cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Muc <>
Subject Re: [announce] XMLForm - a new project using Xerces, Xalan, & JTidy
Date Mon, 28 Feb 2000 00:22:13 GMT

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.

My 2 cents worth

View raw message