Hi Peter, > -----Original Message----- > From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 27, 2002 1:04 PM > > >> > >> 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?
No. The schema JS objects are basically pregenerated and live in a hidden frame that is loaded once at startup. The site JS objects are loaded into another hidden frame and are only refreshed when a change to the site properties has been done by a user in the project. There is a main frame that houses the wysiwyg view of the page, which is a result of the request. It is transformed on the server using the site.xml and the appropriate XSL and sent back as (X)HTML. The site XML tells me what EACH folder, page or content piece needs for a transfomation. I use a URIResolver to find these things. Here is a newer screenshoot: http://www.livestoryboard.com/en_us/Products/Screen_shots.html I do not want this flow to happen on the server because I want all of these props available for whatever the user wants to do. Of course you have to deal with locking things that should not be edited, because they are in use by another user who got there first. Every trip to the server (page req, save, etc) tells the browser to reload the site JS objects or not. It also sends lock information for folders, pages and content. If editing is available and triggered by the user, the content is parsed and set up for editing. Then on save it is roundtripped back to XML and submitted to the server. > If so, can > they be used to render anything else (PDF, Excel)? Well, it can handle the properties and probably render it, but I have not put any real thought into this. You definitely have alot going on! I'd say your job is secure for a while :) HTH, -Rob > 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]
