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
****************************************************************