XML Application Servers

[Patrick Phalen]

>From your (Mike's) description, it sounds like Zope is within spitting
distance of providing everything you need, with the additional
advantage of being scriptable in Python.

It has the hashed object store, ORB, the document template
processor, the clear separation of control and content, and the ability
to dynamically control display of forms, etc. It also has the
infrastructure for fine-grained access control. I believe the missing
XML pieces are already being worked on, but you could easily add what
the Zope group calls a "Product" to supply them.

Take a look: http://www.zope.org


[Mike Williams, on Sat, 27 Nov 1999]
:: Mike> The servlet collects output data in a hash-table.  Then, I (plan to)
::   Mike> run a template-processor, which splices this data into existing XML
::   Mike> templates, constructing an abstract view of the page.
:: 
::   Sebastien> Sound similar to the Cocoon publishing framework, expect that
::   Sebastien> your control logic is handled by the servlet itself.  This
::   Sebastien> latter point should, IMHO, be also XML driven, a la XSP (still
::   Sebastien> from Cocoon), 
:: 
:: Hmm. Cocoon is doing very good things, and I took a good look at XSP, but
:: it didn't quite meet my needs.
:: 
::   Sebastien> logic description -SHOULD NOT- be hard-coded in servlet but
::   Sebastien> rather scripted, and eventually compiled on the fly by the
::   Sebastien> server processor.
:: 
:: Well ... the sample XSP code I've seen uses Java as a scripting language,
:: so it's not as though coding is easier.  Though I do like the idea of
:: compiling XML into Java code that produces DOM nodes (or SAX events).
:: 
:: Let me explain why I chose to "do my own thing".  
:: 
::   * XSLT is good for _transforming_ documents, to apply a style.  However,
::     it's not so good for assembling document components.  For this, a
::     template-like system makes more sense.
:: 
::   * Similarly, XSLT is good for duplicating markup, ie. which is not so
::     good when your markup includes code. If you put code in a XSP
::     logic-sheet, then apply this to a number of content documents, it seems
::     to me that you'd end up generating a number of pages containing
::     identical code.  Messy.
:: 
::   * Cocoon XSP is not yet a reality, only a work-in-progress.
:: 
:: This is my current world-view:
:: 
::   * Control *logic* should be in control of what *presentation* method to
::     use, and what *content* to include.
:: 
::   * Templates are a useful way to define data-independent presentation. It
::     should be possible to include other templates, allowing a page to be
::     built out of re-usable fragments.
:: 
::   * Templates should be able to display content from different
::     sources. They should be *provided with* content to present, rather than
::     knowing how to go out and get it.
:: 
::   * Likewise, it should be possible to display the same content in
::     different ways.  So, the content shouldn't (directly) imply the
::     presentation mechanism.
:: 
:: I need this flexibility because of the requirements of my current project,
:: which is a database-backed web application.
:: 
::   * Dynamically created forms. On some screens, data-entry fields are
::     generated dynamically from the database, depending on what's
::     appropriate for the object being edited.
:: 
::   * Context-sensitive help. We need to be able to provide help for each
::     screen of our application, describing the forms, fields, links etc on
::     that screen.  This includes the dynamic screens mentioned above.  To do
::     this, we plan to include help-text in our screen templates, and use
::     alternate style-sheets to display either the help or an editable
::     screen.
:: 
::   * User-visible text (labels, help, etc.) cannot be hard-coded in the
::     screen templates, but must be but sourced from external
::     configuration-files. 

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)