Integration in the general case

Users (including me) have, in the past, wondered why it is so difficult to integrate blogs forums and shopping carts that normally want to be autonomous pages. In other words, why can't Phorum appear as the contents of a DIV inside some other layout context? Why can't I put phorum inside my header-navigation-and-main-display pages, without using an IFRAME?

The answer is complex, but it seems to have a lot to do with conditional if($x<$y) header("location: xxx") else .... switching. Answers to that question (from Phorum developers) often complain that although that goal is entirely doable, it is far too much work to accomplish, perhaps involving huge amounts of Javascript.

In a slightly related context someone here did publish the guts of a way to place a Phorum discussion at the foot of every page, on an arbitrary website. I remember the example given, and it worked nicely. But it was painfully difficult to pull off.

=======
So why don't software systems like Phorum adhere to an integration API of some kind? If ALL get and post parameters specific to Phorum where named with a unique three character prefix followed by and underscore, it would be a fairly simple problem to write a plugin manager for any enclosing Content Management system. ?cms_page=whatever&phm_readphp=1234

Perhaps I'm missing something. Perhaps I'm missing a lot. But I don't see why an enclosing content management system couldn't parse a URL like that. Recognize phm_ refers to a well-known "plugin" named phorum who wants to make use of a routine named read.php with parameter 1234. Produce the phm_ output before pushing anything down the internet pipe. Save it as a string and then push it into a block element inside the CMS page and then write to port 80. If all important content producers followed an established plugin API, then any system could make use of any other.

Phorum could have a blog attached. Open Cart could have product category forums. Etc.



Edited 4 time(s). Last edit at 09/18/2013 04:04PM by salmobytes.

On the flip side of this issue, another problem with nearly all open source content generators is their pervasive reliance on codes who make use of embedded templating systems. *.tpl templates are easy to manipulate if and only if you merely want to tweak the appearance of that particular template include. But what if you want to move block elements around like musical chairs? And how do you change what a given template include does, when template include statements are peppered throughout external PHP codes like bits of black olives in a spaghetti sauce, from who knows where?

Templating systems are rumored to make modification easy, when in fact they make it more difficult. For instance, if Phorum (which is otherwise the best forum software out there) was easy to manipulate graphically, there would now be a host of contemporary-looking skins to make use of. But instead the template library consists of a long list of derivative tables-based looks that change largely by color and border style only. Trying to modify skins is trickier than writing new plugin codes. I have my ideas about big-picture directions to go in. But even without specific alternative suggestions I am firmly convinced templating systems are holding the whole web development picture back. To a look-and-feel snail's pace.

Ok. I'm ready to receive all incoming arrows. But I do predict in a decade's time all content production systems will be able to embed all others, and versa visa. And new look-and-feel skins will be a lot easier to modify than they are today.