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

Hi Nick,

Yes I agree that we are also essentially saying that simple external model 
is not enough to solve all of the problems faced by our customers, who 
seem to need a more generalized "custom subform component" capability.

Still, external model seemed like a step in the right direction, ignoring 
what we currently do with "Form Parts", even though it doesn't solve the 
problem of combining UI and model declarations into a single reusable 
component.  It seemed like we might at least be able to get some 
instances, submissions and binds that would enable importation of web 
service definitions, for example.

In this regard, it makes sense to talk about "Form Parts" as another 
instance-- not the only one-- of a technology that would be both capable 
of and *likely* to be used as a substitute for simple external model 
importation.

The fact that both "Form Parts" at design time or XBL at run-time could 
also be used to create generalized custom components does not detract from 
the fact that we've seen two categorically different approaches that have 
arisen that would both benefit from having the one standardized way of 
doing the import, even if that import did not scale up to the case of 
generalized custom components.  Whether it has enough value or not, 
without also getting generalized custom components, is of course up to the 
group.

Meanwhile, the reason why a simple external model import cannot scale up 
to generalized custom components seems to be clear also, by looking at 
both the XBL approach and the "Form Parts" approach.  In both cases, two 
different techniques are used to ensure that both UI and model content are 
added to the importing form.   In both cases, the exact point of injection 
into the UI is, and has to be, identified.  The injection point into the 
model does not seem to be so important and is not identifed by either 
approach.  Any kind of "model import" that turned into "subform import" 
would need to add a way to indicate where in the UI should be injected the 
UI portion of the subform.

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






From:
Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
To:
John Boyer/CanWest/IBM@IBMCA, "public-forms@w3.org" <public-forms@w3.org>
Date:
04/09/2010 12:13 AM
Subject:
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 
http://www.inventivedesigners.com

Linked in
 
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, and is believed to be clean. 
--