xsltforms-support

[Xsltforms-support] server-based select loading

[ac <ac...@hy...>]

Hi Alain,

This seems like a trivial question, but looking around, I have not found 
an answer yet, so I am turning to you.

Along with a main model, some XSLTForms have to display a selector (e.g. 
xf:select1) where the options are typically provided by a server, 
typically on return from a previous form submission.  What is the best 
practice for managing this?  Should the options be part of the model and 
some script in the form loads them to the selector?  can the pre-loaded 
selector be part of the model? is there a better way of doing this?  In 
this case, although it seems preferable, there is no requirement for the 
selector to be xForm, as it could be html, other than it needs to be 
transmitted and received together with the (main) XSLTForms model.  The 
number and exact nature of the selector options do vary according to 
context, previous selections, and submitted model content.  Also there 
is typically more than one selector involved, along with other guizmos 
like checkboxes etc.

Thank you.

Regards,
Andre

[Xsltforms-support] server-based select loading

[Andre C. <ac...@01...>]

Hi Alain,

This seems like a trivial question, but looking around, I have not found 
an answer yet, so I am turning to you.

Along with a main model, some XSLTForms have to display a selector (e.g. 
xf:select1) where the options are typically provided by a server, 
typically on return from a previous form submission.  What is the best 
practice for managing this?  Should the options be part of the model and 
some script in the form loads them to the selector?  can the pre-loaded 
selector be part of the model? is there a better way of doing this?  In 
this case, although it seems preferable, there is no requirement for the 
selector to be xForm, as it could be html, other than it needs to be 
transmitted and received together with the (main) XSLTForms model.  The 
number and exact nature of the selector options do vary according to 
context, previous selections, and submitted model content.  Also there 
is typically more than one selector involved, along with other guizmos 
like checkboxes etc.

Thank you.

Regards,
Andre

Re: [Xsltforms-support] server-based select loading

[ac <ac...@hy...>]

Hi Alain,

This sounds just great.  It seems that my main issue is getting access 
to so XSLTForms examples and documentation. Unfortunately I have not 
found much.  Do you know better?  For example, how would the server 
return a loaded xf:select? as part of the model? in a separate model? 
The separate model sounds just fine.  How should I address each model?  
This is obviously basic usage stuff.  There must some documentation 
somewhere.  I checked the spec, the wiki, XForms.  I get some ideas but 
I need to get operational quick here.  Just a few appropriate examples 
would surely do the trick. Where could I find them?

I am sorry to waste your time with this.

Thank you.

Andre


> Hi André,
>
> XForms instances are basically used to store input values entered by 
> the user but can also be used to dynamically construct and update 
> controls such as xf:select1 or others. Instances can be initialized 
> internally or externally and submissions permit to replace data into 
> them. This can appear on every possible event so a sub-control can be 
> populated dynamically.
>
> Defining different models allows to limit refresh operations. I'm also 
> considering the always read only constraint for performance.
>
> Mixing HTML controls with XForms controls is possible with XSLTForms 
> but not recommended because it requires complex use of Javascript.
>
> Do you have other questions?
>
> -Alain
>
> Le 23/02/2011 16:38, ac a écrit :
>> Hi Alain,
>>
>> This seems like a trivial question, but looking around, I have not 
>> found an answer yet, so I am turning to you.
>>
>> Along with a main model, some XSLTForms have to display a selector 
>> (e.g. xf:select1) where the options are typically provided by a 
>> server, typically on return from a previous form submission.  What is 
>> the best practice for managing this?  Should the options be part of 
>> the model and some script in the form loads them to the selector?  
>> can the pre-loaded selector be part of the model? is there a better 
>> way of doing this?  In this case, although it seems preferable, there 
>> is no requirement for the selector to be xForm, as it could be html, 
>> other than it needs to be transmitted and received together with the 
>> (main) XSLTForms model.  The number and exact nature of the selector 
>> options do vary according to context, previous selections, and 
>> submitted model content.  Also there is typically more than one 
>> selector involved, along with other guizmos like checkboxes etc.
>>
>> Thank you.
>>
>> Regards,
>> Andre
>>
>>
>>
>
>

Re: [Xsltforms-support] server-based select loading

[COUTHURES A. <ala...@ag...>]

Hi André,

Please find attached an example with two xf:select, the second one been 
loaded from the first one.

It appears there is a small issue with XSLTForms: the second xf:select 
is not reseted to "no value" after loading. Mozilla XForms Extension 
handles this example correctly.

