From: Thomas D. <t.d...@wo...> - 2003-06-12 21:55:24
|
Ian writes: > Personally I detest XML files -- the beauty of OO is when data is not > exposed, just methods, and XML exposes data in an inflexible way. But > the interchangeability would be great. At Autodesk, we had an object-oriented approach to XML for the Streamline engineering collaboration service. We had class libraries in both C++ and Java for client code (web apps, server apps, and publishing apps), who used objects rather than XML text. XML was used to persist CAD data in "packages," crack open packages to populate databases, and stream structured metadata from databases to web clients. It is very much like C# uses attributes to serialize objects in XML, but we had a finer degree of control. The wrong XML definition was shown to balloon text size to an unacceptable degree pretty quickly. More recently, I used Webware/Python to prototype an online catalog for a local not-for-profit institute serving the visually-impaired. The catalog was defined in XML. (No formal schema, just me inventing a syntax. The initial catalog has 90-100 entries, enough to give me a warm feeling that the XML has pretty good coverage.) One of the goals for the site design was to be able to maintain the web presentation separately from the catalog content. The website look and feel would not change often, but products would be added or deleted from the catalog on an ongoing basis, prices would change, etc. [It should be noted that the online catalog and site are designed only for presentation, and not to support direct purchase at this time.] I got two things from python: 1) A nice class hierarchy for the web page types (welcome, show items in a given category, show search-by-keyword results, show specific item) along with a parallel class hierarchy for the XML filters needed to support them. 2) Good built-in support for SAX parsing, without validation. Given that, what I got from Webware was a straightforward and repeatable organization for the WriteContent method on my python server pages: # parse values from the HTTP request, if any, ... # Read the catalog and render the page, for example # base = os.path.dirname(self.request().serverSidePath()) pp = GoreySearchPage(self, base, 'Gorey.xml', ...) pp.read() pp.render() The read() method parses the XML file, pulling out the juicy bits. The render() method writes the HTML response. Granted, the python statements to crank out the HTML response were tedious to write, but there is a lot of common content across the page types, which was well-supported by the class hierarchy. I was able to get a feature-rich site running in about a week, with no previous Webware experience and somewhat rusty python skills, and to extend the functionality easily a couple times already. On the XML side, the catalog file worked as I intended it to. Changes were automatically reflected in the website, even if the change added or removed a product category, changed the number of pages occupied by a category, or added/removed an entry from a keyword search result on screen. (An aside: pagination is very important when delivering data to the visually-impaired, some of whom might be using a text-to-speech system to READ webpages to them, others who might be using very large type. As a sighted user, I tend to want many results on a page. But I have also experienced the tedium of the mechanical voice droning on and on. We are experimenting with various strategies for separately formatting content to suit users with various classes of visual impairment.) So Webware seemed to be the right venue for getting a proof-of-concept done in a short amount of time, while still having an understandable and extensible design. It remains to be seen whether we will go live with that architecture. Tom Dennehy Private Citizen Bloomfield Hills MI |