RE: Regarding import of external content, some info on our "Form Parts" feature

John,

Correct me if I'm wrong, but I see this as custom components. There is a bit of tweak that the 'components' are resolved at runtime, but this can be just how your implementation resolves the components (it only looks in the 'archive' created for the form document, the document itself could also be seen as an 'archive' if you want, you can refer inside the document).

For me it seems very close to what is solved in Orbeon by their custom components implementation based on XBL. Erik is better placed to elaborate on this, but what I see are: a binding site in the form (both data and UI), local models, probably some kind of communication between the main form and the 'sub form' using events (you didn't spell this out, but I think you will have it or will need it in the future). Orbeon's solution is also a bit more generic that it doesn't acts as a single group, they can have multiple data bindings to the custom control (again, Erik correct me if I'm wrong).

We are hitting more and more cases in our company that require a 'custom component'/'reusable sub-form' solution. I believe that this is something that should have a high importance on our roadmap, but I don't think that external models and 'custom components'/'reusable sub-forms' are the same thing. External models should be the smaller feature of the two.

Regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com <mailto:nick.van.den.bleeken@inventivegroup.com>
http://www.inventivedesigners.com<http://www.inventivedesigners.com/>
Linked in<http://be.linkedin.com/in/nvdbleek>

From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On Behalf Of John Boyer
Sent: vrijdag 9 april 2010 2:54
To: public-forms@w3.org
Subject: Regarding import of external content, some info on our "Form Parts" feature


Dear Forms WG,

As part of the work of determining how to approach the import of external content, I have been asked to provide some technical information on our "Form Parts" feature, which is related in that it does call for importation of XForms content into a larger XForms, but is not strictly related to the simple use of a src attribute on model or otherwise.

The IBM Lotus Forms team is currently implementing a feature called "Form Parts", and a fair bit of the functionality is currently available in our latest "Tech Preview".

The "Form Parts" feature allows users of our Form Designer environment to create reusable form fragments that may be consumed by any number of form templates in a form collection.
The Design environment can understand any number of Form Parts, and the form author can update any number of form parts before requested to update the form templates that use the updated form parts.

The form templates themselves contain the content of each Form Part they consume plus an indication of where that content came from.  The indicator allows us to do the updating, but having the form part content in the form template means that the form template is always ready to be published to the web without a "compile" step.  In other words, the compile step is loaded onto form part updates rather than as a prerequisite to someone trying to use the form.  Furthermore, it should be clear that the form template is always ready to be used by a run-time XForms processor without it having to load externally referenced content.

In our solution, a "Form Part" can have multiple "components".  In our Tech Preview, you get one component that logically maps to the content of an xforms:group element.  In other words, the component is designed to allow the form author to define a set of user interface elements that are reusable in multiple forms.

When a form author drags and drops such a "Form Part" on the Design canvas, they effectively get a copy of the user interface contained by the main component of the Form Part.  By default, our Design environment automatically generates the underlying XForms instance data model for a form, so a data layer for this UI is automatically created.  However, the design environment is also responsive to more advanced form authors that have designed their own data layer, e.g. according to an XML Schema.  The form part drag and drop opereration automatically brings up a design-time dialog that allows the form author to create a mapping of the UI components onto the existing data model in the form to which the Form Part content is being added.  The form author can click OK without creating a mapping, in which case a data instance for the UI is automatically generated into the form as mentioned above.

The work we are currently undertaking on this "Form Parts" feature recognizes that a form fundamentally has two components, the UI part and the data model part.  So, we are currently enabling our Form Parts to have a second component that contains xforms:model content.  Thus, when the form authors drags and drops a form part onto the design canvas, the UI component would be added by adding an xforms:group to the UI layer, and any xfoms:binds or other model content would be added to the default xforms:model of the form.  This allows us to have a reusable form part that expresses both UI as well as constraints, calculates, etc on the data collected by that UI.

So, in a way, this solution could be seen as another, perhaps easier, way to deal with the larger problem of form composition.  At the run-time level, we seem to always think about subforms and try to solve the problem of data communication between a subform and the form that contains it.  The "Form Parts" solution instead does an injection of markup into two non-continuous locations within a document.  In this way, it is also not like an XInclude or the use of a simple src attribute.  Finally, by virtue of being a Design time mechanism, issues related to ID conflicts are sorted out before the form ever hits the run-time.

The downside of this approach is that it assumes a Design experience distinct from the run-time, whereas the W3C track record on Design environments rarely if ever gets beyond a text editor.

So, even if we were to have a run-time mechanism, my ideal world would be a customized solution that could inject content into at least two non-continuous parts of a form.  Furthermore, despite the fact that our *current* system is based on the Design time, I do see value in moving what we have into a run-time solution because I think it would help to create more interesting "Interactive Web Documents".  But that is another topic with prerequisite reading at [1].

[1] http://portal.acm.org/citation.cfm?id=1600193.1600226

Cheers,
John M. Boyer, Ph.D.
STSM, Lotus Forms
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--

________________________________
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--