CMS design
Posted: Sun Sep 03, 2006 3:27 pm
While considering design/concepts, etc for my second version of my CMS...
I ask myself, what type of system most people prefer to deal with?
In the backend, my CMS uses a front controller type approach where all requests to display a page are done through a single index.php and actions are carried out intrinsically via FORM actions, etc...using seperate modules.
In this regard it's not really modelled after the model 2 architecture, but it more closely resembles model 2 architecture than model 1, because it does use a form of front controller.
Thats the backend, where clean URL's are not an issue as no one cares if Google spiders their admin pages anyway (in fact that could be bad and likely wouldn't work without logging in first anyways)
So, model 2 makes sense for me here and it seems it's common amongst most CMS applications.
My client generated pages is where I take a slightly different approach to solving the problem, instead of using model 2 approach, my CMS actually generates the phsyical web page as a file, which is invoked by normal clicking.
In this regard, model 1 offers several advantages:
1) No mod_rewrite required for clean SEO URL's
2) Slightly more efficient as no front controller, mapping, etc is invoked...possibly important when having a massive article repository pidered by Google, etc...
3) Most flexible and extensible. There is no need to hack into the CMS itself when adding PHP functionality to any given web page, as each page is just a PHP script.
Of course there are many disadvantages as well:
1) No DB means inbuilt extensibility is difficult or at least more work
2) Searching, archiving, etc becomes a difficult task to implement
3) RDBMS seriously make life a lot easier
Some short falls can be circumvented using existing 3rd party libraries. For instance I could add search engine support by using a class like Lucene search in the Zend library or others.
Basically my backend is modelled after model 2 and my front end is more analogous to model 1.
My CMS works more closely to say a web enabled version of front page, then it does an CMS of the PHP variety...
So I'd like to hear opinions, design suggestions, etc...
I guess there is no point in starting a second version using the model 1 approach for the front end if everyone agrees dynamic URL's are acceptable or if need be...mod_rewrite is always available...
My next version will likely use Zend and at this time AFAIK mod_rewrite is mandatory, althought sounds like that is going to change as a requirement...
Edit: I should also note, that currently my CMS doesn't require a RDBMS as I wanted pages to be availble even under DB down conditions, but I'm re-considering that approach as well???
Cheers
I ask myself, what type of system most people prefer to deal with?
In the backend, my CMS uses a front controller type approach where all requests to display a page are done through a single index.php and actions are carried out intrinsically via FORM actions, etc...using seperate modules.
In this regard it's not really modelled after the model 2 architecture, but it more closely resembles model 2 architecture than model 1, because it does use a form of front controller.
Thats the backend, where clean URL's are not an issue as no one cares if Google spiders their admin pages anyway (in fact that could be bad and likely wouldn't work without logging in first anyways)
So, model 2 makes sense for me here and it seems it's common amongst most CMS applications.
My client generated pages is where I take a slightly different approach to solving the problem, instead of using model 2 approach, my CMS actually generates the phsyical web page as a file, which is invoked by normal clicking.
In this regard, model 1 offers several advantages:
1) No mod_rewrite required for clean SEO URL's
2) Slightly more efficient as no front controller, mapping, etc is invoked...possibly important when having a massive article repository pidered by Google, etc...
3) Most flexible and extensible. There is no need to hack into the CMS itself when adding PHP functionality to any given web page, as each page is just a PHP script.
Of course there are many disadvantages as well:
1) No DB means inbuilt extensibility is difficult or at least more work
2) Searching, archiving, etc becomes a difficult task to implement
3) RDBMS seriously make life a lot easier
Some short falls can be circumvented using existing 3rd party libraries. For instance I could add search engine support by using a class like Lucene search in the Zend library or others.
Basically my backend is modelled after model 2 and my front end is more analogous to model 1.
My CMS works more closely to say a web enabled version of front page, then it does an CMS of the PHP variety...
So I'd like to hear opinions, design suggestions, etc...
I guess there is no point in starting a second version using the model 1 approach for the front end if everyone agrees dynamic URL's are acceptable or if need be...mod_rewrite is always available...
My next version will likely use Zend and at this time AFAIK mod_rewrite is mandatory, althought sounds like that is going to change as a requirement...
Edit: I should also note, that currently my CMS doesn't require a RDBMS as I wanted pages to be availble even under DB down conditions, but I'm re-considering that approach as well???
Cheers