cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven Kuenzler <>
Subject Re: XMLForm taglib
Date Wed, 17 May 2000 19:29:51 GMT
> >Another question would be "where does the data come from?" when you
> >think about the "edit" mode.
> The difference between "edit", "new", "delete", etc. are not well defined in 
> my model.

Is this because you think this is not neccessary or is it something that
just has to be worked out?

At least, there has to be some option to define whether we're in add or
replace mode. You must be able to define whether the captured data
should be stored in the node that is specified by the XPath (or
whatever) or after that.

Again, this concerns the xml-file binding. SQL/LDAP etc. provide such a
thing by default.

> >My first approach would be to say that the output of the taglib should
> >happen to be HTML compatible, ie. you could use it with internet
> >browsers without transforming it in any way.
> Seems limiting. I would suggest XML output, transformed to whatever by XSL.

OK how should the output look like? What kinds of elements would we


> >>         <form:hander> - one per form on each page or chain
> >>                 next="id of  next form in chain" - attribute to chain to
> >>                 next form
> >>                 in page. If there are several <form:hander>s with no "next"
> >>                 attribute you get seperate forms on the same page
> >
> >Can you give an example of how to use this chaining?
> Umm, you know like when you have to fill in several form in a row? Each form 
> passes on data to the next one, either I expect through hidden fields, or>
> through sessions.

It was wondering how the taglib logic would be using this handler
element. To be more concrete, your example did not yet show how one form
would reference another (Probably some tag within <form:action>?)

> What I am thinking of is putting in several <form:handler>s each one 
> handling one of the forms in the chain, checking the new input, and passing 
> on hidden fields etc.

Sounds reasonable. Again, the idea needs to be made more concrete.

> >>         <form:content> - included node containing content for the form
> >>                 defines where to find the content to be used in the
> >>                 form,from a file/node,
> >>                 sql query etc. containing default values for fields, error
> >>                 messages, page content, help text etc.
> >
> >I am not sure if things like help texts and page content should bother
> >the form tag lib. In my understanding, its tags should be used within a
> >xml page that represents the page the form lives in.
> I don't know, I quite like it. Maybe we can see if we get around to it. I'm 
> sure this is not too irksome to do with XSL.

I guess I misunderstood the meaning of <content> and <store>
The file in <content> only contains info about the form itself and how
it is filled in by default? If the path from the <store> element exists,
the content found there is used for the fields instead. Correct?

So, this <content> file needs a "XSPForms-specific" format? Something
like form markup language ;)? Or am I still missing the point?

> >>         <form:field> - defines one field with an id

> I guess the <glue> is a node path, similar to what Donald uses in XMLForm.
> Is there a better way of doing it?

Well I guess, this question should be answered by some "taglib guru" ;)
Basically the question is how can we make taglibs "communicate"?

> [<form:contraints>]
> I would much prefer to be doing this when XSchema is a reality .....
> But I don't want to wait :)

I don't want to either. So let's stick with the constraints from your
original proposal. Strings still could be matched against regexp. Some
regexp code for this is available for Cocoon2, can we use it for this

> My example looked like this:
>    <form:action>
>     <form:trigger></form:trigger>
>     <form:redirect><form:redirect>
>    </form:action>
> What I meant by it was, when a form is successfully submitted, you will get 
> anything inside the <form:action> executed.

As said above, some <next-form> mechanism should be available here.
The <action> should taken after the data is stored or before? Or should
there be an option for both?

> >In this case we could split the problem in two sections: the form
> >handling itself and the data source connection. For databases, the
> >sql-taglib would be ready. Thus, we'd need something similar for
> >accessing XML via XPath.
> Seems fair enough

When I wrote this, I confused the meaning of <contents> and <store>
(Maybe I still do?) 

Maybe there is no need to split this into another lib anymore. 


P.S.: What happens if store/xpath matches more than one node? It would
be useful to have some grouping mechanism or so to convert this to a
list/option menu.

View raw message