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
>