- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Thu, 13 Jul 2006 15:58:14 +0200
- To: 'www-forms' <www-forms@w3.org>
John, 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. -Erik 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: http://www.orbeon.com/blog/
Received on Thursday, 13 July 2006 14:13:23 UTC