cocoon-dev mailing list archives

From: "Jakob Praher" <jpraher@yahoo.de>
> 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.
Great!
Just a few comments on it.
Basically, your idea is to be able to use external data references to use in
form controls, right? So, I'd like the syntax to be as close to W3C XForms
(http://www.w3c.org/MarkUp/Forms/) as possible (and where possible).
There is a 'src' attribute used for linking to external sources:
http://www.w3.org/TR/2002/CR-xforms-20021112/slice3.html#structure-attrs-lin
k .
Also see how the input controls are bound to the instance data using binding
expressions:
http://www.w3.org/TR/2002/CR-xforms-20021112/slice3.html#structure-bind-elem
ent
>
> 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.
There are two ways to make this data avalable on an XMLForm:
1. retrieve it on the server-side and then evaluate all expressions
where this data is referenced
2. generate a special JavaScript on the server-side and then retrieve
the data on request, e.g. when user enters a country code manualy a request
can be sent to server to retrieve the name of the country (or a list of
countries).
>
> 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.
Yes, it's much better to extend the XMLForms transformer to perform this
task.
>
> one proposal would be:
>
> <document>
>
> <xfdata:provider id="states" >
>
> <xfdata:source id="src-states" href="cocoon://data/provinces" />
Or
<xf:instance id="country-list" src="cocoon://data/countries" />
and then you can reference this data in your form controls as:
See more on this:
http://www.w3.org/TR/2002/CR-xforms-20021112/slice3.html#structure-bind-elem
ent
>
> <!--
>
> 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>
The above code looks very similar to a calculated binding expression in
XForms:
http://www.w3.org/TR/2002/CR-xforms-20021112/slice6.html#model-prop-calculat
e
>
>
> 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
These are implementation details that can be decided as we agreed on the
syntax.
>
> 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?
IMO, all the above can be implemented in the XMLForms transformer and XSLT
XForms stylesheet.
Regards,
Konstantin
>
> thanks in advance
>
> -- Jakob
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org