You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Ulrich Mayring <ul...@denic.de> on 2000/10/20 13:39:42 UTC
We need a forms taglib
Hello,
some time ago various people professed to be working on a forms taglib.
Are any of these projects finished? If not, perhaps you can send me your
code and I'll try to incorporate into my bits'n'pieces.
I think we need a forms taglib now, anyway I need it and have decided to
spend a little time on this. I do know about the fp:if-post and
fp:if-get in the fp taglib and will try to incorporate them, but I think
there was more.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: MVC, Struts and Cocoon (was: We need a forms taglib)
Posted by Ulrich Mayring <ul...@denic.de>.
Jeremy Quinn wrote:
>
> >> Basically I have stuff to handle user input via
> >> HTML forms and processing of the input via request parameters. Then I have
> >> definition files, which act a bit like schemas. My idea was that
> >> developers would create definition files (and edit them via fp) and the
> >> rest (forms and processing) would automatically be set up by the taglib.
> >> The whole thing could be called a content management system, it would
> >> allow everything to be edited via fp.
>
> Sounds very interesting.
>
> Can we see it working? This kind of thing with XSchema is a way off IMHO.
Well, you can come to my office and I'll show you ;-)
The question, which I tried to get an answer to, was: is it worth taking
all the distributed bits of code, cleaning it up and putting it in a
centralized taglib? Currently it's a mess of code unsuitable for
publishing. Since I will be one of the last guys on this list to switch
to cocoon2, if I wrote a cocoon1 taglib now, it would have to wait very
long to get ported to cocoon2. So it's better to create something from
scratch for cocoon2.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: MVC, Struts and Cocoon (was: We need a forms taglib)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 23:08 +0100 29/10/00, Giacomo Pati wrote:
>Uli Mayring wrote:
>>
>> On Sun, 29 Oct 2000, Jeremy Quinn wrote:
>>
>> > I had some excellent discussions with Stefano, Giaccomo, Richardo and
>> > Nicola at the Hackathon, about Cocoon 2 and the whole process of supplying
>> > a generic Form Handling mechanism, and while I suspect it is a way off (we
>> > need XSchema) I am beginning to suspect that the solution will involve
>>more
>> > than just TagLibs, it will likely also involve SiteMap Actions, the recent
>> > addition to Cocoon 2 specifically designed for this type of
>> > "web-application" functionality.
>> >
>> > Nicola and I appear to have agreed to push this forward :)
>>
>> Hm ok, so it doesn't make much sense to publish what I have, it will be
>> superseded in the future.
Umm, please don't throw it away !
>> Basically I have stuff to handle user input via
>> HTML forms and processing of the input via request parameters. Then I have
>> definition files, which act a bit like schemas. My idea was that
>> developers would create definition files (and edit them via fp) and the
>> rest (forms and processing) would automatically be set up by the taglib.
>> The whole thing could be called a content management system, it would
>> allow everything to be edited via fp.
Sounds very interesting.
Can we see it working? This kind of thing with XSchema is a way off IMHO.
You can see the glacial pace I am working at the moment ..... this is going
to take some time ..... and I understand Nicola is pretty busy too ....
>The Actions in C2 are separated logic away from the XSP page into a class of
>itself. I think it is not necessarily superseded only refactored and
>separated.
>I visioned having Actions like FormValidationAction which have your
>"definition
>file" loaded as the "src" attribute. Such an Action can return substitution
>strings to the sitemap engine used to determine the resource a generator
>should
>produce. A abreviated sitemap snippet could look like:
>
> <map:match pattern="myuri">
> <map:act type="form-validation-action" src="definition-file">
> <map:generate src="{next-resource}"/>
> </map:act>
> </map:match>
Cool
And, Umm, sorry for mis-spelling your name 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: MVC, Struts and Cocoon (was: We need a forms taglib)
Posted by Giacomo Pati <Gi...@pwr.ch>.
Uli Mayring wrote:
>
> On Sun, 29 Oct 2000, Jeremy Quinn wrote:
>
> > I had some excellent discussions with Stefano, Giaccomo, Richardo and
> > Nicola at the Hackathon, about Cocoon 2 and the whole process of supplying
> > a generic Form Handling mechanism, and while I suspect it is a way off (we
> > need XSchema) I am beginning to suspect that the solution will involve more
> > than just TagLibs, it will likely also involve SiteMap Actions, the recent
> > addition to Cocoon 2 specifically designed for this type of
> > "web-application" functionality.
> >
> > Nicola and I appear to have agreed to push this forward :)
>
> Hm ok, so it doesn't make much sense to publish what I have, it will be
> superseded in the future. Basically I have stuff to handle user input via
> HTML forms and processing of the input via request parameters. Then I have
> definition files, which act a bit like schemas. My idea was that
> developers would create definition files (and edit them via fp) and the
> rest (forms and processing) would automatically be set up by the taglib.
> The whole thing could be called a content management system, it would
> allow everything to be edited via fp.
The Actions in C2 are separated logic away from the XSP page into a class of
itself. I think it is not necessarily superseded only refactored and separated.
I visioned having Actions like FormValidationAction which have your "definition
file" loaded as the "src" attribute. Such an Action can return substitution
strings to the sitemap engine used to determine the resource a generator should
produce. A abreviated sitemap snippet could look like:
<map:match pattern="myuri">
<map:act type="form-validation-action" src="definition-file">
<map:generate src="{next-resource}"/>
</map:act>
</map:match>
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mobil: +41 (0)78 759 7703
CH-8166 Niederweningen Mailto:Giacomo.Pati@pwr.ch
Web: http://www.pwr.ch
Re: MVC, Struts and Cocoon (was: We need a forms taglib)
Posted by Uli Mayring <ul...@denic.de>.
On Sun, 29 Oct 2000, Jeremy Quinn wrote:
> I had some excellent discussions with Stefano, Giaccomo, Richardo and
> Nicola at the Hackathon, about Cocoon 2 and the whole process of supplying
> a generic Form Handling mechanism, and while I suspect it is a way off (we
> need XSchema) I am beginning to suspect that the solution will involve more
> than just TagLibs, it will likely also involve SiteMap Actions, the recent
> addition to Cocoon 2 specifically designed for this type of
> "web-application" functionality.
>
> Nicola and I appear to have agreed to push this forward :)
Hm ok, so it doesn't make much sense to publish what I have, it will be
superseded in the future. Basically I have stuff to handle user input via
HTML forms and processing of the input via request parameters. Then I have
definition files, which act a bit like schemas. My idea was that
developers would create definition files (and edit them via fp) and the
rest (forms and processing) would automatically be set up by the taglib.
The whole thing could be called a content management system, it would
allow everything to be edited via fp.
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: MVC, Struts and Cocoon (was: We need a forms taglib)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
Sorry to be replying to such old messages :)
At 17:25 +0200 21/10/00, Uli Mayring wrote:
>On Sat, 21 Oct 2000, Jeff Turner wrote:
>> For "data collection"-type forms, there is possibility for creating a
>> taglib to automatically populate a bean with form data, ala <jsp:useBean>
>> tags. Struts has this too, I think. A Cocoon version would be very nice..
>
>I don't think the forms management should be connected with Beans, after
>all not everyone uses Beans. It could be put in as an additional option,
>though.
>
>If you look at my auth taglib (or at Jeremy's fp taglib) you'll find that
>we both would have needed a forms taglib, because both our taglibs mainly
>make sense in an interactive application where the user inputs data
>(enters a password in the case of auth or edits XML items in the case of
>fp). Jeremy and I have solved this requirement in different ways, he put
>some additional constructs in his fp taglib, which don't really belong
>there, as they have nothing to do with fp as such. I have put this
>functionality in a stylesheet, which may be a little more appropriate, but
>does nothing for standardisation.
The version of FP currently in Cocoon 1 has three Tags that could be seen
as not naturally belonging to a TagLib that manipulates external xml files
via XPath:
<fp:redirect> redirects user if no errors
<fp:if-get> conditional output depending on HTTPMethod = "get"
<fp:if-post> conditional output depending on HTTPMethod = "post"
There is little option to separate out <fp:redirect> as it requires
knowledge of the FP TagLib's error status, ie. it only redirects if there
have been no errors. There is no standard shared XSP TagLib Error
collection mechanism, so here there is little option here.
The other two, could logically move to the request:taglib as they require
no knowledge of the internals of FP, and are working with
HTTPServletRequest information.
On the other hand, FP(2) the version I am still trying to complete :(
Has new Tags that deal specifically with HTTP Forms:
<fp:form-parameters> converts incoming form data to XML Node
<fp:to-string> serialises XML Node to String (with entities)
written specifically to allow XML to be passed
untouched by the HTMLSerializer to a Form for editing
And two new general purpose logic tags:
<fp:set-variable> set the value of a variable, global to your XSP Page
<fp:get-variable> retrieve the value of your variable
While these two logic tags could move to the util:taglib, the other two are
a much more difficult proposition to separate out.
The main problem is this:
The FP Taglib has Tags that Consume as well as Tags that Generate XML (from
the point of view of the Output Document). This causes big complications
with the LogicSheet, where it has to decide whether to wrap the Java Code
being generated in either an <xsp:expr> (outputs to Output Document) or
<xsp:logic> (outputs to "consuming" tag). The FP LogicSheet needs to know
which Tags are "consumers", it's all rather unpleasant ;)
For example, in the following snippet, the XML generated by the
<fp:form-parameters> tag is "consumed" by the <fp:write> tag and written to
external file, not sent to the Output Document.
<fp:write as="node" to"external-file" select=".">
<fp:get-parameters mode="exclude" name="submit,temp.scope,temp.id">
</fp:write>
While in this example, the XML generated by the <fp:form-parameters> tag is
output to the Output Document.
<your-form>
<fp:get-parameters mode="exclude" name="submit,scope,temp.id">
</your-form>
This problem is quite possibly an artefact of my partial understanding of
how to write TagLibs correctly, in fact I think I have an inkling of a
solution ....
However the next big issue is, how much time and effort should go into
rearranging how TagLibs work in Cocoon 1, when really we should be working
on how their functionality can be ported to Cocoon 2 :)
I had some excellent discussions with Stefano, Giaccomo, Richardo and
Nicola at the Hackathon, about Cocoon 2 and the whole process of supplying
a generic Form Handling mechanism, and while I suspect it is a way off (we
need XSchema) I am beginning to suspect that the solution will involve more
than just TagLibs, it will likely also involve SiteMap Actions, the recent
addition to Cocoon 2 specifically designed for this type of
"web-application" functionality.
Nicola and I appear to have agreed to push this forward :)
Hope this helps ...
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: MVC, Struts and Cocoon (was: We need a forms taglib)
Posted by Uli Mayring <ul...@denic.de>.
On Sat, 21 Oct 2000, Jeff Turner wrote:
> My question is really: are you interested in forms as a navigational
> device, or as a data collection device?
Data collection, i.e. managing user input through input fields, dropdown
menus, buttons etc. - the whole issue includes dealing with HTTP request
parameters, because the form's data is transported through that mechanism,
when a form is submitted.
> For "data collection"-type forms, there is possibility for creating a
> taglib to automatically populate a bean with form data, ala <jsp:useBean>
> tags. Struts has this too, I think. A Cocoon version would be very nice..
I don't think the forms management should be connected with Beans, after
all not everyone uses Beans. It could be put in as an additional option,
though.
If you look at my auth taglib (or at Jeremy's fp taglib) you'll find that
we both would have needed a forms taglib, because both our taglibs mainly
make sense in an interactive application where the user inputs data
(enters a password in the case of auth or edits XML items in the case of
fp). Jeremy and I have solved this requirement in different ways, he put
some additional constructs in his fp taglib, which don't really belong
there, as they have nothing to do with fp as such. I have put this
functionality in a stylesheet, which may be a little more appropriate, but
does nothing for standardisation.
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
MVC, Struts and Cocoon (was: We need a forms taglib)
Posted by Jeff Turner <je...@socialchange.net.au>.
On Fri, 20 Oct 2000, Ulrich Mayring wrote:
> Hello,
>
> some time ago various people professed to be working on a forms taglib.
> Are any of these projects finished? If not, perhaps you can send me your
> code and I'll try to incorporate into my bits'n'pieces.
>
> I think we need a forms taglib now, anyway I need it and have decided to
> spend a little time on this. I do know about the fp:if-post and
> fp:if-get in the fp taglib and will try to incorporate them, but I think
> there was more.
What sort of functionality are you looking for?
My question is really: are you interested in forms as a navigational
device, or as a data collection device?
By navigational, I mean using forms to control where the user visits
next. By data collection, I mean simple "enter your name, age, ..." type
forms.
If you're using forms for navigational purposes, then the Jakarta Struts
project may interest you. Struts implements an Model-View-Controller
framework (http://jakarta.apache.org/struts/users_guide.html). Now before
everyone disregards Struts on the basis of it's association with JSP
("eeww!"), and starts preaching the SoC purity of Cocoon, let me say:
********
The core of Struts that implements the MVC pattern is *independent* of JSP.
********
The JSP form taglib that Struts provides is just one way to talk to the
Struts core MVC engine. To quote Craig McClanahan, the designer:
>> In general, the MVC framework part of Struts
>> can clearly be used by itself, even if you do
>> not use the form based tags (or even if you
>> use something besides JSP to render the user
>> interface.
-- (http://marc.theaimsgroup.com/?l=struts-user&m=86951931906104&w=2)
So we could probably create a Cocoon navigational-form taglib that does
exactly what the JSP taglib does, ie talk to the Struts MVC core.
For "data collection"-type forms, there is possibility for creating a
taglib to automatically populate a bean with form data, ala <jsp:useBean>
tags. Struts has this too, I think. A Cocoon version would be very nice..
<xsp:page>
<form:populateBean name="foo">
<form:setProperty name="attr1" property="propertyattr"/>
</form>
</xsp:page>
<xsp:page>
<form:populateBean name="foo">
<form:setProperty name="*"/> <!-- populates any bean
attributes which have corresponding set request parameters -->
</form>
</xsp:page>
IMHO, Cocoon is great for single complex pipelines, but provides nothing
for website structure and navigation. For that, current opinion seems to
favour the Model-View-Controller pattern, which Struts provides.
Has anyone out there been using Struts and Cocoon together?
--Jeff
(DISCLAIMER: I have used Struts only minimally. I hope I haven't
misrepresented anything)
>
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>