Do you know where your variables are? | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
I used to work for a company that did essentially what you are suggesting above for their major product. Content was written in XML, and was transformed into HTML using XSLT depending upon user settings. This meant that it was possible to do radically different things for different users, whereas the writers of content had a very easy time with a generalised mark-up language. Sounds a bit like how HTML was supposed to be, doesn' t it?
All the XML to HTML transformation was done server-side, which does incur a very serious performance hit. In the case of this particular product, pages consisted of many well-defined objects, and once these were rendered once for a particular user profile, those objects could be agressively cached. This meant that things could still run at reasonable speeds, despite the performance hit of the XML to HTML pipeline. PerlMonks is blessed with a similar structure of well-defined objects. We have nodes and nodelets, most of which remain fairly static (with a few exceptions). Being able to agressively cache and assemble these objects, rather than doing a full transformation with XSLT, would no doubt make an XML backend much more possible without major hardware upgrades. If the PerlMonks code does not already do so, I would strongly suggest thinking about caching strategies for both XML and rendered HTML code. This might even provide performance benefits even if we did stay with a pure HTML website. What Petruchio is discussing is possible and is certainly worthwhile. Just make sure you don't burn a hole through your CPU in the process. :)
Cheers,
In reply to Re: Learn to be a pmdev vigilante in 21 days!
by pjf
|
|