cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: Flow wishlist :)
Date Wed, 27 Nov 2002 21:03:57 GMT
>>
>> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message