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
<countries>
<country id="at">
<name>Austria</name>
<states>
<state id="xy"><name></name></state>
<...>
</states>
</country>
</countries>
and a xml form. The question is how to intermix the data with the form,
in a very easy but powerful way.
B) The XFORM
Now we have this wonderful xform document:
<document xmlns:xf="..." xfdata=".:">
<xf:form id="..." >
<selectOne ref="/country" >
...
</selectOne>
<selectOne ref="/state" >
...
</selectOne>
</xf:form>
</document>
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:
<document>
<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 ... -->
<xfdata:dependency
type="raw"
name="country"
form="offer"
select="country"
/>
<!-- the key -->
<xfdata:key
name="states"
match="countries/country[@id=$country]/states/state"
use="@id"
/>
</xfdata:provider>
....
<xf:form id="offer">
<xf:selectOne id="country" ref="/country">
</xf:selectOne>
<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" />
</xfdata>
</xf:selectOne>
</xf:form>
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
