cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: XMLForm taglib
Date Mon, 15 May 2000 16:50:59 GMT
On 14/5/00 at 4:42 pm, (Sven Kuenzler) wrote:

>I think such a taglib would be very useful to a lot of people. Thus, I
>have retrieved a digest of Jeremies proposal and will respond to it
>below. I also would like to help implementing such a thing.



>>         Logic Contract
>>             Where is that data to go? (XML Fragment, SQL db, email msg etc.)
>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. 


>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.

>>         Content Contract
>>             What data is to be captured?
>>             What are the fields called?
>>             What form element should be used (input, textarea etc.)
>The type of form elements is sometimes a matter of layout. For example,
>you can use radiobuttons or comboboxes (<option> tag) for the same kind
>of choice.

I was thinking along the lines of: do you want lots of text or just one line.
It makes more sense to decide this in the XSL, I guess, ie, in the Design Contract.


>>             Authorisation
>>                 (is this handled by the server?)
>I think so. If you would handle this from Cocoon, this probably would be
>a sitemap thing?

I guess we can leave it to the WebServer for now ...
Only it would be useful to maybe serve different forms depending on user level; admin, author,
user, anon etc. ie allow editing od different fields.

>Another issue is a locking mechanism. If the form data goes to a SQL
>Database, this is probably handled implicitly, but the taglib should
>prevent 2 or more users from writing to the same XML file at the same

Can anyone suggest a strategy for this?


>>         <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.

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.

>>         <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.


>>         <form:field> - defines one field with an id
>>                 <form:glue> - where to place field data in XML node you are
>>                 storing
>What kind of argument would this get? A XPath expression? A node set?
>Should be something that the various sources (sql, xml file,...) can
>provide easily.

I think what we are doing here is to assemble an XML fragment, containing the form data to
be saved, or the reverse in the case of an edit, where you have a structure and you want to
work out which bit to copy to which form field.

So, this acts as the data template for the form. What fields does the user get to change and
how do they map into my XML?

I guess the <glue> is a node path, similar to what Donald uses in XMLForm.

Is there a better way of doing it?

>>                 <form:constraint> - verification information
>>                         <datatype> - String, Integer, Double, Date, URL, 
>>                                      etc.
>>                                 - Standard datatype coersions
>>                                 ie. if it successfully coerces to the type, 
>>                                 it's OK
>>                                 How can we check patterns like phone
>>                                 numbers, credit card etc.?
>May here, the taglib should use types from the XML Schema definition.
>XML Schema has simple types such as string, float, boolean etc. It also
>provides facets to derive own types from it. For example, you can define
>ranges for integer values. Strings can be matched against regular
>The bad thing is that these types do not map 1:1 to Java types, so some
>extra work would need to be done. The good thing is that the Xerces team
>will have to bother about it so we can get this for free someday ;-)

I would much prefer to be doing this when XSchema is a reality .....
But I don't want to wait :)

>>                         <method> - user supplied verification method
>>                 <form:transform> - method to transform data before storage

>>		  (or checking?)
>There should be also an transform option before the data is rendered.
>Just in case someone stores his or her date values in milliseconds since
>1/1/70 ;-)

Good point

>>         <form:action> - what should happen after verification and saving
>>                 <form:trigger> - execute this when done (needs API?)
>What is the difference between <action>, <redirect> and <trigger>?

My example looked like this:


What I meant by it was, when a form is successfully submitted, you will get anything inside
the <form:action> executed.

The <form:trigger>s (maybe it should be<form:method>) allows you to call methods.
And a <form:redirect> allows you to redirect the user somewhere.

>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

> Sven....

Thanks for the response!

regards Jeremy


      Jeremy Quinn                                             media.demon
                                                           webSpace Design
     <>       <>
      <phone:+44.[0].207.737.6831>          <>

View raw message