Re: question: handling extremely heterogenous XSDs with XForms

Hi Mark,

On Tue, Apr 28, 2009 at 10:44 PM, Mark Birbeck
<mark.birbeck@webbackplane.com> wrote:
> Hi Joern,
>
>> I actually also thought about the load action but missed the target
>> attribute. I like the solution as it builds on existing standards and
>> avoids a new action. Think i've read your blog post one day but must
>> have forgotten about it again ;)
>
> It was from so long ago, so did I. :)
>
>
>> My + 1 for this solution and i would appreciate if this would be
>> considered for a future version of XForms. The only thing i'm
>> wondering about is how we can deal with real subforms (including
>> models and UI) when embedding.
>
> What sort of issues are you thinking of?
We managed to get most of load embed working in about half a day. In
our first example we used this structure as as example

<xf:model id="main">
....
</xf:model>
<div id="mountpoint"/>

<xf:group>
  <xf:trigger>
     <xf:label>load external model</xf:label>
     <xf:load resource="UrlToSnippet" show="embed" target="mountpoint"/>
.....

The external (embedded) part was a snippet of this structure:
<div>
  <xf:model>
   ...
  </xf:model>
  <xf:group>
    <xf:input ...

  </xf:group>
</div>

This works quite fine. We resolve the external source, parse it,
import it to the host document and then had to add a method to init
the models found in the imported snippet and afterwards initialize the
UI within the same part.

Of course some questions arise:
- how shall we deal with the model events that get dispatched during
'normal' model init as model-construct, model-construct-done and
xforrms-ready. At the moment we simply do just the same as during
standard init and dispatch all these events again but that has to be
reviewed. Especially for model-construct-done the spec says that it's
dispatched only once no matter how many models there are. In the light
of load embed it might be worth thinking about if this event probably
should dispatched for each model.

Further it would be good to support something like:
<xf:load resource="http://somhost.org/myEmbeddedForm.xhtml#modelSnippetId"
show="embed" ....

(note the #)

This would allow to re-use a xforms embedded in an xhtml doc for
instance but only using the snippet identified by id 'modelSnippetId'
instead of having prepared snippets as in my example above.

<html>
.....
<body>
<div id="modelSnippetId">
  <xf:model>
  </xf:model>
  <xf:group>
  </xf:group>
</div>
</body>
</html>

This way the 'snippets' would be runnable standalone as well as being
embeddable in another form (great for testing, modularization and
re-use).

>
> One thing that has changed is that xf:model is no longer limited to
> being in the xhtml:head element in a document, so a subform really
> could be an independent little piece of mark-up that could be reused
> in a number of different forms. We do this a lot already on projects,
> but what would be really great would be to create a library of
> subforms that people can drop into their applications.
Yes, we now using the model in body authoring style for quite a while
now for the reason mentioned by you. Makes it far more easier to
manage 'snippets'.

>
> Or are you thinking about controls in a subform binding to a model in
> the master form? We've tended to treat that in much the same way that
> the dynamic aspects of repeat work.
We thought of that as first guess also but found out during discussion
that we like complete self-contained xforms better for maintainance
and encapsulation reasons. Further the approach of just embedding UI
markup is too limited - as soon as you want a boolean input you're
missing the type MIP and quickly need binds again. Those binds can
hardly be maintained in a master form in a senseful way. So this
approach seems rather limited (at least as long as we don't have X4H).

We are now thinking about two remaining issues that come up with our use case:
- first, if we can load a form there should be way to unload it also.
Of course we can fire another load embed with the same target but
probably more explicit ways (without using an empty dummy or so) can
be found by studying the remaining options of xlink. We have to think
and investigate a bit further on this.

- second, once we have this nice feature of loading new xforms at any
time these will often (as in our use case) fulfill sub-tasks of the
master form. E.g. we need to insert the instance data resulting from
entry in the embedded form into an instance of the main form. So the
questions arises how models can interchange data between each other in
a clean way. We currently a thinking of 'cross-model submissions' as
one possible solution but haven't come to and end in that discussion
yet.

Just one remaining issue with regard to X4H -  though X4H
conventiently wraps one model and its UI into a <form>  this gets a
bit problematic when using the load embed as embedding a <form>
element can get you into trouble with nesting form tags which is not
valid in HTML and will be not be handled by browsers. Just mentioning
that as you might want to mix X4H and full XForms markup with this
technique. Maybe this comes only those implementations into the way
that are transcoding XForms to HTML at runtime as we still do.
>
>
>> And yes we'll quite likely will implement it soon as it's a
>> requirements in the mentioned project.
>
> Excellent. Let's keep talking on the list, so that we make sure we
> converge; as you're probably aware, there is a general feeling at the
> moment in the XForms Working Group that new features for future
> versions of XForms should come from this kind of implementation
> experience, rather than being created in advance of the real uses --
> so this is exactly right.

Thanks for the inspiration - we're very happy with our results so far
though there are surely details to work out

>
> Regards,
>
> Mark
>
> --
> Mark Birbeck, webBackplane
>
> mark.birbeck@webBackplane.com
>
> http://webBackplane.com/mark-birbeck
>
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)
>

Received on Wednesday, 29 April 2009 21:28:20 UTC