Re: [Xsltforms-support] can one automatically load a sub-form?

[Alain C. <ala...@ag...>]

Michael,

Subforms are loaded with the load action so any event can trigger it. If 
not, this would be an issue and I would be happy to have a test case if 
this happens.

Ids are to be considered with subforms: if no static id is used in the 
subform, generated ids include the generated subform id. But, yet, the 
load action has to copy the subform content according to an id (within a 
repeat, every static id is actually replaced by a generated one). Adding 
AVT support in the load action for the targetid attribute might do the 
trick...

There is also the xf:include/@src control, which is an extension, just 
to include an external file at the XSLT step.

What do you think?

Alain

Le 18/06/2016 à 21:22, C. M. Sperberg-McQueen a écrit :
> Apologies for an ignorant question; my knowledge and understanding
> of the event model underlying XForms is incomplete (in the places
> where it exists at all).  This level of ignorance is compatible with a lot
> of usage of XForms, as long as everything you want to happen is
> triggered by a button press and you can catch it with ev:event
> = "DOMActivate", but I find myself wanting something different for
> the form I'm working on right now.
>
> Subforms can be loaded on a DOMActivate event; this is reasonably
> straightforward.
>
> Can they be loaded on other events?  in particular, can they be loaded
> automatically when an element matches a group in the form?  Or
> when the main form itself is loaded?
>
> Consider two use cases:
>
> A.  A user has done a search in a database and is paging through the
> results.  The back end has sent us $rows-in-page items in the results,
> along with a $total-hit-count number telling us how many hits the
> user's query actually produced, and a $start-row number telling us
> where in the results this extract starts.  For the first page of results, $start-row
> will be 1, and $rows-in-page can be adjusted by the user.
>
> Both at the top of the results display and at the bottom, I want
> two buttons:  a Previous or Back button (iff $start-row > 1)
> and a Next or Forward button (iff $start-row + $rows-in-page
> < $total-hit-count).
>
> The logic, the markup structure, and the CSS styling of the two
> buttons is just complicated enough that the handling of the buttons
> takes up 42 lines in the example I just examined, and they get
> tweaked repeatedly.
>
> Keeping two occurrences of a 42-line block in synch is boring and
> error-prone, and having a full screen or more devoted to such
> secondary concerns makes the form hard to read.  At the moment, I
> handle both of these problems by maintaining the re-used block as
> an external entity, which gets inserted into the main form when I
> run xmllint, rxp, an identity transform, or any other XML normalizer
> to create form.xhtml out of form.xml and its external entities.
>
> But it might be nicer to handle the repeated code by means of a
> sub-form.  To make that work, I would need to have something
> at the locations where the sub-form needs to be loaded which
> causes the loading and which is triggered by an event generated
> automatically when the search results are returned.
>
> Is there a suitable event in the XForms model?  Can anyone point to
> an example of its use?
>
>
> B. In a form I'm writing now, the documents being edited by the user
> consist of a series of top-level children of the document element,
> in a relatively fixed order, each top-level child having a characteristic
> intermal substructure.  Some of the top-level elements have mixed
> content (for which I am using a subform); others have element-only
> content, but sometimes have children (or in some cases, distant
> descendants) which have mixed content.
>
> I would like the user to be presented, on loading a document, with
> read-only displays of each top-level element, and buttons offering
> to edit (a) the top-level mixed-content elements, and (b) the
> second-level elements, some of which have mixed content and
> others of which have other specialized needs which will be handled
> with other specialized sub-forms.
>
> Right now, the main structure of the form has the structure
>
>    <xf:repeat nodeset="*">
>
>        <xf:group ref=".[ ... element has mixed content ...]">
>            ... read/edit switch; read case shows the data; edit case loads
>            mixed-content subform ...
>        </xf:group>
>
>        <xf:group ref=".[ ... element has element-only content ... ]>
>            <xf:repeat nodeset="*">
>
>                <xf:group ref=".[ ... element has mixed content ...]">
>                    ... read/edit switch; read case shows the data; edit
>                    case loads mixed-content subform ...
>                </xf:group>
>      
>                <xf:group ref=".[ ... element has other specialized content ...]">
>                    ... read/edit switch; read case shows the data; edit
>                    case loads suitable subform ...
>                </xf:group>
>
>                ...
>
>            </xf:repeat>
>        </xf:group>
>    </xf:repeat>
>
> Actually, in the current version of the form its worse than this:  the
> read/edit switch for mixed-content elements occurs three times, not just
> twice.
>
> If I could (a) represent the read/edit switch for mixed content as a subform,
> and (b) cause that subform to load automatically at the two different locations
> where it's needed, then I would have less repetition in my code, fewer
> opportunities for unintentional inconsistency, and smaller modules
> which are (probably) easier to understand.
>
> If I can find a way to make this work (and especially if I can find a way
> to make it work recursively), then it might be possible to write XForms
> for documents with less repetition and in a way that feels more like
> the template-driven style of XSLT.  (Where I come from, that would be
> a very good thing.)
>
> Any comments welcome.
>
> Michael Sperberg-McQueen
>
>