Is it what you were looking for?

-Alain

Le 24/02/2011 17:21, ac a écrit :
> Hi Alain,
>
> This sounds just great.  It seems that my main issue is getting access 
> to so XSLTForms examples and documentation. Unfortunately I have not 
> found much.  Do you know better?  For example, how would the server 
> return a loaded xf:select? as part of the model? in a separate model? 
> The separate model sounds just fine.  How should I address each 
> model?  This is obviously basic usage stuff.  There must some 
> documentation somewhere.  I checked the spec, the wiki, XForms.  I get 
> some ideas but I need to get operational quick here.  Just a few 
> appropriate examples would surely do the trick. Where could I find them?
>
> I am sorry to waste your time with this.
>
> Thank you.
>
> Andre

Re: [Xsltforms-support] server-based select loading

[ac <ac...@hy...>]

Hi Alain,

This is quite useful and provides me with a good example.

On the other hand, the issue I am facing is a little different and I 
will try to briefly describe a simplified version and focus on points 
that I am still unsure of, if you do not mind.

I have a first, not too large,  xf:instance that we can call "data" and 
its elements and attributes are mapped to displayed form fields as 
first: string, last: string, for example.

I have an xf:select1 that gets loaded from server calculations including 
database accesses (not from preset files)

This is in a multi-user context, where, for example, the xf:select1 
options depend on user rights or affiliations, as well as context, 
state, and content.

When a user makes a selection in the xf:select, typically, a new "data" 
xf:instance, with the same structure but different content, is 
dynamically generated on the server and returned to the form.  
Accordingly, based on a (state/type) value (that is only changed by the 
server) in an attribute of that xf:instance, the corresponding displayed 
fields can change, where, for example, first and last are now (visually) 
replaced by id: integer, count:integer, date: date

The form also has an "update" button, which when clicked, sends the 
current xf:select1 selected value and the current "data" xf:instance to 
the server, to get a new set of computed values for the xf:select1, as 
well as a new "data" xf:instance (matching the new default xf:select1 
selected value), requiring a new set of display fields to match the 
content of the new "data" xf:instance.

Although there is more, including more buttons and submission types, as 
well as the possibility of local save/load for any xf:instance, they 
remain stable through the different states, and should not affect the 
state dependent strategy at stake here, and for which I have to select 
an approach, that I am still unsure of.

I first considered doing a submit on every change and letting the server 
regenerate a new (version of the) form and send it back to the user.  
That should probably work, but I can see options that may provide a 
possibly more responsive user interface, including having some 
Javascript to dynamically build the appropriate display fields for the 
varying "data" xf:instance cases (there are currently up to 16, quite 
similar, but with some differences).  This dynamic Javascript-based 
display area building may be also quite useful when local-loading the 
xf:model.

I understand that this is quite specific, application oriented, that 
different options may be relatively equivalent, and that you have other 
things to worry about, but if you do have a feel for this, I would 
appreciate your guidance, knowing that in the worst case, I will simply 
let the server regenerate the form at every change (submit), possibly 
allowing local-load only in the proper form context/state.

In any case, thank you.

Regards,
Andre



> Hi André,
>
> Please find attached an example with two xf:select, the second one 
> been loaded from the first one.
>
> It appears there is a small issue with XSLTForms: the second xf:select 
> is not reseted to "no value" after loading. Mozilla XForms Extension 
> handles this example correctly.
>
> Is it what you were looking for?
>
> -Alain
>
> Le 24/02/2011 17:21, ac a écrit :
>> Hi Alain,
>>
>> This sounds just great.  It seems that my main issue is getting 
>> access to so XSLTForms examples and documentation. Unfortunately I 
>> have not found much.  Do you know better?  For example, how would the 
>> server return a loaded xf:select? as part of the model? in a separate 
>> model? The separate model sounds just fine.  How should I address 
>> each model?  This is obviously basic usage stuff.  There must some 
>> documentation somewhere.  I checked the spec, the wiki, XForms.  I 
>> get some ideas but I need to get operational quick here.  Just a few 
>> appropriate examples would surely do the trick. Where could I find them?
>>
>> I am sorry to waste your time with this.
>>
>> Thank you.
>>
>> Andre
>

Re: [Xsltforms-support] server-based select loading

[COUTHURES A. <ala...@ag...>]

Hi André,

