cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Praher <jpra...@yahoo.de>
Subject Re: [Proposal] XMLForm: Data Provider
Date Thu, 19 Dec 2002 09:58:30 GMT
Am Don, 2002-12-19 um 10.07 schrieb Konstantin Piroumian:
> 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!
> 

I'll go through your comments in detail. I hope to come up with a better
design - with tight integration on w3c/xmlforms.

Good that I posted, since I have overlooked the src attribute in the
XForm spec.

thanks. I am working on it and inform you.


> 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


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message