[
Lists Home |
Date Index |
Thread Index
]
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@whump.com>
http://www.whump.com/moreLikeThis/
|
