You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jakob Praher <jp...@yahoo.de> on 2002/12/18 18:53:49 UTC
[Proposal] XMLForm: Data Provider
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] XMLForm: Data Provider
Posted by Jakob Praher <jp...@yahoo.de>.
Am Don, 2002-12-19 um 10.07 schrieb Konstantin Piroumian:
> From: "Jakob Praher" <jp...@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
[Proposal] XForm with linking and model item properties WAS:Re:
[Proposal] XMLForm: Data Provider
Posted by Jakob Praher <jp...@yahoo.de>.
hi konstantin,
hi all,
first, thanks for your pointers.
I looked at the various "advanced" xforms constructs and have come to
following solution for realising it in "standard" xforms:
I will first introduce the solution and then put some questions, which
should be settled before implementation starts ...
the solution I found:
============================================================
<!--
somehow, we have to get a handle to the JXPath model, which
is not "really" present in the xml form definition
<instance id="xf:builtin-instance" />
-->
<!--
the instance( ) method is used to get the first
child of the instance element.
so instance( 'x' ) means
<instance id="my-instance" >
<x>
</x>
</instance>
the instance/x == instance('my-instance')
-->
<xf:model name="data">
<instance id="countries" src="cocoon:/data/states.xml" />
<instance id="calc-data" >
<data>
<states /> <!-- this will be calculated -->
</data>
</instance>
<bind nodeset="instance('calc-data')/states"
calculate="instance('countries')/country[@id=instance('xf:builtin-instance')/country]/states"
/>
</xf:model>
<xf:form id="my-form">
<!-- instance('xf:built-in' ) is the default instance? -->
<xf:selectOne ref="/country" >
<xf:caption>select a country ...</xf:caption>
<!-- bind the elments using the itemset element -->
<xf:itemset model="data" nodeset="instance('countries')/country" >
<xf:caption ref="name" /> <!-- the name of the country -->
<xf:value ref="@id" /> <!-- the id of the country -->
</xf:itemset>
<xf:selectOne>
<xf:selectOne>
<xf:caption>select a state ... </xf:state>
<xf:itemset model="data" nodeset="instance('calc-data')/states" >
<xf:caption ref="name" /> <!-- the name of the state -->
<xf:value ref="@id" /> <!-- the id of the state -->
</xf:itemset>
</xf:selectOne>
</xf:form>
+======================================================================+
| questions/problems and orthogonalities: |
+======================================================================+
* how to refer to the model which is kept in the Form.getFormModel( )
and is accessed via JXPath?
----------------------------------------------------------------------------
I propose here a kind of well-known identifier. In my example, I have
used 'xf:builtin-instance' as the name of the instance that resides in
the Form object, and is accessed via JXPath.
We could also use a kind of form( ) method or something like that. but
that is not standard conform.
* there is a instance( ) method to access different instances, but there
is
no method to change the model via XPath.
-----------------------------------------------------------------------------
so we have to suppose that the well known instance 'xf:builtin-instance'
is a member of very model. Otherwise we can't write the binding, as
there is no xpath expression for chaging the model. [ or does the
instance( 'id' ) method work accross models ? ]
* first version will be as simple as possible:
------------------------------------------------------------------------------
the tricky part of the implementation is part of translating the
calculate property to DHTML Javascript Form.
surely it would be interesting to get only the "required" data from the
server. Such a mechanic could be implemented by using data request line,
with which the client can request the data on an as needed basis - this
could probably be implemented using a generic Action Component that,
looks up the data description from the form defnition and serves the
data to the client.
a very "cheap" idea would be to give the client all the data and let him
choose the appropriate data.
the logic can be deduced from the calculate model properties like :
<bind nodeset="instance('calc-data')/states"
calculate="instance('countries')/country[@id=instance('xf:built-in')/country]/states"
/>
javascript:
<script>
/* ------- global data ----------------------- */
instances = { };
/* ------- set up instances ------------------ */
/* static data ... */
instances[ 'countries' ] = [
{ _att_id: 'at', name: 'Austria',
states : [
{ _add_id: 'ua', name: 'UpperAustria' },
{ _add_id: 'la', name: 'LowerAustria' },
/* ... */
]
}, /* next one ... */
];
/* calculated data */
instances[ 'calc-data' ] = { states: null };
function recalculate_data( ctx, src_selector, dest_selector, data ) {
src_selector = dest_selector( data );
}
/* ------- a recalculation global event handler */
function xform_recalculate( ) {
var value = this.value;
if ( this.name == 'country' ) {
/* primitive that sould get generated somehow */
src_selector = function( ) {
return instances['calc-data'].states;
}
dest_selector = function( value ) {
for ( i in instances[ 'countries' ] )
{
if ( instance[ 'countries' ][ i ]._att_id = value )
return instance['countries'][i].states;
}
}
recalculate_data( {}, src_selector, dest_selector, data );
}
}
/* register all handlers for recalculation */
document.forms[ 'my-form' ].country.onChange = xform_recalculate;
</script>
for the sake of simplicity one could write a huge recalculate function
and trigger it based on the dependencies in the calculate xpath.
the transformer also has to track which form elements depend on
calcluated data.
these form elements must be recalculated if the data they depend on is
recalculated too.
for instance:
for every instance data element refered to by a "ref", make function for
refreshing the view
for every bind nodeset with a calculate property make a recalculation
function.
in the recalculate function call those refresh functions that refer to
the recalculated instance data.
the xpath calculate expression to javascript converter could get quite
tricky.
I will experiment with them a bit.
any ideas on this are appreciated.
thanks
-- Jakob
Am Don, 2002-12-19 um 11.04 schrieb Konstantin Piroumian:
> From: "Konstantin Piroumian" <kp...@apache.org>
> > From: "Jakob Praher" <jp...@yahoo.de>
> >
> >
> > 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
>
> Minor addition to this point. Usually, an XForms form contain a defaul
> 'instance' data which is referenced by simple expressions like
> '/customer/name', but you are allowed to use multiple 'instance' data
> objects and you can reference particular 'instance' using instance()
> function, e.g.:
>
> The instance:<xforms:instance xmlns="" id="orderform">
> <orderForm>
> <shipTo>
> <firstName>John</firstName>
> </shipTo>
> </orderForm>
> </xforms:instance>
> and the reference:ref="instance('orderform')/shipTo/firstName"
> The default instance in case of XMLForms is the underlying Form object, so
> this will require support for multiple instances.As for the function in
> referencing expression: it should not be much difficult as XMLForms uses
> JXPath to retrieve values and it's quite easy to add extension functions to
> it.
>
> Konstantin
>
> <snip/>
>
> >
> > 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
Re: [Proposal] XMLForm: Data Provider
Posted by Ivelin Ivanov <iv...@apache.org>.
Hi Jacob,
Yes, I read your message.
Since Konstantin started responding to your questions, I backed off due to
my poor understanding of the subject and current inability to come up with
an elegant design for the implementation.
Konstantin is participating in the W3C XForms discussions, so he would have
a much better guidance than me at this point. As the thread progresses I may
join with some questions and ideas.
Regards,
Ivelin
----- Original Message -----
From: "Jakob Praher" <jp...@yahoo.de>
To: <co...@xml.apache.org>
Sent: Sunday, December 22, 2002 4:16 AM
Subject: Re: [Proposal] XMLForm: Data Provider
> hi Ivelin,
> hi Christian,
> hi Michael,
>
>
> have you looked at my last mail about the introduction of xforms model
> item properties (only the calculate) for calculating depending data and
> linked instances.
>
> it's called "[Proposal] XForm with linking and model item properties"
>
> is anybody working on something like that?
>
>
> thanks
>
> Jakob
>
>
>
> Am Son, 2002-12-22 um 03.58 schrieb Ivelin Ivanov:
> > I am glad that we already have multiple proposed solutions for a
question
> > which has been raised frequently.
> >
> > You should probably synchrinize with "Michael Homeijer"
> > <M....@devote.nl>
> > Who wrote this:
> > Subject: [possible donation] XmlForm popup sample using sourcewriter
> >
> > And also "Josema Alonso" <al...@aafunky.com>
> > Subject: Re: FORMS & Xindice
> >
> >
> > I would be glad to consider applying a patch which was agreed upon the
three
> > of you.
> >
> >
> > Ivelin
> >
> >
> > ----- Original Message -----
> > From: "Christian Haul" <ha...@informatik.tu-darmstadt.de>
> > To: <co...@xml.apache.org>
> > Sent: Saturday, December 21, 2002 3:47 AM
> > Subject: Re: [Proposal] XMLForm: Data Provider
> >
> >
> > > Konstantin Piroumian wrote:
> > > > The instance:<xforms:instance xmlns="" id="orderform">
> > > > <orderForm>
> > > > <shipTo>
> > > > <firstName>John</firstName>
> > > > </shipTo>
> > > > </orderForm>
> > > > </xforms:instance>
> > >
> > > I hope this comment is not completely off: I have checked in a
transformer
> > > that extracts an (arbitrary) fragment and stores it (as DOM) using an
> > > output
> > > module. This can be used to extract form instance data. Coincidently,
it
> > > is called
> > > SimpleFormInstanceExtractionTransformer ;-)
> > >
> > > Actually, I'm planning to look into XMLForms over the hollidays. I
would
> > > really
> > > like it if it were possible to not write a bean for every form. But
this
> > > might be possible
> > > already only that I don't know....
> > >
> > > Chris.
> > > --
> > > C h r i s t i a n H a u l
> > > haul@informatik.tu-darmstadt.de
> > > fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] XMLForm: Data Provider
Posted by Jakob Praher <jp...@yahoo.de>.
hi Ivelin,
hi Christian,
hi Michael,
have you looked at my last mail about the introduction of xforms model
item properties (only the calculate) for calculating depending data and
linked instances.
it's called "[Proposal] XForm with linking and model item properties"
is anybody working on something like that?
thanks
Jakob
Am Son, 2002-12-22 um 03.58 schrieb Ivelin Ivanov:
> I am glad that we already have multiple proposed solutions for a question
> which has been raised frequently.
>
> You should probably synchrinize with "Michael Homeijer"
> <M....@devote.nl>
> Who wrote this:
> Subject: [possible donation] XmlForm popup sample using sourcewriter
>
> And also "Josema Alonso" <al...@aafunky.com>
> Subject: Re: FORMS & Xindice
>
>
> I would be glad to consider applying a patch which was agreed upon the three
> of you.
>
>
> Ivelin
>
>
> ----- Original Message -----
> From: "Christian Haul" <ha...@informatik.tu-darmstadt.de>
> To: <co...@xml.apache.org>
> Sent: Saturday, December 21, 2002 3:47 AM
> Subject: Re: [Proposal] XMLForm: Data Provider
>
>
> > Konstantin Piroumian wrote:
> > > The instance:<xforms:instance xmlns="" id="orderform">
> > > <orderForm>
> > > <shipTo>
> > > <firstName>John</firstName>
> > > </shipTo>
> > > </orderForm>
> > > </xforms:instance>
> >
> > I hope this comment is not completely off: I have checked in a transformer
> > that extracts an (arbitrary) fragment and stores it (as DOM) using an
> > output
> > module. This can be used to extract form instance data. Coincidently, it
> > is called
> > SimpleFormInstanceExtractionTransformer ;-)
> >
> > Actually, I'm planning to look into XMLForms over the hollidays. I would
> > really
> > like it if it were possible to not write a bean for every form. But this
> > might be possible
> > already only that I don't know....
> >
> > Chris.
> > --
> > C h r i s t i a n H a u l
> > haul@informatik.tu-darmstadt.de
> > fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: [Proposal] XMLForm: Data Provider
Posted by Ivelin Ivanov <iv...@apache.org>.
I am glad that we already have multiple proposed solutions for a question
which has been raised frequently.
You should probably synchrinize with "Michael Homeijer"
<M....@devote.nl>
Who wrote this:
Subject: [possible donation] XmlForm popup sample using sourcewriter
And also "Josema Alonso" <al...@aafunky.com>
Subject: Re: FORMS & Xindice
I would be glad to consider applying a patch which was agreed upon the three
of you.
Ivelin
----- Original Message -----
From: "Christian Haul" <ha...@informatik.tu-darmstadt.de>
To: <co...@xml.apache.org>
Sent: Saturday, December 21, 2002 3:47 AM
Subject: Re: [Proposal] XMLForm: Data Provider
> Konstantin Piroumian wrote:
> > The instance:<xforms:instance xmlns="" id="orderform">
> > <orderForm>
> > <shipTo>
> > <firstName>John</firstName>
> > </shipTo>
> > </orderForm>
> > </xforms:instance>
>
> I hope this comment is not completely off: I have checked in a transformer
> that extracts an (arbitrary) fragment and stores it (as DOM) using an
> output
> module. This can be used to extract form instance data. Coincidently, it
> is called
> SimpleFormInstanceExtractionTransformer ;-)
>
> Actually, I'm planning to look into XMLForms over the hollidays. I would
> really
> like it if it were possible to not write a bean for every form. But this
> might be possible
> already only that I don't know....
>
> Chris.
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
>
>
> ---------------------------------------------------------------------
> 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
Re: [Proposal] XMLForm: Data Provider
Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
Konstantin Piroumian wrote:
> The instance:<xforms:instance xmlns="" id="orderform">
> <orderForm>
> <shipTo>
> <firstName>John</firstName>
> </shipTo>
> </orderForm>
> </xforms:instance>
I hope this comment is not completely off: I have checked in a transformer
that extracts an (arbitrary) fragment and stores it (as DOM) using an
output
module. This can be used to extract form instance data. Coincidently, it
is called
SimpleFormInstanceExtractionTransformer ;-)
Actually, I'm planning to look into XMLForms over the hollidays. I would
really
like it if it were possible to not write a bean for every form. But this
might be possible
already only that I don't know....
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] XMLForm: Data Provider
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Konstantin Piroumian" <kp...@apache.org>
> From: "Jakob Praher" <jp...@yahoo.de>
>
>
> 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
Minor addition to this point. Usually, an XForms form contain a defaul
'instance' data which is referenced by simple expressions like
'/customer/name', but you are allowed to use multiple 'instance' data
objects and you can reference particular 'instance' using instance()
function, e.g.:
The instance:<xforms:instance xmlns="" id="orderform">
<orderForm>
<shipTo>
<firstName>John</firstName>
</shipTo>
</orderForm>
</xforms:instance>
and the reference:ref="instance('orderform')/shipTo/firstName"
The default instance in case of XMLForms is the underlying Form object, so
this will require support for multiple instances.As for the function in
referencing expression: it should not be much difficult as XMLForms uses
JXPath to retrieve values and it's quite easy to add extension functions to
it.
Konstantin
<snip/>
>
> 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
Re: [Proposal] XMLForm: Data Provider
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Jakob Praher" <jp...@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