W3C home > Mailing lists > Public > www-forms@w3.org > July 2006

Re: Use cases for multiple models

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Thu, 13 Jul 2006 15:58:14 +0200
Message-ID: <44B65176.8090604@orbeon.com>
To: 'www-forms' <www-forms@w3.org>


Interesting comment about the portal use case! I guess this is more of
a use case for a client-side implementation though. With an
server-side Ajax implementation like OPS's, this is not very relevant
so I never though about it

As a BTW and slightly off-topic, but that can be food for thoughts for
other implementors, OPS now supports multiple portlets containing
XForms in the Liferay portal (the only portal tested so far, but other
JSR-168-compliant portals should work as well), and we handle all the
ids and namespacing automatically: you just don't have to care that
there are other forms around in other portlets, and you write your
form as if it was running in a non-portal environment.

The same kind of transformation could probably be applied to a
client-side form engine dealing with a portal page, although in that
situation you have to also deal with all references to ids as you
produce the page, including things like ref="instance('my-instance')",
which is harder. In the server-side case, we can resolve namespacing
as we execute the XPath expression, which is simpler.

So I understand why using multiple models then would be the preferred
solution for a client-side engine.


John Boyer wrote:
 > Hi Eric,
 > I believe that using XForms in a portal environment is the use case
 > main use case.
 > Logically, I think we want the notion of one form, one model.  We
 > also want one portlet, one form.
 > But for client-side web browser implementations, this means there
 > could be one model and set of UI controls per portlet, so the XForms
 > processor reading the XHTML for the whole portal has to be able to
 > deal with multiple models.
 > Unfortunately, an XForm does not get off scott-free of modifications
 > to be used in a portal environment.
 > The IDs of the models have to be made unique, and each portlet's set
 > of XForms controls need to be qualified with the proper model
 > identity.  This could be as simple as wrapping the controls of the
 > portlet in a group with the single-node binding of model='x' and
 > ref=".".  Not hard, but still something that needs to be done.
 > However, a lot of the mixed model tip-toeing that we have been doing
 > for context resolution and for action sequences that can
 > *theoretically* touch multiple models is really not to address this
 > main use case but rather to deal with the nuclear fallout that
 > results from allowing more than one model in a host document.

Orbeon - XForms Everywhere:
Received on Thursday, 13 July 2006 14:13:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:18 UTC