XML Application Servers

[Mike Williams]

  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. 

  Sebastien> In our project we don't yet clearly seperate the logic from
  Sebastien> the content, but our approach is the following : We can
  Sebastien> express Business Object behaviour in XML, say simple, actions
  Sebastien> on a EJB are writen in XML and result from such action, 

Interesting ... can you show me an example?

If your logic and content are represented in the same file, can your logic
select alternate content?  For instance, say your logic detects that the
user has entered invalid data, and you wish to re-present the originating
page so they can try again ... how would you do this?

  Sebastien> May you need more information, don't hesitate.

Cheers. I'm very interested in what you're doing.

-- 
Mike Williams

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)