>> >> In-other-words: currently, sitemap has access to context via URI, >> parameters, generators, etc. Based on this, sitemap spits out a >> decision on what transform to use. What I want instead is to feed an >> XSLT this same set of context as XML and have the XSLT pick the >> subsequent transform to use. The advantages to me are; 1) I can code >> in XSLT instead of sitemap language; >> 2) I can optimize the entire chain of events since the transform picking >> XSLT can pass on the context to the next transform (standard transform >> chaining); 3) I get a functional programming model (not an advantage to >> some, I know). > > I believe what I am doing with livestoryboard is exactly what you want, but I go about it differently. > > You have many projects going on with all of their own properties. I have the same issue with different sites having their > own properties (they could have differnet schemas). A site is defined in a single XML file, site.xml. The transformation to > the page view always happens against this cached XML. Since this XML has all the properties handy I can set up the UI > controls to use the specific properties (including the appropriate XSL, which can be changed by an authorized user) > necessary to do the next thing, whatever that is. What I actually do is transform the site.xml into JS objects (that extend > a base object so I can get the benefits of inheritance). I also transform my schema (config and content) into JS objects. > The constructors are also created by the schema transform so they can be whatever the project needs. The combination of the > schema objects and the site objects lets me do pretty much anything I want, or rather, anything the client wants. > > Is this on target, this time?
Can't tell for sure... Our users will get their own UI generator which will create an XML description of the UI that they want for any particular "screen". This XML is validated (and constrained by the UI generator tool) against a schema that is essentially assembled dynamically from metadata in a database. At run time the XML is matched up against the metadata as it currently exists (it may have changed from the point the original UI was built), the current user authorizations, the current context (session and request data) and a combined abstract representation of the data elements and presentation elements is created (via a transform on all of the data just described). This combined data is now fed to the presentation layer for rendering as appropriate (be that HTML, PDF, or whatever). I'd guess that your JS objects eventually render HTML or XML? If so, can they be used to render anything else (PDF, Excel)? If not, that would be the big difference in approaches. So far, our dynamic validation and dynamic work flow only work with browser based interfaces, but I could see, for example, generating an Excel spreadsheet that includes build in validation handling and an "Authorize" control embedded in it that causes the thing to be submitted back to the back end system for subsequent handling. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
