CMS Design: Modularize a web page?

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

CMS Design: Modularize a web page?

Post by alex.barylski »

I have to modularize page construction for a CMS...I am trying to logically break down the parts or sections of a web page and reconstruct them on the fly...to return a whole finished product...

So far I have decomposed a web page into 3 sections (in order of assembly):

1) meta section (title, keywords, doctype, language, etc)
2) view section (layout template - everything inside BODY tag which defines layout)
3) page section (Content supplied by user, etc)

1. META HTML is constructed from fields (CSV, DB, etc)
2. View is already in native HTML but wrapped by META
3. Page content is interpolated into the finished compiled product (Native HTML).

Depending on page content, certain CSS and JS files may be required...and so by generating the META section on the fly will allow my CMS to reconstruct META section accordingly (ignoring the fact that TITLE is both meta and markup)

Originally I considered have the Native HTML content of View and Page stored as DOM objects, so depending on the META doctypes I could dynamically generate HTML, XHTML (trans, strict, etc) accordingly...however I have decided that would be likely overkill and too time consuming to both implement and generate (even with caching).

If someone desires to have an HTML and XHTML 2.0 web site, they can define two different view templates...

1) HTML compliant
2) XHTML compliant

I can't think of any reason why anyone would want to work backwards though (backwards support I suppose) and support HTML if they already had xhtml 1.1 trans...but anycase, this isn't my question...

In fact...I don't really have a question...I just needed a brain dump and figured I'd troll for ideas, suggestions, comments, etc...

What do you think of the above? Have any comments?

Cheers :)
User avatar
daedalus__
DevNet Resident
Posts: 1925
Joined: Thu Feb 09, 2006 4:52 pm

Post by daedalus__ »

I've been struggling with what I think is somehting similar lately. Although I do not have anything to add at this point, I will let you know if I have any good ideas. :)
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

I use a bit of output buffering to manage this with a very basic template engine.

The main view is the layout/structure you mention; that's the bit which contains a <head> section with a <!-- @HEAD@ --> marker inside it which gets used later.

I then have page views which are just smaller templates using the same template engine but just in a simpler way.

My page views can then set items which are due to go in the <head> by defining a section at the top of their own little template like this:

Code: Select all

<!-- @HEAD START: -->
<style type="text/css">
...
</style>
<!-- @HEAD END@ -->
The order by parsing is:

Run template engine over the page view and buffer its result in memory. Remove the @head@ section from it completely and store it in memory. Run the template engine over the main view, replacing the @head@ section with the one from the page view and then inserting the page view into the correct part of the layout.

I'm not sure if that's where you're heading with this? You could probably do some more weird and wonderful things with the DOM library.
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Post by matthijs »

Maybe I don't understand your system completely, but are you storing different sections of the pages (views) in different ways?

Seems to me like this might complicate things too much and could make the system less flexible. From a users perspective (someone using the cms and/or webmaster making the templates) I think the best system is one in which the templates themselves can be completely edited. And then use some standard tags/variables in these templates to replace common elements, like the title of the site, the keywords, etc.

I like the way it is done in wordpress for example. It's the content which is stored in the db and which can be placed in the templates, like "get latest 5 posts and show them here in reverse chronological order" or "show list of categories". The view/templates around the content can be completely managed. And are a set of physical files in a separate directory. I don't like the other way around: having certain parts (modules) of the layout stored somewhere in the system. I think the risk of being less flexible is great.

I hope my point is clear. I have seen many systems in which certain modularization is placed in the system itself. Sooner or later that restricts the way you want to design a page/section of a website.

So, that's my brain dump :)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Thanks for the replies...not sure if any of us are on the same path :P but I"ll try and absorb what you've all said...

d11, that is how I have done it in the past, but not how I am trying to do it now...difficult to explain without even a prototype...

Perhaps this will clarify things a little...

In attempt to make the CMS as easy to use and flexible as possible, I am building a psuedo-three tier user system:

1) Content editors/authors
2) Template editors/authors
3) System administrators

3 being the ROOT user (all privileges) and others being more fine-grained in access. This is of course not technically accurate as the permissions and roles are much more advanced but from a high-altitude perspective it is these three user levels which will dictate the control any given user has.

I am using a prototype template language I have been working on for a couple years. Quite different from the norm, but not complete enough to claim victory, so everything is still early prototype stage.

Everything client side is stored in a database (templates, css, javascript, etc) only the backend uses physical files. It's difficult again to explain why I choose this approach, but so far (at least conceptually) it has proven to simply my understanding of the CMS. The problem of course is that templates typically cannot be stored in a DB because then template logic goes out the window; You could cache to disk and call include() or Smarty->fetch() or write a custom template parser and execution engine.

cheers
Post Reply