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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
