cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [announce] XMLForm - a new project using Xerces, Xalan, & JTidy
Date Mon, 28 Feb 2000 16:03:19 GMT
Alex Muc wrote:
> Donald Ball wrote:
> > On Tue, 22 Feb 2000, Jeremy Quinn wrote:
> >
> > > On 21/2/00 at 4:24 pm, (Donald Ball) wrote:
> > >
> > > If this was built into Cocoon, it could be possible to have an XML
> > > file on the server that is addressed (via SiteMap) by the Form's
> > > Action, which contains the information required to do stuff like:
> > >
> > >     work out what file to update/create;
> > >     map Form Fields to Nodes;
> > >     define datatypes and ranges;
> > >     provide a cusomisable response
> > >     define behaviour like form chaining
> > >     etc.
> > >
> > > I am sure you must have had good reasons to implement this as a
> > > Servlet rather than a Producer.
> > >
> > > What am I missing?
> >
> > Cocoon is a web publishing framework. XMLForm doesn't need cocoon since it
> > only returns HTTP redirects (unless something goes wrong). Cocoon may well
> > generate the HTML form used by XMLForm, but it's certainly not mandatory;
> > I dunno, I see XMLForm being useful in situations where cocoon may not be
> > desirable. If someone can come up with a convincing reason why XMLForm
> > belongs in cocoon, I'm all ears, otherwise I say keep the code and feature
> > bloat to a minimum ;)
> I haven't really been using cocoon too much, so my practical experience with it is
> rather limited.  I have, however been following this list for the last couple of
> months.  Forgive me if my comments seem out to lunch.
> I think a pretty strong case can be made for XMLForm (or something similar) to be
> rolled into cocoon mainly because of the following:
> If cocoon is an XML-based publishing framework I think it should make use of XML
> wherever possible, the biggest place where I see this lacking is in the access-to
> and processing-of HTTP requests.  From what I recall of looking at the source code
> there is all this HttpRequest stuff lying (as parameters to method calls) all about
> which I think would be better replaced by a simple DOM XML document which contains
> all that information in XML format.  It could include the HTTP header info, POST
> data (if any), access point to session information, and whatever else might be
> necessary.  I think it would be a good idea to centralize access to all this
> request information.

I am opposed to this, like I said to Niclas not long ago, since it
doesn't make sense to XML-ize an http request and then parse it again to
retrieve the information it carries.

True, with the XML-ized request, you could xsl-transform it directly...
but usually you want to "do something" with the HTTP request and doing
something requires logic... and placing logic into XSLT for form
handling, is, IMO, the evidence of the "golden hammer" anti-pattern.

Also, if you need to fill your request with all the cookie and session
parameters, the overhead of doing this might be orrible since your
sessions might be stored someplace else, maybe in a heavy clustered

Also, I don't like the ability for users to match around with my XML
structure from the HTML form, this is a HUGE security hole.

I think Donald's proposal is clever, but adds more problems than it
solves. We must think about better ways to do the full loop 

 request (empty) -> response (with form) -> request (with data) ->
response (with result)

This is the piece we are currently missing.

I was playing around with XFA ( but I'm not sure which
direction to take... what do you think?

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

View raw message