XH 1.7: Abstracting the access to the content

Discussions and requests related to new CMSimple features, plugins, templates etc. and how to develop.
Please don't ask for support at this forums!
Post Reply
cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

XH 1.7: Abstracting the access to the content

Post by cmb » Sun Jul 06, 2014 3:27 pm

Hello Community,

for various reasons the discussion about changing the way CMSimple_XH stores the content comes up from time to time. For instance, eeeno was concerned regarding the memory consumption, svasti was concerned that there are not enough page internal headings, when there are more than 3 menu levels, and recently the issue came up in a German thread, that the current solution is bad for SEO purposes. Furthermore storing all content in a single file sets some limitation regarding the content size, and circumventing this limitation has been one of the reasons for the subsite solutions.

However, we must not forget, that this very way to store all the content in a single HTML file is regarded by some as the unique selling point of CMSimple (links to a thread in the internal forum[1]; a related discussion can be found in the German forum). And there may still be users editing content.htm in an offline editor (in rare cases I do that myself, and find it very handy).

So I presume that we won't be able to agree on a way to change the storage format of the content. However, I think it is not necessary to find an agreement. It seems to be possible to have alternative storage formats as "add-ons" (in the simplest case just replacing some functions). A prerequisite would be to access the contents not via global variables ($c, $h, $u, $l, etc.), but rather via functions or preferably methods. That would be a Good Thing anyway as it decouples the interface from the implementation, so the latter can be changed without affecting the former.

Of course, simply removing the existing global variables would break nearly all plugins, some templates and lot of customizations done by users/webdesigners. So I suggest that we introduce a new API in XH 1.7, and deprecate the use of the global variables (unfortunately, we can't trigger deprecations notices, but we can document the fact). Since XH 1.6 there is already a small abstraction layer XH_Pages, but if we are going to drop support for PHP 4 I suggest to offer a better alternative with an own object for every page (say, XH_Page) and a container (say, XH_Content) to access these page objects. IMO it would be nice to be able to access the page data from these objects, too, which could be implemented as a wrapper for the respective $pd_router methods.

Sometimes in the future we could remove the global variables completely, but even in the maintime it would be possible to develop and use alternative storage "modules", if only extensions using solely the new API would be in use for a particular site.

Christoph

[1] BTW, it is rather interesting to read the former opinions of a certain developer regarding the marriage of content.htm and pagedata.php. SCNR.
Christoph M. Becker – Plugins for CMSimple_XH

Post Reply