cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: [announce] XMLForm - a new project using Xerces, Xalan, & JTidy
Date Sun, 27 Feb 2000 20:11:52 GMT
On Tue, 22 Feb 2000, Jeremy Quinn wrote:

> On 21/2/00 at 4:24 pm, balld@webslingerZ.com (Donald Ball) wrote:
> 
> >I've been using cocoon for time out of mind to handle sending information
> >out of my XML files as HTML over HTTP and it's fantastic. That's half of
> >the work of a typical web design shop. The other half of the equation
> >hasn't really been addressed to my satisfaction yet - I wanted a way to
> >edit XML files through an HTML form interface.
> 
> This is marvelous!
> I was particularly tickled by the use of XPath :)

Thank you! Sorry it took me a while to get to this message, my mailbox
just topped the 1000 messages mark. 50% of that is cocoon related stuff.
seriously. y'all need to stop being so damned chatty :)

> >If you find this servlet useful, if you have any suggestions, or if you
> >know of a similar project in Java that escaped my attention, please don't
> >hesitate to contact me.
> 
> I have not had the chance to tryout or read the code ...
> 
> Can it create new files?

erm, not right now since the only node alteration mode is 'append' (which
requires a node to append to!) but i'm adding 'replace' right now, and see
a need to add 'prepend' and, uh, 'subpend'. once i get replace working
i'll remove the restriction on adding files.

> Sorry to say this, considering how much work you have already done, but could
> this Form handling functionality be considered for inclusion into Cocoon?
> If so, how should it interact with SiteMap, XSL and XSP?

It's possible, I suppose, but I think a marriage would be forced, at best.
I see the two projects as complementary. What advantage would be gained by
putting this functionality inside cocoon itself somewhere?

> >From the README file in the distribution.
> > <input name="xmlform:virtual" value="/news.xml">
> > <input name="xmlform:xpath" value="/articles/article[position()=last()]">
> 
> Is this not a bit of a security hole? Anyone with the motivation,
> could "explore" your XML file structure (with feedback from error
> messages) and add Nodes wherever they like; just by modifying the
> Form. (In fact I have some students who might think of this as fun :)

Well, I wouldn't open up the XMLForm servlet to untrusted users. Assuming
you had to, though, I reckon I could add a configuration option to the
servlet that specified a list of URLs from which posting was allowed. Btw,
the servlet runs in POST only mode right now. Then as long as the trusted
POST urls were secured, the users should be unable to mess with the XML
files outside of your narrow constraints.

> 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 ;)

- donald


Mime
View raw message