cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@supereva.it>
Subject Re: Forms proposal
Date Tue, 04 Jul 2000 07:11:53 GMT
----- Original Message ----- 
From: "Niclas Hedhman" <niclas@localbar.com>
To: <cocoon-dev@xml.apache.org>
Sent: Tuesday, July 04, 2000 7:52 AM
Subject: Re: Forms proposal


> Stefano Mazzocchi wrote:
> 
> > Many others have something to say about this?
> 
> Is this not a whole different thing??

In which way?

> My knowledge of FORMs is basically;
> 
> The form's fields will be parameters in the URL.

Not necessarily. If you look at the W3C site, the XForms proposal, you will see
that they want to send XML directly to the server, no parameters.
When you want to send an array of data the size of which is not known beforehand,
with normal forms you must send a parameter with the elements divided by some
character and parse the string in the server.
With XML, you just send XML, no need to reparse yourself. 

> Is there any other long-term suggestions on how forms are to be sent from the
> browser to the server?

Two methods: parameters and XML.
 
> Sounds to me what you want to do is;
> 
> Http parameters -> XML -> validate -> destinationtion processor -> response
page.

Your scheme is the same as mine, basically, but without the specification of all
"actors". I wanted to define clearly all that is needed.

> Then to me, it looks like that Cocoon executes the response page creation, and
> that the Generator for such is the 'processor' of the Form.

Also the "request" page creation. And the 'processor' of the form doesn't
create the response, it just transforms the form into the valid xml posted
by the client for further processing.
I want to make it as modular as possible.

> Then you would add a new type of ServletRequest class, which overrides the
> doPost(). It would require its own kind of mapping to validation and processing
> classes, but quite straight forward.

I think thar a processor is simpler and cleaner.
I'm not saying the processor code is difficult, but it's not the only thing.

Ken

Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Via Leonardo da Vinci,2 Ticengo (CR) Italy
Personal homepage at Java Guru:
http://www.jguru.com/jguru/guru/viewchannel.jsp?EID=39153
Personal FAQ at Java Guru:
http://www.jguru.com/jguru/guru/viewfaqs.jsp?EID=39153
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy):
Politecnico di Milano - Dipartimento di Meccanica



Mime
View raw message