Cart
[Home] [By Thread] [By Date] [Recent Entries]
Joshua Allen: > I personally think that this idea of an "XML View" is a great way to > webify a relational database and make all of the data universally > addressable. It is also consistent with RESTful idea of "mediated view" > over a resource. SQL data thus exposed is accessible from XSLT > document() function, and all of the other GET clients. Didier's described how the CMS I'm writing in Frontier for one of Apple's intranets handles editing. The pages are stored in Frontier's database as compiled XML, each editable component on a page can be described with an Xpath expression: /page/summary[@id = '0001']/para[@id = '0005']. When a page is displayed on a browser in editing mode, each of those editable nodes has a GET URL: /editing/content/get?path=/path/to/page&xpath=summary[@id = '0001']/para[@ id = '0005'] (URL encoding left out for clarity) In practice, I'm using BSD's tool to generate unique id's for editable elements. I then convert the Xpath to a Frontier database address: @sometable.path.to.page.["00001 summary"].["00005 para"], and fetch the CDATA for that node. That content is returned in a POSTable HTML form with the content, the page, and the XPath as parameters. My current Xpath implementation is minimal, paying attention only to @id attributes as qualifiers, a full Xpath implementation in Frontier would be nice to have, but this works for now. This architecture's allowed me to remove dependencies on Frontier at the client side. And since the data can be extracted from Frontier's databases back into valid XML, I have the flexibility to move to any other XML store on the server-side in the future. On the performance side, we've achieved a 100-250% improvement by switching to Frontier's table model instead of the outline model the previous version of our CMS was using. The painful part has been getting export scripts to take the outlines and convert them to XML. ---- Bill Humphries <bill@w...> http://www.whump.com/moreLikeThis/
|
