CMS common Architecture

I know this is a weird question to ask, but I would like to know if there is any documentation/blog-article out there that explains the architecture of a Website content management system? More particularly, I am interested to lear开发者_如何学Gon more about how "widgets" are implemented.

I can't remember which system it was that I've seen tis one, but in the "Page Layout view" it had the ability to allow the end user to select a widget (thumbnail gallery, contact form, etc) from a list, and drag and drop it onto custom areas of the page.

I know that this is not directly a programming question, but please could I seek advice/feedback on this.

Thanks!

I don't think that any particular CMS architecture exists, there are many. What you call widgets might be something like a component-based view layer. The idea is to create view using component, which can be configured and reused. That is what asp.net uses afaik. On the other hand, many MVC frameworks don't use components, because it is nature of MVC to have views, which are somewhat more coarse grained. The difference can be spotted easily and best compared between web aplications and GUI applications. Most MVC web applications use some sort of templateing engine to create views with at most some sort of partials - template embedding. In contrast, GUI frameworks present you "widgets" which are components of which you can compose your view layer. The advantage of components lays in reusability, but rigidness and some coupling to the backend (their behaviour) is present.

The architecture for a CMS (in general) is arguably no different to any other sort of web application; you will find that the biggest influences on the architecture will be the functional and non-functional requirements: flexibility or performance? local install or hosted? Multi-tenancey or not? etc.

This (diagram included - http://www.morphological.geek.nz/Architecture/default.aspx) is what i've done for my CMS / web-application framework:

• Isolated different areas of responsibility to ensure cohesiveness / segregation where required.
• Abstracted out the data access implementation, via a clean interface.
• Seperated Content, Pages, Page-Layout and 'Skins' (Look and Feel).
• Designed the API's with external third party use in mind.
• Re-used existing capabilities where I can (AntiXSS library, MS Ent Libs, User / Role Membership provider).

The target market for my framework is to be installed and run locally or FTP'd onto a ISP in a shared hosting envrionment (where you don't have full control over the platform).

I've gone for flexibility first (but tried to keep performance in mind); and I'm not intending to use it as a multi-tenant system.