cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <je...@media.demon.co.uk>
Subject Re: XMLForm taglib
Date Tue, 16 May 2000 08:10:53 GMT
On 15/5/00 at 10:29 am, Giacomo.Pati@pwr.ch (Giacomo Pati) wrote:

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

Even more thanks to Sven :)

[snip]

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

This sounds good. I think you are implying what I wanted to hear, that different TagLibs are
nestable.

A Tag from a TagLib, just takes XML as "parameters" and out puts modified|other XML as a result.
Is that correct?


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

?? From the XML file you are editing as defined in <form:store> ??



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

That is an interesting approach.

It would be handy to check it on the server side as well as having a JavaScript form checker
built from the <form:constraint>.

While a set of JavaScripts can save bothering the server with a form with obvious things just
not filled in, but you may need to check the relevance of the data on the server, refering
to info only held there.

[snip]

>> >         Style Contract
>> >             How should it look?
>
>This should be covered by a stylesheet applied befor serializing to the
>client..

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

I agree, I don't know about XMLForm though, is it nice and simple :)

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

Do you think it will be possible to write a TagLib that works with both Cocoons?
Or would one have to be written using DOM and the other SAX?

>> >         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 seperate fields? Where the field data goes in the XML? What fields can be edited, by
whom? What data is not to be edited (auto generated, meta structural).

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

Absolutely

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

Yes, but we need to provide any functionality that is needed for generic form processing,
if it is not available in another TagLib. ie. read/write files etc.

[snip]

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

What options do we have?

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

I always found it safer to check on both Client and Server.

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

If it does not hold up the project, lets do it. First lets concentrate on core-functionality
.....


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

Are we going to define a common set of commands/command-fieldnames?
Or set it up so people define their own?

ie. a hidden command form field, switches to a particular <form:handler>?

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

Excellent news!

>giacomo

Thanks for your feedback.

regards Jeremy

      ____________________________________________________________________

      Jeremy Quinn                                             media.demon
                                                           webSpace Design
     <mailto:jeremy@media.demon.co.uk>       <http://www.media.demon.co.uk>
      <phone:+44.[0].207.737.6831>          <pager:jermq@sms.genie.co.uk>




Mime
View raw message