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 Fri, 29 Nov 2002 16:38:42 GMT
Hi Robert,

>> 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.

Ok, our two systems have similarities but we have a very different
requirement than you; our users cannot create new content, only work with
previously approved "objects" on a given page.  Let me give an example; we
have a "Radiation" page that can be used by any protocol to track various
types of radiation treatments.  At some point a user committee got together
and decided what are the standard ways for tracking radiation and we
implemented over 30 different "objects" that do this.  These objects are
defined in metadata for the radiation page (using a base of about 20
standard java objects).  Some of the radiation objects (IIRC only 2) are
considered mandatory for any radiation page, the rest are optional; a given
protocol may or may not be measuring the same things as another protocol.  A
business analyst now gets enlisted to build a new radiation page for a new
protocol.  They work with the end user to make sure the requirements for the
new protocol match up with the requirements as known to date (if not, the
new requirements are presented at committee). Eventually the analysts
(and/or end user) uses a UI builder to pick from the objects described in
metadata to determine what specific objects apply for that specific protocol
and how they should be presented on the screen.  This final description is
recorded in an XML template stored in the database for that protocol.  At
presentation time the template is used to retrieve the required metadata.
The then current context (authorization, session, request, etc.) is also
created (as XML input) and an XSLT transform evaluates the template with
respect to the current context (still authorized?, previous errors?, etc.) .
Based on this an abstract object representation is built that contains all
currently known information about a given object.  This abstract
representation is then passed on to a second transform which renders it for
presentation purposes and the final screen is built.

The same template building process as is used for UI objects is used to add
validation rules, presentation flow rules, and work flow rules. Eg; for a
given protocol maybe the radiation can only be given if it is following
chemotherapy, a lab documenting the patients blood work must be specified,
(and it is picked using method X from system Y), and the values on the red
blood cell count must between M and N...

>> 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 :)

Yes, I'd guess so... This is the most complex system I've ever been involved
in.  Among many other things I've previously built an application
infrastructure that was used to build over 1000 MIS and EIS applications for
over 15,000 users in a single company (and it was deployed across multiple
companies).  This is a far more complex system...


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message