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