You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jon Lancelle <jk...@knosys.com> on 2000/07/02 20:00:56 UTC
Your favorite way to handle form submissions
Any thoughts on handling form submissions from the client via Cocoon? I
want to start down the right path from square one...
My first inclination is to write a producer. Has anyone used ECS from
Apache successfully in a producer?
How about a simple servlet which either redirects when done to an *.xml
file for continuation or generates some well-formed HTML in response,
complete with links back to the xml model?
Jon Lancelle
Re: Forms proposal
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 09:44 +0200 06/07/00, Nicola Ken Barozzi wrote:
>Hi Jeremy.
>I've seen your mails on the users list.
>I hoped that your taglib would do for me what I needed but unfortunately it
>isn't the case. :-(
I am sorry about that.
Yes, when I saw your proposal, I thought, Hmm, that is better thought out,
but not within my reach yet.
It is meant to be a C1 solution, I would be very happy to begin work on the
ideas that will lead to your suggestion for C2, as it seems a total
re-write will be required for C2 anyway.
Meanwhile, if there are little changes I can make to the current version to
make it more useful to you, please let me know. But, I do want to release
something soon that will solve a needs of C1 users.....
>Correct me if I'm wrong, but it seams that your system unites all my
>scheme on forms in one taglib, definind also (5).
I think you are correct here.
>To make the forms system more versatile, I think that it (the system)
>should be more modular. That's why I made the proposal.
I agree.
I spent a long time trying to get advice on how different TagLibs interact,
so I could build a more modular system. But it just did not lead anywhere.
What the hell I thought, I'll make it work with Files, I can manage that :)
Your modularity appears to be couched largely in terms of C2, something I
do not fully understand.
>Don't get me wrong, I'm not saying what you did is not ok, it just
>has a different goal. For that it's very good. :-)
Cool :)
>But I think that it could be used in the forms system I am writing (on C1 now)
>in stage (5). In that stage I will use the SQL Processor, and yours
>could become a sort of XML processor for manipulating XML files.
>This is just an idea for the future.
>When what I'm writing becomes usable, we'll see what/(if it) can be done.
>Thank you.
Good
>Btw, I'm very curious too about C1-C2 migration.
Me too.
>What recoding needs to be done?
>Will there be a wrapper for Dom processing (legacy) in C2? Seems
>possible to me, DOM is usually based on SAX.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: Forms proposal
Posted by Ross Burton <ro...@mail.com>.
> Pier wrote some DOM-SAX conversion classes that are in cocoon2 right
> now. And there's always JDOM, which I believe can act as a DOM-SAX
> converter.
The DOM -> SAX and SAX -> DOM classes are... interesting to work with, due
to the differences in the SAX and DOM APIs. I'm not sure if this can be
worked around.
I do have an abstract DOMFilter for Cocoon 2 which I'm using to build a SVG
editing filter in which works - if anyone wants it just ask - more eyes
looking at it could make it more elegant and it can serve as an example of
how to use the SAX <-> DOM classes.
Ross Burton
Re: Forms proposal
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 6 Jul 2000, Nicola Ken Barozzi wrote:
> Btw, I'm very curious too about C1-C2 migration.
> What recoding needs to be done?
> Will there be a wrapper for Dom processing (legacy) in C2? Seems
> possible to me, DOM is usually based on SAX.
Pier wrote some DOM-SAX conversion classes that are in cocoon2 right
now. And there's always JDOM, which I believe can act as a DOM-SAX
converter.
- donald
Re: Forms proposal
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Jeremy Quinn" <je...@media.demon.co.uk>
To: <co...@xml.apache.org>
Sent: Wednesday, July 05, 2000 11:17 AM
Subject: Re: Forms proposal
> At 12:49 +0200 04/07/00, Stefano Mazzocchi wrote:
> >> 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.
> >> 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 believe Nicola was proposing to create a sort of infrastructure for
> >"web round-trips":
> >
> > server -> client -> server
> >
> >to simplify what is already possible.
> >
> >But I agree with Niclas that this may just be a layer on top of Cocoon.
> >
> >If this doesn't require any architectural changes, then I'd like to
> >postpone this discussion when we have implemented the sitemap and enough
> >components to test the design.
>
> The XFPTagLib, I'm writing for C1, manipulates external documents according
> to the contents of a Form and the structure of the XML via XPath, using
> some DOM Objects, then wacks out XML results to XSL.
>
> Will such TagLibs work in C2?
>
> Or will they all have to be re-coded for SAX?
Hi Jeremy.
I've seen your mails on the users list.
I hoped that your taglib would do for me what I needed but unfortunately it
isn't the case. :-(
Correct me if I'm wrong, but it seams that your system unites all my
scheme on forms in one taglib, definind also (5).
To make the forms system more versatile, I think that it (the system)
should be more modular. That's why I made the proposal.
Don't get me wrong, I'm not saying what you did is not ok, it just
has a different goal. For that it's very good. :-)
But I think that it could be used in the forms system I am writing (on C1 now)
in stage (5). In that stage I will use the SQL Processor, and yours
could become a sort of XML processor for manipulating XML files.
This is just an idea for the future.
When what I'm writing becomes usable, we'll see what/(if it) can be done.
Thank you.
Btw, I'm very curious too about C1-C2 migration.
What recoding needs to be done?
Will there be a wrapper for Dom processing (legacy) in C2? Seems
possible to me, DOM is usually based on SAX.
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)
Re: Forms proposal
Posted by Donald Ball <ba...@webslingerZ.com>.
> At 20:18 +0200 05/07/00, Giacomo Pati wrote:
> >> Will such TagLibs work in C2?
> >>
> >> Or will they all have to be re-coded for SAX?
> >
> >If you use XSP internal stuff like
> >
> > xspParentNode = xspCurrentNode;
> > xspNodeStack.push(xspParentNode);
> > xspCurrentNode = document.createElement("tr");
> > xspParentNode.appendChild(xspCurrentNode);
> >
> >then I think yes it must be recoded.
>
> Oh dear! :)
> Jeez, it's taken me long enough to get my head around doing this in DOM :)
i think you'll find SAX much easier to work with once you understand the
class structure. it's sort of fire-and-forget when it comes to node
creation.
- donald
Re: Forms proposal
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 20:18 +0200 05/07/00, Giacomo Pati wrote:
>> Will such TagLibs work in C2?
>>
>> Or will they all have to be re-coded for SAX?
>
>If you use XSP internal stuff like
>
> xspParentNode = xspCurrentNode;
> xspNodeStack.push(xspParentNode);
> xspCurrentNode = document.createElement("tr");
> xspParentNode.appendChild(xspCurrentNode);
>
>then I think yes it must be recoded.
Oh dear! :)
Jeez, it's taken me long enough to get my head around doing this in DOM :)
thanks Giacomo
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: Forms proposal
Posted by Giacomo Pati <Gi...@pwr.ch>.
Jeremy Quinn wrote:
>
> At 12:49 +0200 04/07/00, Stefano Mazzocchi wrote:
> >> 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.
> >> 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 believe Nicola was proposing to create a sort of infrastructure for
> >"web round-trips":
> >
> > server -> client -> server
> >
> >to simplify what is already possible.
> >
> >But I agree with Niclas that this may just be a layer on top of Cocoon.
> >
> >If this doesn't require any architectural changes, then I'd like to
> >postpone this discussion when we have implemented the sitemap and enough
> >components to test the design.
>
> The XFPTagLib, I'm writing for C1, manipulates external documents according
> to the contents of a Form and the structure of the XML via XPath, using
> some DOM Objects, then wacks out XML results to XSL.
>
> Will such TagLibs work in C2?
>
> Or will they all have to be re-coded for SAX?
If you use XSP internal stuff like
xspParentNode = xspCurrentNode;
xspNodeStack.push(xspParentNode);
xspCurrentNode = document.createElement("tr");
xspParentNode.appendChild(xspCurrentNode);
then I think yes it must be recoded.
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: Forms proposal
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeremy Quinn wrote:
>
> At 12:49 +0200 04/07/00, Stefano Mazzocchi wrote:
> >> 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.
> >> 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 believe Nicola was proposing to create a sort of infrastructure for
> >"web round-trips":
> >
> > server -> client -> server
> >
> >to simplify what is already possible.
> >
> >But I agree with Niclas that this may just be a layer on top of Cocoon.
> >
> >If this doesn't require any architectural changes, then I'd like to
> >postpone this discussion when we have implemented the sitemap and enough
> >components to test the design.
>
> The XFPTagLib, I'm writing for C1, manipulates external documents according
> to the contents of a Form and the structure of the XML via XPath, using
> some DOM Objects, then wacks out XML results to XSL.
>
> Will such TagLibs work in C2?
>
> Or will they all have to be re-coded for SAX?
very likely.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Forms proposal
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 12:49 +0200 04/07/00, Stefano Mazzocchi wrote:
>> 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.
>> 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 believe Nicola was proposing to create a sort of infrastructure for
>"web round-trips":
>
> server -> client -> server
>
>to simplify what is already possible.
>
>But I agree with Niclas that this may just be a layer on top of Cocoon.
>
>If this doesn't require any architectural changes, then I'd like to
>postpone this discussion when we have implemented the sitemap and enough
>components to test the design.
The XFPTagLib, I'm writing for C1, manipulates external documents according
to the contents of a Form and the structure of the XML via XPath, using
some DOM Objects, then wacks out XML results to XSL.
Will such TagLibs work in C2?
Or will they all have to be re-coded for SAX?
Thanks for any help
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: Forms proposal
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
Subject: Re: Forms proposal
> Niclas Hedhman wrote:
> >
> > Stefano Mazzocchi wrote:
> >
> > > Many others have something to say about this?
> >
> > Is this not a whole different thing??
> >
> > My knowledge of FORMs is basically;
> >
> > The form's fields will be parameters in the URL.
> > Is there any other long-term suggestions on how forms are to be sent from the
> > browser to the server?
> >
> > Sounds to me what you want to do is;
> >
> > Http parameters -> XML -> validate -> destinationtion processor -> response page.
> >
> > 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.
> > 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 believe Nicola was proposing to create a sort of infrastructure for
> "web round-trips":
>
> server -> client -> server
>
> to simplify what is already possible.
>
> But I agree with Niclas that this may just be a layer on top of Cocoon.
I't just the definition of a "framework" that uses cocoon features to help
with forms.
I't "doing forms with cocoon".
> If this doesn't require any architectural changes, then I'd like to
> postpone this discussion when we have implemented the sitemap and enough
> components to test the design.
Ok.
I wanted to see what you all think of my idea before starting it, to see if it
is reasonable.
I need to do it, and I would like to make it good.
Thank you.
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)
Re: Forms proposal
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
>
> Stefano Mazzocchi wrote:
>
> > Many others have something to say about this?
>
> Is this not a whole different thing??
>
> My knowledge of FORMs is basically;
>
> The form's fields will be parameters in the URL.
> Is there any other long-term suggestions on how forms are to be sent from the
> browser to the server?
>
> Sounds to me what you want to do is;
>
> Http parameters -> XML -> validate -> destinationtion processor -> response page.
>
> 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.
> 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 believe Nicola was proposing to create a sort of infrastructure for
"web round-trips":
server -> client -> server
to simplify what is already possible.
But I agree with Niclas that this may just be a layer on top of Cocoon.
If this doesn't require any architectural changes, then I'd like to
postpone this discussion when we have implemented the sitemap and enough
components to test the design.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Forms proposal
Posted by Lars Martin <la...@softwarebuero.de>.
On Die, 04 Jul 2000, you wrote:
> I know of at least 3 companies that transfer XML from client. They usually
> integrate perform the building using another language (ie javascript, java,
> whatever). I think these 3 companies are basically just "Freaks" but it
> will probably be more important in future.
Is it possible to get the names of these companies and/or products you think of?
Are these commercial or open source projects?
Thanks,
Lars
--
________________________________________________________________
Lars Martin lars@softwarebuero.de
SMB - softwarebuero m&b http://www.softwarebuero.de
Re: Forms proposal
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Tuesday, July 04, 2000 1:48 PM
Subject: Re: Forms proposal
> Nicola Ken Barozzi wrote:
> >
> > ----- Original Message -----
> > From: "Niclas Hedhman" <ni...@localbar.com>
> > To: <co...@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?
>
> I didn't write this, Niclas did.
You're right. Sorry.
Sometimes I have to put the ">"s myself and this happens (it shouldn't).
Ken
Re: Forms proposal
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> ----- Original Message -----
> From: "Niclas Hedhman" <ni...@localbar.com>
> To: <co...@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?
I didn't write this, Niclas did.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Forms proposal
Posted by Peter Donald <do...@mad.scientist.com>.
At 04:22 4/7/00 +0800, you wrote:
>What kind of market is there for the browsers that sends XForms??
Currently and in the
>next 6 months.
Let me prefix this with "I know nothing about XFroms" :P but
I know of at least 3 companies that transfer XML from client. They usually
integrate perform the building using another language (ie javascript, java,
whatever). I think these 3 companies are basically just "Freaks" but it
will probably be more important in future.
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Forms proposal
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Niclas Hedhman" <ni...@localbar.com>
To: <co...@xml.apache.org>
Sent: Tuesday, July 04, 2000 10:22 AM
Subject: Re: Forms proposal
> Nicola Ken Barozzi wrote:
>
> > 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.
>
> What kind of market is there for the browsers that sends XForms?? Currently and in the
> next 6 months.
Imo there is no real need now of browsers that do it, sometimes it would
just make things easier.
It could be very important instead for B2B, where the "client" is another server
wanting to send data to the server.
> > 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.
>
> Ok, what you are saying is basically,
> There is a XFormGenerator, that takes the request and streams the SAX events from the
> posted XML.
I would use a "Transformer" (3) for this, because it has to transform the Form in a file
into valid XML by using values gotten from a request.
I think that it's more correct from a transaction point of view (and safer) that it's the
same file that originated the form "questions" that checks for the validity of the response.
> Any processing of the posted data is done as a "Transformer" (formerly a Filter), with
> possible "side effects" such as updating a database, and otherwise streamed down the
> line in a normal fashion.
Basically the valid xml gotten from (3) is "streamed down the line in a normal fashion" (5).
Here is where one or more "side effects" can occur.
> A possibility would then be that the "Validation" stage would be in the Pipeline as a
> Chooser, which then direct the processing according to validation of fields.
Yes, something like it.
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)
Re: Forms proposal
Posted by Niclas Hedhman <ni...@localbar.com>.
Nicola Ken Barozzi wrote:
> 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.
What kind of market is there for the browsers that sends XForms?? Currently and in the
next 6 months.
> 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.
Ok, what you are saying is basically,
There is a XFormGenerator, that takes the request and streams the SAX events from the
posted XML.
Any processing of the posted data is done as a "Transformer" (formerly a Filter), with
possible "side effects" such as updating a database, and otherwise streamed down the
line in a normal fashion.
I buy that. Clean.
A possibility would then be that the "Validation" stage would be in the Pipeline as a
Chooser, which then direct the processing according to validation of fields.
Niclas
Re: Forms proposal
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Niclas Hedhman" <ni...@localbar.com>
To: <co...@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
Re: Forms proposal
Posted by Niclas Hedhman <ni...@localbar.com>.
Stefano Mazzocchi wrote:
> Many others have something to say about this?
Is this not a whole different thing??
My knowledge of FORMs is basically;
The form's fields will be parameters in the URL.
Is there any other long-term suggestions on how forms are to be sent from the
browser to the server?
Sounds to me what you want to do is;
Http parameters -> XML -> validate -> destinationtion processor -> response page.
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.
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.
Niclas
Re: Forms proposal
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> ----- Original Message -----
> From: "Jon Lancelle" <jk...@knosys.com>
> To: <co...@xml.apache.org>
> Sent: Sunday, July 02, 2000 8:00 PM
> Subject: Your favorite way to handle form submissions
>
> > Any thoughts on handling form submissions from the client via Cocoon? I
> > want to start down the right path from square one...
> >
> >
> > My first inclination is to write a producer. Has anyone used ECS from
> > Apache successfully in a producer?
> >
> > How about a simple servlet which either redirects when done to an *.xml
> > file for continuation or generates some well-formed HTML in response,
> > complete with links back to the xml model?
> >
> > Jon Lancelle
>
> I would like to take this mail as an opportunity to discuss about the use of
> forms in Cocoon, and about how it can be done.
Ouch, big issue.... should we postpone this after the sitemap discussion
is finished?
> I know that others have started similar discussions and implementations
> in the past, and I apologise beforehand if I repeat things and are not
> aware of some past conclusions.
> This is my contribution to the subject, I'm waiting comments.
Ok, but I can't guarantee you too much bandwidth on this right now.
> The goal is setting up a new form system that integrates well with
> the notion of content-view separation.
Ok
> The system has to be as flexible, simple and extensible as possible.
Good.
> The starting point is the XForms specification draft on the W3C site.
Good.
> First of all: what is a form?
> Even better: what is a form system?
This is my kind of guy :)
> A form system is a way of inverting the data stream: the data comes
> from the client.
> A form is a way of presenting the "questions" that answered create the
> data sent to the server.
>
> The verb "presenting" suggests that forms are
> a view... so they need stylesheets (1), one for every client type.
> Forms are not only style, because they are also content like any other
> content. You need xml (2) to drive a stylesheet.
> Form data needs to be checked for correctness, so you
> need a validator (3).
> The validator validates against a schema (4).
> Then you need to do something with the data (5).
>
> Looking at the XForm spec you can see that (2) is html, svg, etc.
> We need xml that gets mapped dynamically to those formats.
Yep.
> The following is a scheme of how things can work and what is needed.
> I made two versions hoping all can see it ok.
> (this drawing is for fixed space fonts).
>
> 4) -----------------------
> XML Schema --------| schema file ref |
> | |
> | <xml> |
> | |
> | |
> |<schema element ref/> | (2)
> | |
> | |
> | </xml> |
> | |
> -----------------------
> |
> ----client input ----------|
> | processor (3)
> | |
> XSL(1)------yes-------error in validation?
> |
> no
> |
> -----------------------
> XML Schema --------| schema ref |
> | <next pi> |
> | <root> |
> | |
> | |
> |<element> |
> | |
> | |
> | </root> |
> | |
> -----------------------
> |
> |
> (5)
>
> (this drawing is ok in Outlook).
>
> (4) -----------------------
> XML Schema --------| schema file ref |
> | |
> | <xml> |
> | |
> | |
> |<schema element ref/>| (2)
> | |
> | |
> | </xml> |
> | |
> -----------------------
> |
> ----client input ----------|
> | processor (3)
> | |
> XSL(1)------yes-------error in validation?
> |
> no
> |
> -----------------------
> XML Schema --------| schema ref |
> | <next pi> |
> | <root> |
> | |
> | |
> |<element> |
> | |
> | |
> | </root> |
> | |
> -----------------------
> |
> |
> (5)
>
> Let's see what is missing now:
> (1) need all the stylesheets for all clients.
> (2) We need to define general tags for inserting references to the
> schema in the xml. They are needed by (1).
> (3) Need a processor that uses a schema validator and validates.
> (4) XForms schemas are different from normal schemas.
> We need an XSL that maps between the two.
> (5) I think basic ones are needed, like an SQL insertor or XML insertor
> (there are implementations, we just have to tweak them).
> I think a redirector is very important.
>
> As you see I haven't discussed about how the client interacts, if he
> sends xml or single nodes. I think that it is not that important for
> now as long as the data gets to the server...
> Sending Xml is important when the amount of data sent is not known
> beforehand (arrays). I needed it myself once but imho it is 1% of 90%
> of forms.
>
> Here transactions are not discussed; I think that they should be taken
> care of in (5).
>
> Please let me know what you think of this.
I like your abstract approach and, to be honest, I didn't think about
this hard enough to come up with enough knowledge to see how this
interacts with mine... so I'll let this percolate thru for now...
Many others have something to say about this?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Forms proposal
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Jon Lancelle" <jk...@knosys.com>
To: <co...@xml.apache.org>
Sent: Sunday, July 02, 2000 8:00 PM
Subject: Your favorite way to handle form submissions
> Any thoughts on handling form submissions from the client via Cocoon? I
> want to start down the right path from square one...
>
>
> My first inclination is to write a producer. Has anyone used ECS from
> Apache successfully in a producer?
>
> How about a simple servlet which either redirects when done to an *.xml
> file for continuation or generates some well-formed HTML in response,
> complete with links back to the xml model?
>
> Jon Lancelle
I would like to take this mail as an opportunity to discuss about the use of
forms in Cocoon, and about how it can be done.
I know that others have started similar discussions and implementations
in the past, and I apologise beforehand if I repeat things and are not
aware of some past conclusions.
This is my contribution to the subject, I'm waiting comments.
The goal is setting up a new form system that integrates well with
the notion of content-view separation.
The system has to be as flexible, simple and extensible as possible.
The starting point is the XForms specification draft on the W3C site.
First of all: what is a form?
Even better: what is a form system?
A form system is a way of inverting the data stream: the data comes
from the client.
A form is a way of presenting the "questions" that answered create the
data sent to the server.
The verb "presenting" suggests that forms are
a view... so they need stylesheets (1), one for every client type.
Forms are not only style, because they are also content like any other
content. You need xml (2) to drive a stylesheet.
Form data needs to be checked for correctness, so you
need a validator (3).
The validator validates against a schema (4).
Then you need to do something with the data (5).
Looking at the XForm spec you can see that (2) is html, svg, etc.
We need xml that gets mapped dynamically to those formats.
The following is a scheme of how things can work and what is needed.
I made two versions hoping all can see it ok.
(this drawing is for fixed space fonts).
4) -----------------------
XML Schema --------| schema file ref |
| |
| <xml> |
| |
| |
|<schema element ref/> | (2)
| |
| |
| </xml> |
| |
-----------------------
|
----client input ----------|
| processor (3)
| |
XSL(1)------yes-------error in validation?
|
no
|
-----------------------
XML Schema --------| schema ref |
| <next pi> |
| <root> |
| |
| |
|<element> |
| |
| |
| </root> |
| |
-----------------------
|
|
(5)
(this drawing is ok in Outlook).
(4) -----------------------
XML Schema --------| schema file ref |
| |
| <xml> |
| |
| |
|<schema element ref/>| (2)
| |
| |
| </xml> |
| |
-----------------------
|
----client input ----------|
| processor (3)
| |
XSL(1)------yes-------error in validation?
|
no
|
-----------------------
XML Schema --------| schema ref |
| <next pi> |
| <root> |
| |
| |
|<element> |
| |
| |
| </root> |
| |
-----------------------
|
|
(5)
Let's see what is missing now:
(1) need all the stylesheets for all clients.
(2) We need to define general tags for inserting references to the
schema in the xml. They are needed by (1).
(3) Need a processor that uses a schema validator and validates.
(4) XForms schemas are different from normal schemas.
We need an XSL that maps between the two.
(5) I think basic ones are needed, like an SQL insertor or XML insertor
(there are implementations, we just have to tweak them).
I think a redirector is very important.
As you see I haven't discussed about how the client interacts, if he
sends xml or single nodes. I think that it is not that important for
now as long as the data gets to the server...
Sending Xml is important when the amount of data sent is not known
beforehand (arrays). I needed it myself once but imho it is 1% of 90%
of forms.
Here transactions are not discussed; I think that they should be taken
care of in (5).
Please let me know what you think of this.
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)