xsltforms-support

[Xsltforms-support] Subform mechanism implementation in XSLTForms

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

Hello,

Please find below some explanations about how a subform mechanism is 
currently supported in XSLTForms:

In XSLTForms, a subform is a form which could be eventually loaded in a 
stand-alone way.

It contains a model part and a body part. Only HTML is currently 
supported as host language, so the subform body is defined as the HTML 
body inner content.

When loaded from a main form, the model part of the subform is added to 
the model part of the main form. Conflicting ids in models are merged by 
XSLTForms: instances, submissions and bindings are added into the 
corresponding model of the main form. Conflicting ids in instances, 
submissions and bindings are supported by ignoring the conflicting 
elements in the subform.

For management reasons, models and instances without an associated id 
are assigned generated work ids. Currently, XSLTForms always generates 
the same work id whether defined in the main form or in the subform. In 
the future, this might be considered as an option to generate different 
work ids for them.

When loaded, the subform body replaces the inner content of the target 
element. There is no implicit scoping change so the bindings in the 
subform body now depend on the current context of the target element. 
The author has to explicitly force the subform context with an extra 
group control, for example.

A subform can load subforms itself.

When a subform is unloaded, all the elements added to the main form are 
removed as if it had not been loaded at all.

Currently, the xforms-model-construct and xforms-model-construct-done 
are the only events which are dispatched. More events should be 
considered such as xforms-subform-load, xforms-subform-load-done, 
xforms-subform-unload and xforms-subform-unload-done.

XSLTForms uses a unique XForms engine instance to manage subforms. No 
extra mechanism is required to allow communication between main form and 
subforms. Such a mechanism has been implemented in XSLTForms for 
load/@show="new": the new form can interact with the initial form using 
instance/@src and submissions with the resource starting with 
"opener://" followed by the instance id, the calling form been 
considered as a server for the new form.

Regards,

Alain Couthures
agenceXML

Re: [Xsltforms-support] Subform mechanism implementation in XSLTForms

[C. M. Sperberg-M. <cm...@bl...>]

[cc list trimmed]

On Jun 27, 2012, at 7:51 AM, Alain Couthures wrote:

> Hello,
> 
> Please find below some explanations about how a subform mechanism is 
> currently supported in XSLTForms:

Alain, thank you for this helpful description.  
> 
> In XSLTForms, a subform is a form which could be eventually loaded in a 
> stand-alone way.
> 
> It contains a model part and a body part. Only HTML is currently 
> supported as host language, so the subform body is defined as the HTML 
> body inner content.

If (as I think I understand) the right way to do subforms is still
a matter for experimentation, then this is one place where I
might suggest an alternative.  I think it might be useful if the 
calling subform were able to specify one or more IDs of
constructs in the subform and have those count as the subform
body.  

So instead of 

  <xforms:load if="@selected != 'true'" show="embed" targetid="subform" 
  resource="books.xml"/>

the call in writers.xml might read

  <xforms:load if="@selected != 'true'" show="embed" targetid="subform" 
  resource="books.xml#bookdetails"/>

And the books.xml subform would include (for example):

  <xf:repeat id="bookdetails" nodeset="book">

This would allow the subform to contain material like standard
navigation bars and headers, for when it's loaded in a stand-alone
way, without those navigation bars and headers cluttering up
the main form (which presumably already has a header and
navigation bar of its own, if that's the style used by the project
in question.

If the caller does not specify an ID, then taking the children of
/html/body makes sense to me.

> 
> When loaded from a main form, the model part of the subform is added to 
> the model part of the main form. Conflicting ids in models are merged by 
> XSLTForms: instances, submissions and bindings are added into the 
> corresponding model of the main form. Conflicting ids in instances, 
> submissions and bindings are supported by ignoring the conflicting 
> elements in the subform.

So one way to make something in the subform NOT be included 
in the main form would be to give it an ID that conflicts with an ID
in the main form?

> 
> For management reasons, models and instances without an associated id 
> are assigned generated work ids. Currently, XSLTForms always generates 
> the same work id whether defined in the main form or in the subform. In 
> the future, this might be considered as an option to generate different 
> work ids for them.


> 
> When loaded, the subform body replaces the inner content of the target 
> element. There is no implicit scoping change so the bindings in the 
> subform body now depend on the current context of the target element. 
> The author has to explicitly force the subform context with an extra 
> group control, for example.
> 
> A subform can load subforms itself.
> 
> When a subform is unloaded, all the elements added to the main form are 
> removed as if it had not been loaded at all.

This makes me wonder if that is the source of the problem I ran into
in writers.xml:  if you're generating the same IDs for the profiler in both
the main form and the subform, and if the unload process is
accidentally unloading the profiler, because its ID was present in 
the subform, that would explain the problem.

And indeed, the problem is not visible until the user clicks Hide Books
at least once.

Hmmm.

Michael

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Re: [Xsltforms-support] Subform mechanism implementation in XSLTForms

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

Le 27/06/2012 19:25, C. M. Sperberg-McQueen a écrit :
> If (as I think I understand) the right way to do subforms is still
> a matter for experimentation, then this is one place where I
> might suggest an alternative.  I think it might be useful if the
> calling subform were able to specify one or more IDs of
> constructs in the subform and have those count as the subform
> body.
>
> So instead of
>
>    <xforms:load if="@selected != 'true'" show="embed" targetid="subform"
>    resource="books.xml"/>
>
> the call in writers.xml might read
>
>    <xforms:load if="@selected != 'true'" show="embed" targetid="subform"
>    resource="books.xml#bookdetails"/>
>
> And the books.xml subform would include (for example):
>
>    <xf:repeat id="bookdetails" nodeset="book">
>
> This would allow the subform to contain material like standard
> navigation bars and headers, for when it's loaded in a stand-alone
> way, without those navigation bars and headers cluttering up
> the main form (which presumably already has a header and
> navigation bar of its own, if that's the style used by the project
> in question.
>
> If the caller does not specify an ID, then taking the children of
> /html/body makes sense to me.
I know that such a facility is already possible with betterform and I 
will surely consider it for XSLTForms soon!
>
>> When loaded from a main form, the model part of the subform is added to
>> the model part of the main form. Conflicting ids in models are merged by
>> XSLTForms: instances, submissions and bindings are added into the
>> corresponding model of the main form. Conflicting ids in instances,
>> submissions and bindings are supported by ignoring the conflicting
>> elements in the subform.
> So one way to make something in the subform NOT be included
> in the main form would be to give it an ID that conflicts with an ID
> in the main form?
Yes, but only for instances, submissions and bindings!

Thanks!

-Alain