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 Thu, 18 May 2000 14:59:39 GMT
On 17/5/00 at 9:29 pm, svenk@gmx.net (Sven Kuenzler) wrote:

Hi Sven,

>> >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.
>
>Is this because you think this is not neccessary or is it something that
>just has to be worked out?

We need to work it out ...
There are so many ways we can go on this .....

Let's say I have a site that implements shared content management.

A whole set of "pages" will share a common structure, and therefore will share a common set
of forms to work with the pages.

I would not want to put the same <xml:form> into each XML content file, and I would
not want one <xml:form> file for each content file.

So my URL would probably want to point to the <xml:form> file, passing the name of the
file to work with, and any special commands.

ie. http://my.org/form.xml?path=content.xml&id=edit 	(Cocoon 1)
or  http://my.org/form.xml#edit?content.xml			 	(Cocoon 1)
or  http://my.org/edit/content 							(Cocoon 2)

I would probably want several different forms for each DTD; one for SysAdmin to edit low level
stuff, several for Authoring (new, edit, delete, move), one for searches, one for users to
add comments etc etc. And then there may be Form Chains.

So we have Forms for function, and Forms for chaining. They could each be in seperate files,
or all inside one, using multiple <form:handler>s.

Can the <form:handler> perform both roles? Maybe something like:

	<form:handler id="command" [next="idOfNextForm"]>
		<form:field id="field-one"/> ......
	</form:handler>

The TagLib would match request parameters to a particular <form:handler> using "id".


Maybe for chaining, the next form ID and intervening values could be held in the user's session?
We'd also need a way for the user to navigate backwards as well as forwards through the chain,
Hmm.

>At least, there has to be some option to define whether we're in add or
>replace mode. You must be able to define whether the captured data
>should be stored in the node that is specified by the XPath (or
>whatever) or after that.

This is the example with the original message, you are right, it is not clear.

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

This sample is supposed to show how to add the form data to an existing file, or a new file
if it did not exist, adding our data to the end. But the XPath could be pointing to an existing
node.

Can we do this?

	<xpath mode="add">/sections/section[position()=last()]</xpath>
	Would add a new node at the end.
	
	<xpath mode="replace">/</xpath>
	Would replace the root.
	
	<xpath mode="replace">/sections/<request:get-parameter name="section"/></xpath>
	Would replace the section named in the parameter.


We need the ability to create new files from a form. How are we going to insert processing
instructions, default elements, entities, etc?

Maybe we need some sort of template?

   <form:store>
    <form:file>
     <filepath 
      type="relative" 
      create="always" 
      template="template.xml"
      suffix=".xml"
      name="blah"
      >./</filepath>
     <xpath mode="replace">/page</xpath>
    </form:file>
   </form:store>

	In this situation, the TagLib would insert the new node, replacing the "page" node in a copy
of the template file, saving it as a new file, making up a unique name from the "name" and
"suffix" attributes, in the directory specified.

<form:file> is becoming a monster!

Maybe the XInclude TagSet (?) could be coerced into this role, in parallel to the SQL, Mail
and LDAP TagLibs. Does it make sense to add writing functionality to XInclude?

>Again, this concerns the xml-file binding. SQL/LDAP etc. provide such a
>thing by default.
>
>> >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.
>
>OK how should the output look like? What kinds of elements would we
>need?

