cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jerm <je...@media.demon.co.uk>
Subject xml:form [long]
Date Mon, 10 Apr 2000 18:09:48 GMT
Dear All,

With the impetus generated by Pier's organisational efforts, and Donald's endorsement of my
approach:) here are my ideas as to what a generic form handling TagLib could be.

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.

Also I am obviously interested in finding out if this is actually useful to people, if it
is generic enough and conversly, if it is too generic to be useable.

I would like to be able to handle: rendering, verification, error response, saving, editing
existing data, chaining sub-forms. I'd like the ability to: have standard and user-supplied
data verification methods, use sql/files/nodes etc. for storage, include content based on
language selection etc.

I am not recommending here the use of any of the "next-generation" Form technologies in the
XForms spec at W3.org, they appear to be largly client-side dependant.

I am suggesting an XML Markup that allows the structure of a form, the definition of it's
handling, checking, processing and chaining; transformation to HTML(or whatever) can then
be handled with XSL.


Is there a need for this?
It seems to me, that anybody who needs to implement form-based interactivity with Cocoon,
faces a similar set of problems. Providing a TagSet to handle these, saves us from constantly
having to reinvent the wheel.


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.)
	    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.)
	Content Contract
		What data is to be captured?
	    What are the fields called?
	    What form element should be used (input, textarea etc.)
	    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?)
	    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
	    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.

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.

I also assume the SQLTagLib writes as well as it reads.

The next thing I did (lacking the analytical skills of someone like Ricardo :) was to think
about what the markup might look like. I am sure this approach to planning software sucks,
but there you go, I have a design background!



<?cocoon-process type="xsp"?>
<?xml-stylesheet href="form-html.xsl"?>
<?cocoon-process type="xslt"?>
<xsp:page
 language="java"
 xmlns:xsp="http://www.apache.org/1999/XSP/Core"
 xmlns:request="http://www.apache.org/1999/XSP/Request"
 xmlns:form="http://www.foo.com/Form"
>
 <page>
  <form:handler id="first-form-on-page">
   
   <form:store><!-- eg. saves data using XPath to node in existing file -->
    <form:file>
     <filepath type="relative" create="notexists">./saved-forms.xml</filepath>
     <xpath>/forms/form[position()=last()]</xpath>
    </form:file>
   </form:store>
   
   <form:content><!-- eg. includes node using dynamic XPath from a local file  -->
    <form:file>
     <filepath type="relative">form-content.xml</filepath>
     <xpath>/forms/test/<request:get-parameter name="lang"/></xpath>
    </form:file>
   </form:content>
   
   <!-- define a field -->
   <form:field id="field-one">
    <form:glue>/form/name</form:glue>
    <form:constraint>
     <datatype>String</datatype>
     <length-min>1</length-min>
     <length-max>128</length-max>
    </form:constraint>
    <form:transform type="method">my.personal.transform.method</form:transform>
   </form:field>
   
   <!-- define another field, eg. a date -->
   <form:field name="field-two">
    <form:glue>/form/date</form:glue>
    <form:constraint>
     <datatype>Date</datatype>
     <value-min>12 Mar 1998<value-min>
     <value-max>1 Jan 2003<value-max>
    </form:constraint>
    </form:field>
   
   <form:action>
    <form:trigger>org.jerm.cocoon.form.pay.into.bank.method</form:trigger>
    <form:redirect>http://go.to/ta_for_the_form<form:redirect>
   </form:action>

  </form:handler>
 </page>
</xsp:page>

This would define a page with a single form, with two fields.
Pass 1 - (GET Method) the form is rendered into HTML with default values
	or contents of existing document etc. eg. if you are editing, 
	<form:store> and <form:content> are the same.
Pass 2 - (POST Method) the form is verified, saved, actions triggered etc.


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
	
	<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.
	
	<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 | url" 
				- 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
		
		<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.?
			
			<value-min><value-max><length-min><length-max> - etc. 
				- Standard "boundary" tests, dependant on datatype.
			
			<method> - user supplied verification method
			
		<form:transform> - method to transform data before storage (or checking?)
			type="method|logic|regexp" 
			- method call, embedded xsp:logic, regular expression
			
	<form:action> - what should happen after verification and saving
	
		<form:trigger> - execute this when done (needs API?)
		
		<form:redirect> - redirect here when done
		
		

There are proably many other ways to conceptualise this problem al the way through to defining
the tag set.

Maybe there are better ways to encode this information, to make it easier to write to code
to implement it.



There are many unresolved issues and confusions, apart from the fact that I don't really have
a clue what I am doing :)


Is there a better way of rearranging this structure?


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



Does any of this intersect with any form of reality? :)

Response keenly sought!


regards Jeremy





   ___________________________________________________________________

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <mailto:sharkbait@mac.com>     		 <http://www.media.demon.co.uk>
    <phone:+44.[0].207.737.6831>        <pager:jermq@sms.genie.co.uk>



Mime
View raw message