Re: [Proposal] XMLForm: Data Provider
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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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" > > <[EMAIL PROTECTED]> > > Who wrote this: > > Subject: [possible donation] XmlForm popup sample using sourcewriter > > > > And also "Josema Alonso" <[EMAIL PROTECTED]> > > 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" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Saturday, December 21, 2002 3:47 AM > > Subject: Re: [Proposal] XMLForm: Data Provider > > > > > > > Konstantin Piroumian wrote: > > > > The instance: > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > 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 > > > [EMAIL PROTECTED] > > > fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08 > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, email: [EMAIL PROTECTED] > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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" > <[EMAIL PROTECTED]> > Who wrote this: > Subject: [possible donation] XmlForm popup sample using sourcewriter > > And also "Josema Alonso" <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, December 21, 2002 3:47 AM > Subject: Re: [Proposal] XMLForm: Data Provider > > > > Konstantin Piroumian wrote: > > > The instance: > > > > > > > > > John > > > > > > > > > > > > > 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 > > [EMAIL PROTECTED] > > fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08 > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] XMLForm: Data Provider
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" <[EMAIL PROTECTED]> Who wrote this: Subject: [possible donation] XmlForm popup sample using sourcewriter And also "Josema Alonso" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, December 21, 2002 3:47 AM Subject: Re: [Proposal] XMLForm: Data Provider > Konstantin Piroumian wrote: > > The instance: > > > > > > John > > > > > > > > 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 > [EMAIL PROTECTED] > fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] XMLForm: Data Provider
Konstantin Piroumian wrote: The instance: John 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 [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] XMLForm: Data Provider
From: "Konstantin Piroumian" <[EMAIL PROTECTED]>
> From: "Jakob Praher" <[EMAIL PROTECTED]>
>
>
> 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:
John
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
>
> Regards,
> Konstantin
>
> >
> > thanks in advance
> >
> > -- Jakob
> >
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] XMLForm: Data Provider
Am Don, 2002-12-19 um 10.07 schrieb Konstantin Piroumian: > From: "Jakob Praher" <[EMAIL PROTECTED]> > > > 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 > > > > > > > > Austria > > > > > > > > > > <...> > > > > > > > > > > > > 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: > > > > > > > > > > > > > >... > > > > > > ... > > > > > > > > > > > > > > > > writing xsp pages, or other generatos that generate the 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: > > > > > > > > > > > > > > Or > > > 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 > > > > > > > > > > > > type="raw" > > name="country" > > form="offer" > > select="country" > > > > /> > > > > > > > > > name="states" > > match="countries/country[@id=$country]/states/state" > > use="@id" > > /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] XMLForm: Data Provider
From: "Jakob Praher" <[EMAIL PROTECTED]> > 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 > > > > Austria > > > > > <...> > > > > > > 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: > > > > > > >... > > > ... > > > > > > > > writing xsp pages, or other generatos that generate the 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: > > > > > > Or 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 > > > > > type="raw" > name="country" > form="offer" > select="country" > > /> > > > > name="states" > match="countries/country[@id=$country]/states/state" > use="@id" > /> > > > > > > > > > > > > > > > > > > > > > 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: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