I saw that someone (can't remember who) is using something like this:

	<inputfield name="htmlFormFieldName" value="fieldContents">
		htmlFormFieldDescription
	</inputfield>

I don't think this is flexible enough, how would we do Select or Checkboxes etc.?
Also htmlFormFieldDescription is really Content .....

Maybe we could output something more like this:

	<inputfield name="htmlFormFieldName">
		<value>fieldContents</value>
	</inputfield>

This way, if we have multiple options, we can do this:

	<inputfield name="htmlFormFieldName">
		<value>
			<option value="1">Option 1</option>
			<option value="2" selected="true">Option 2</option>
			<option value="3">Option 3</option>
			<option value="4">Option 4</option>
		</value>
	</inputfield>

I think there is more information that the TagLib ought to be able to send to the StyleSheet.
For instance, hidden fields for commands or form chaining; constraints for clientSide form
checking, and (see below) possible "content" inclusion.

	[] - optional element

	<inputfield name="htmlFormFieldName">
		<value>fieldContents</value>
		
		[<type>hidden</type>] 
		[<contstraint>???</contstraint>]
		[<title>tooltip and mouseover text</title>]
		[<image>urlToButtonImage</image>]
		
	</inputfield>

Even if intervening values from Form Chains etc. were held in the user's session, I think
the TagSet still needs the ability to say "I want this hidden field inserted", it allows the
Logic developer to insert fields independantly of the StyleSheet developer.

If we are to automatically generate, or assist in the generation of ClientSide form checking
code, from the <form:constraint> as was Giacomo's suggestion, we need to think about
what kind of checks can realistically be performed, what kind of data needs to pass around.

It could be as simple as giving the <inputfield> some simple elements like maximum and
minimum length, so the JavaScript is at least checking the forms been filled in. 

<snip>

>> >>         <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.
>
>I guess I misunderstood the meaning of <content> and <store>
>The file in <content> only contains info about the form itself and how
>it is filled in by default? 

Yes

>If the path from the <store> element exists,
>the content found there is used for the fields instead. Correct?

Yes, in terms of an edit.

>So, this <content> file needs a "XSPForms-specific" format? Something
>like form markup language ;)? Or am I still missing the point?

I think a form has "content" regardless of what else is on the page, ie. JavaScripts + clientSide
form checking parameters, MouseOver hints, standardised page content, field descriptors, etc
etc.; 

This content is often shared across a group of forms. We have the choice of having the "content"
of the form coupled to the XML file, using a custom tag, or coupled to the StyleSheet using
entities or inclusion.

Ideally we should allow both couplings to be defined, they have seperate uses.
We also have the option of providing a content coupling by having content in the file that
contains the <xml:form> and just passing it on to the StyleSheet.

We will also need a mechanism to handle multiple languages .... <gulp>

The simplest way of inserting this content, would be to insert the whole xml of the file refered
to in the <form:content>, allowing the StyleSheet to sort out assembly.

If we don't want to give the StyleSheet writer such a big job, we need the content marked
up with names relating to our <form:field>s so we can insert the content into the <inputfield>
elements sent to the StyleSheet.


>> [<form:contraints>]
>> I would much prefer to be doing this when XSchema is a reality .....
>> But I don't want to wait :)
>
>I don't want to either. So let's stick with the constraints from your
>original proposal. Strings still could be matched against regexp. Some
>regexp code for this is available for Cocoon2, can we use it for this
>purpose?

What other standard tests should we be able to perform?

	datatype
	value min/max
	stringlength min/max
	regexp - how would that work? 


>> My example looked like this:
>> 
>>    <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>
>> 
>> What I meant by it was, when a form is successfully submitted, you will get 
>> anything inside the <form:action> executed.
>
>As said above, some <next-form> mechanism should be available here.
>The <action> should taken after the data is stored or before? Or should
>there be an option for both?

I was thinking of after.

>P.S.: What happens if store/xpath matches more than one node? It would
>be useful to have some grouping mechanism or so to convert this to a
>list/option menu.


Do you mean a form:store/form:file/xpath ?
Or a form:field/form:glue ?

I think the first, would have to be a bug in the user's implementation :)
While the second, we'd have to assume we could make a value list

	<value>
		<option ... />
		<option ... />
	<value>
	

>
>> >>         <form:field> - defines one field with an id
>
>> I guess the <glue> is a node path, similar to what Donald uses in XMLForm.
>> Is there a better way of doing it?
>
>Well I guess, this question should be answered by some "taglib guru" ;)
>Basically the question is how can we make taglibs "communicate"?

If anyone in the know, is following this but not responding, some feedback on any of this
would be really appreciated.

Thanks

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