cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Praher <>
Subject [Proposal] XMLForm: Data Provider
Date Wed, 18 Dec 2002 17:53:49 GMT
hi Ivelin,
hi all,

for the last project I used a self-brewed, but kind-a grown, form
handling mechanism.

now I'm going to use Cocoon XMLForms, because the more people use it the
better it gets ( instead of inventing the wheel again ) and I like its
closeness towards w3c/xmlforms.

now to my idea:

often you have data-source, which provides you with changeable data.

take for instance countries and states (not very dynamic I agree, but
for the sake of simplicity I will use this example).

so you have xml-data,  which can be "GENERATORED" by litteraly anything
( a file on the filesystem, ... ):

A) the data

<country id="at">

    <state id="xy"><name></name></state>

and a xml form. The question is how to intermix the data with the form,
in a very easy but powerful way.


Now we have this wonderful xform document:

<document xmlns:xf="..." xfdata=".:">

<xf:form id="..." >

  <selectOne ref="/country" >
  <selectOne ref="/state"   >



writing xsp pages, or other generatos that generate the <xf:items> is
one way, but I think this scenario is very frequently used and so it
would be better to provide a more "integrated" framework.

one proposal would be:


<xfdata:provider id="states" >
        <xfdata:source id="src-states" href="cocoon://data/provinces" />
	raw - 	read after write means this value must be 
		known prior to 	calculating the values.
		this can be done using the client side "change" event
	<!-- the dependency could also be stated directly in the xform ... -->
	<!-- the key -->



<xf:form id="offer">
	<xf:selectOne id="country"  ref="/country">


	<xf:selectOne id="state"  ref="/state">
		<xfdata:choices use="states" > <!-- here use means a provider/key  -->
			<!-- the dependency could go here too, so that proivders would be
form independent -->

			<xf:caption xfdata:bind="name" />
			<xf:value   xfdata:bind="@id" />


to make this work, one has to write a custom translator, as xslt can't
have global state that changes (variables are immutable). (except when
using extension mechanisms).

and my approach would be:

1) gather all the providers together in a list.
2) go through the xf:form and consume all xfdata:elements

3) write out different versions based on:

-> client side javascript
-> soap ? (+client side javascript :-) )
-> static ( that will be difficult )

does anybody have a cleverer way to do the above - what are your ideas?

thanks in advance

-- Jakob

To unsubscribe, e-mail:
For additional commands, email:

View raw message