> I have a first, not too large,  xf:instance that we can call "data" 
> and its elements and attributes are mapped to displayed form fields as 
> first: string, last: string, for example.
>
> I have an xf:select1 that gets loaded from server calculations 
> including database accesses (not from preset files)
>
> This is in a multi-user context, where, for example, the xf:select1 
> options depend on user rights or affiliations, as well as context, 
> state, and content.
>
> When a user makes a selection in the xf:select, typically, a new 
> "data" xf:instance, with the same structure but different content, is 
> dynamically generated on the server and returned to the form.  
> Accordingly, based on a (state/type) value (that is only changed by 
> the server) in an attribute of that xf:instance, the corresponding 
> displayed fields can change, where, for example, first and last are 
> now (visually) replaced by id: integer, count:integer, date: date
XForms can manage such a situation:

    * an xf:repeat on any element (for example, just "*") will permit to
      have a variable number of input controls
    * the label for each input control can be generated from the name()
      XPath function if there is no attribute, for example, for that
      purpose in the instance
    * bindings in the model, a specific XML Schema or the use of the
      xsi:type attribute will change the input control behavior from
      string to integer or date

>
> The form also has an "update" button, which when clicked, sends the 
> current xf:select1 selected value and the current "data" xf:instance 
> to the server, to get a new set of computed values for the xf:select1, 
> as well as a new "data" xf:instance (matching the new default 
> xf:select1 selected value), requiring a new set of display fields to 
> match the content of the new "data" xf:instance.
The constraint is that only one instance can be serialized for a 
submission. But, you can maintain a dedicated instance just for 
submission, you can also use the resource element to generate a query 
string or a composed URL.

In your example, a unique instance sounds good.
>
> Although there is more, including more buttons and submission types, 
> as well as the possibility of local save/load for any xf:instance, 
> they remain stable through the different states, and should not affect 
> the state dependent strategy at stake here, and for which I have to 
> select an approach, that I am still unsure of.
XForms is powerful enough for this situation because it can be versatile.
>
> I first considered doing a submit on every change and letting the 
> server regenerate a new (version of the) form and send it back to the 
> user.  That should probably work, but I can see options that may 
> provide a possibly more responsive user interface, including having 
> some Javascript to dynamically build the appropriate display fields 
> for the varying "data" xf:instance cases (there are currently up to 
> 16, quite similar, but with some differences).  This dynamic 
> Javascript-based display area building may be also quite useful when 
> local-loading the xf:model.
>
> I understand that this is quite specific, application oriented, that 
> different options may be relatively equivalent, and that you have 
> other things to worry about, but if you do have a feel for this, I 
> would appreciate your guidance, knowing that in the worst case, I will 
> simply let the server regenerate the form at every change (submit), 
> possibly allowing local-load only in the proper form context/state.
I consider that there is no need for replacing all the form at each 
selection. I don't understand why extra Javascript instructions would be 
required for local-loading, the new XSLTForms Java applet should be 
enough, don't you think?

Thanks!

-Alain

Re: [Xsltforms-support] server-based select loading

[COUTHURES A. <ala...@ag...>]

Hi André,

XForms instances are basically used to store input values entered by the 
user but can also be used to dynamically construct and update controls 
such as xf:select1 or others. Instances can be initialized internally or 
externally and submissions permit to replace data into them. This can 
appear on every possible event so a sub-control can be populated 
dynamically.

Defining different models allows to limit refresh operations. I'm also 
considering the always read only constraint for performance.

Mixing HTML controls with XForms controls is possible with XSLTForms but 
not recommended because it requires complex use of Javascript.

Do you have other questions?

-Alain

Le 23/02/2011 16:38, ac a écrit :
> Hi Alain,
>
> This seems like a trivial question, but looking around, I have not 
> found an answer yet, so I am turning to you.
>
> Along with a main model, some XSLTForms have to display a selector 
> (e.g. xf:select1) where the options are typically provided by a 
> server, typically on return from a previous form submission.  What is 
> the best practice for managing this?  Should the options be part of 
> the model and some script in the form loads them to the selector?  can 
> the pre-loaded selector be part of the model? is there a better way of 
> doing this?  In this case, although it seems preferable, there is no 
> requirement for the selector to be xForm, as it could be html, other 
> than it needs to be transmitted and received together with the (main) 
> XSLTForms model.  The number and exact nature of the selector options 
> do vary according to context, previous selections, and submitted model 
> content.  Also there is typically more than one selector involved, 
> along with other guizmos like checkboxes etc.
>
> Thank you.
>
> Regards,
> Andre
>
>
>