Content Management Architecture

12 Comments

• It depends on how you store / separate your content. Main thing is: store your content in a given format (be it article has 1 or more Items has one or more Elements which are of type string/table/image etc or just a blurp of text) and be able to retrieve it in an XML format so you can apply any viewer to it you can think of using XSLT. This way you keep the content in the database once (as a separate unit) and view it on different locations using different viewers (f.e. on the frontpage differently than on a product page).
  
  
  
  
  
  In my commercial CMS, CESys, I used containers, with items and elements. An item is of a given type, and per Container-item-element you have a different XSLt viewer. You can then decide to store the XSLT appliance statically (when the Item is saved / added to a container) so you can retrieve html/wml very fast, or you apply the XSLT on the fly, which is more dynamically but slower. This can be done on a per page / user basis, since you have the two stored separately the contents and the cached HTML / wml generated.
  
  
  
  
  
  Generating HTML / wml on the fly without serious caching (using asp.net f.e.) is very slow compared to static caching in the database and most of the time not necessary. WHen you work with blocks like 'items' you can create user-defined pages even with static generated HTML. :)
  

• Hi,
  
  
  
  
  
  After several years of working with CM systems, I can give the following tips:
  
  
  
  
  
  1. the #1 problem with static sites is that they are useless. You will almost always need at least some portion of the site to be dynamic- for example banners, the date, user info, etc. So creating static "snapshots" of your content is usually NOT a good idea.
  
  
  
  
  
  2. One of the key parameters to be aware of is the R/W ratio. If your site has a high ratio (~10000:1 or more) then you can usually get away with various caching schemes. Any lower than that and you are probably better off doing dynamic rendering. For example, if you get 10 hits a second and update once an hour, your ratio is 10*60*60 = 36K:1 which means you should definitely be caching. On the other hand, if you implement personalization on the same site, you could have 36K UNIQUE hits each hour, with an effective ratio of 1:1. Then you would need to consider caching at the sub-page level - see next bullet
  
  
  
  
  
  3. When caching, you need to decide what to cache. The ASP.NET method caches the actual HTML output, which usually isn't very usefull unless you add a layer on top to manage page fragments (ASP.NET does this but not very well). Sometimes it is better to cache the "raw" content and render it on the fly- this approach is more suited toward personalization, multiple device support, etc. Most of the real-world solutions are hybrids which do a little bit of each and also some other stuff.
  
  
  
  
  
  4. Each CM solution (and it's cache management solution) is geared toward a specific site size... caching for a one box solution will be much simpler than a multi-site multi-farm solution with content propagation, etc.
  
  
  
  
  
  Bottom line- understand the customer, understand the requirements, understand the budget, then go buy an out-of-the-box solution. Home-grown site management tools are rapidly becoming a thing of the past.
  

• Don't create static pages under any circumstances, use caching. Remember, the static pages are logically equivalent to cached copies of your dynamic pages. The difference is that you have to do a lot of extra work if you are going to save your pages to the hard disk somewhere (and, synchronization quickly becomes a pain if you have to cluster your systems and you are using static content), but simple caching can be enabled with one little directive at the top of your page.
  

• Jesse ok I follow you but in this project, each page has a lot of controls, each of them doing a specific function.
  
  
  
  
  
  The issue I have is that I can't cache those controls, they are dynamic. For example I have a Poll control, which take the questions from the database, or a Story box which contains stories kids can post.
  
  
  
  
  
  Until now, unless I'm wrong, I have no idea how I can cache some controls and not some others in an easy way.
  
  
  

• Addy I agree with what you say but not for the last one.
  
  
  I worked with different CMS tools like Vignette for example, and it was always a painful experience.
  
  
  I say so for small and medium projects, maybe for a news website they are perfect.
  
  
  I found many times also their templates approach very restrictive, and difficult to adapt.
  
  
  I don't want to have my site looking the same for each single page. And finally, they are difficult to work with self made controls
  

• Forget the concept of 'page'. Focus on content elements. Apply viewers (xslt is nice to use) to these elements depending where they appear on which page, but do not focus on a page. F.e. a newsitem can be added twice to the same page: once as a headline (using a headlineviewer which creates a link from the item to the actual item on the same page) and once as a full item. It also can then be on the front page as 'the last newsitem added' or similar, you get the idea. The same data, different viewers. Addy's remarks about caching/updating are pretty good and usable what you then should do with those viewers: apply to the item once so it gets rendered very fast or on the fly.
  

• Jesse, I already have the items concept applied.
  
  
  I called them boxes, but it's the same, they can be duplicated.
  
  
  I see the point with the viewers. so if I understand well, I can cache a raw content and apply a viewer (XSL) to render the box. Am I right ?
  

• Yah. You can do that (take a look at the Cache object). Or, you could have a user control called something like "ItemDisplay.ascx" and use output caching at the user control level.
  

• 
  
  
  Guys,
  
  
  
  
  
  I'd say that 80% of the failures I have seen have resulted not from bad performance or site design, but from problems with the content management process. If you can't efficiently manage and update the site then pretty soon it will be dead in the water. Things like version control, image catalogs, approval processes, content backup/restore and user roles are critical to running a medium to large site, and you definitely don't want to start developing those by yourself. You need a good CM system for your USERS not for you (the developer). Anything which has a half-decent API will allow you to develop whatever front-end you want. For example, MS CMS is relatively easy to start with and has good integration with ASP.NET and IIS.
  
  
  
  
  
  

• Addy I still think it's not so difficult to build a CMS for a small to medium project.
  
  
  
  
  
  I had really bad experience with CMS system which didn't understand my website.
  
  
  
  
  
  Don't flame me on this but I think a lot of CMS companies don't know really what is content management !
  

• I've just rewritten the whole cache portion of our commercial asp.net CMS system. It allows page fragment caching as well as whole page caching, all configurable from the CMS interface. If you like any pointers, just contact me (oddur@disill.is or msn: oddur@magnusson.is).
  

• Oddur that sounds like a good idea. I will send you an email on the subject if you can light my green lantern ;-)