cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven Kuenzler <>
Subject XMLForm taglib
Date Sun, 14 May 2000 14:42:41 GMT
Hi all,

lately, there were discussions on the cocoon-users list about how to
interconnect HTML forms and XML documents.

Jeremy posted a proposal for a taglib for this task a month ago but
nobody replied.

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.

Now, I won't claim that I have the ultimate idea of how such a tag lib
must look like (Jeremy said something similar). Therefore, it would be
nice if others could comment as well, so that this gets some "reality

My background: I am currently converting parts of the old HTML website 
of my group to XML data bases. This includes things like a bookmark
list, a bibliography, project descriptions & status, jobs offers, ... 

In order to make the maintainance easier, all those shall be editable by
HTML forms over the web. The functionality needed is basicly
add|edit|remove entries, no fancy ecommerce/business processes ;-)

> --- Enclosed is a copy of the request I received.


> Please keep in mind that this is at a very early stage ...


> I don't fully understand XSP yet, so I need help working out if what I am 
> trying to do is going to be possible, and if there are better ways of 
> defining things.

Same for me. I looked at the taglib code that comes with Cocoon 1.7.3
(sql, util, cookies,...), but for me there is still a lot of "magic" in


> What should an xml:form tablib be able to do?
> First, in terms of "the seperation of contracts":
>         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. 

>             How does the data need to be transformed to fit the storage?
>             What are the constraints on the data? (form checking)

>         Style Contract
>             How should it look?
>             What different formats should the form be output in? (HTML, WAP, PDF etc.)

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.

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

>             What are the default values for the form?
>             What should you get when you fill in the form correctly?
>             What is the content of the page the form is in?

> Second, in terms of functionality:
>         The Form is rendered (method="GET")
>             Authorisation
>                 (is this handled by the server?)

I think so. If you would handle this from Cocoon, this probably would be
a sitemap thing?

>             Choose Browser
>                 (sitemap switches stylesheet?)
>             Collect page content from anywhere as an included node
>                 (based on user-lang or some other context)
>             Collect Form Field default values
>                 (based on user-lang or some other context)
>             Collect Form Field "inherited" values (optional)
>                 (Maybe someone is correcting or editing existing data or
>                 form submission)
>             Assemble the Form
>         The Form is submitted (method="POST")
>             Authorisation

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

>             Convert PostArgs (or "GetArgs") into an XML Node, using "glue" to
>                 define which Field goes into which Element.
>             Check the data.
>                 too long, too short, coercable to correct data-type,
>                 valid URL/email address, whatever ...
>             Data Action
>                 Storage: static or calculated FilePath/XPath expression, SQL
>                     connection defs, email address, etc.
>                 Trigger: Method to invoke with Form XML
>                     Maybe we are controlling a Robot or linking to a
>                     Merchant Server
>             Generate response
>                 Send back the pre-filled form, with error messages if
>                 incorrect
>                 Redirect to, or assemble response page
>                 or chain to next Form (pre-filling accepted data 
>                 into hidden fields)

> The first thing to note, if you have not worked it out already .... the 
> taglib responds differently depending on request method, I assume this is 
> possible.

The request method can be queried, so this should be no problem.

> Next I assume that it is possible to mix namespaces, ie. accessing SQL, 
> filespace, custom classes etc. for standard opperations like 
> reading/writing, verification, custom actions, etc.

This was a thing I was wondering about when I first saw the existing
taglib stylesheets. All of them have a template for xsp:page where they
do their initialisation stuff. What happens when ie. SQL and Cookie tags
get mixed?


> The Tags:
>         <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?

>         <form:store> where form data is sent for storage
>                 Can contain form:file, sql:connection-defs, mail:compose 
>                 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.

>         <form:file> - depending on context, you want to read (include) or
>                 write to nodes in a file
>                 <filepath> - where to find the file
>                         type="relative | root | full | xlink | sitemap | 
>                                 - what type of filepath is it?
>                         create="always | never | notexists"
>                                 - should new files be created on the server?
>                 <xpath> the XPath expression
>                 hopefully both these elements can contain tags from other 
> 		  namespaces so you can do dynamic selection

>         <sql:connection-defs>
>                 - depending on context, you want to get nodes by querying
>                 SQL, write to/modify the node and overwrite the record.
>                 you might be querying multiple records to get content or 
>                 only one
>                 record if you are editing
>         <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.

>                 <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 ;-)

>                         <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 ;-)
>         <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>?

> How does a Schema fit into this? Don't understand Schemas, but someone 
> talked about using them to define what gets edited by whom.

Schemas are the next generation "DTDs". A Schema defines Content Models
of  XML entities (read "files"). The new things are name space support
and "real" data typing (plus many others).

Thus, one could dream of an application that reads a schema definition
and outputs a form that lets you enter valid data according to that
schema. But due to the complexity of schemas, this would be a lot of

Well, where to go next? The central question would be how to design the
interconnection between <data source> <-> <form taglib>

Is it possible/sensible to mix tags from different tag libs? IE:

   <form:glue><sql:query (?)><form:glue> 

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.


View raw message