cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <Giacomo.P...@pwr.ch>
Subject Re: XMLForm taglib
Date Mon, 15 May 2000 08:29:32 GMT
Hi all,

Sven Kuenzler wrote:
> 
> 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 also didn't reply, hoping someone else would (seems everybody thought
so).

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

Definitely!
 
> 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
> check".
> 
> <snip>
> 
> > 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.)

LDAP-Directory, plain file (to make the list more complete and concret)

XML Fragments:	we should take a look into XMLForm from Donald.
SQL db:		Donalds SQL taglib (or a taglib supporting Castor I 
		thought of writing sometimes)
email:		there has been a email taglib somewhere (have to look in the 
		archive)
LDAP:		There already is a LDAP Processor around in Cocoon 1.0. But
		Castor could take care of this, too.

> 
> Another question would be "where does the data come from?" when you
> think about the "edit" mode.

IMHO, this should be covered in the Content Contract!
 
> >             How does the data need to be transformed to fit the storage?

I think this depends on the storage used (see "Where is the data go to")

> >             What are the constraints on the data? (form checking)

Some easy checking syntax should be developed (maybe out of XSL), which
partialy could be transformed (depending on the requesting client) to
Java-Script for client side validation of the data entred.

> 
> >         Style Contract
> >             How should it look?

This should be covered by a stylesheet applied befor serializing to the
client..

> >             What different formats should the form be output in? (HTML, WAP, PDF
etc.)

Also, apply a stylesheet before serializing (sitemap client mapping).

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

I think it should be general enought (maybe w3c's XMLForm) and applying
corresponsing stylesheets to map the clients capabilities.

> 
> >         Content Contract
> >             What data is to be captured?

I don't fully understand this question. Do we mean which part of the
input XML should go into the form and which outside the form (as
descripting data or such things). 

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

Maybe we should leave that to a Filter after XSP processing to map
client capabilities.

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

I think this has nothing to do with a form taglib. The form tags should
be combinable with any other tags available.

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

Authorisation may depend on the authentication method used.
Authentication can be done by the web server (Basic Authentication)
poping you a dialog box to enter userid/password. Can be done by the
servlet container (tomcats form based authentication) also requesting
userid/password. Or can be done by the application itself with a form 
(as Turbine does) reqesting userid/password and maybe other things like
secureid number or alike. And finaly there is also authentication based
on client ceritificates (HTTPS/SSL).

Authorisation is the process mapping a user (evaluated by the
authentication process) to finaly some permissions. This is something
you can discuss forever (as I'm involved with a major customer based on
a project called "general datawarehousing platform"). This is something
mainly done in an application. But if you have general access tools
(like report generator or alike) you should build it also into the
underlying subsystem (database engine, LDAP server, IMAP/POP-Server,
etc). If the application gets the userid/password it might be able to
authenticate the real user of the application against subsystems
involved to delegate authorisation to that subsystem. And so on, and so
on,...

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

Makes sense!

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

This depends on the locking strategy choosen. There are pessimistic and
optimisting locking strategies one could choose to access and modify
data in a store. An other topic is transaction. When will a transaction
start and when will it be commited/rollbacked.

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

As I've mentioned above, some data could have been validated by client
side scripting. But, as I think about it now, could lead to ugly things
(remembering if the client was able to validate data).

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

I think not every aspect can be coverd by a tag. May be there should be
some hooks where a form developer can plug in some (XSP) code for such
things mentioned above.

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

Could also be some (hidden) field values which signals request/response.

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

No real problem. I have a custom taglib which builds functionality based
on standard taglibs and it works (at the moment I don't know if the
order of the namespace definition on the xsp:page/xsl:stylesheet has
some influence. I know the xsp namespace is evaluated as the last step).

> 
> <snip>
> 
> > 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?

Yes, definitely. A example would help very much for discussion!

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

Mime
View raw message