Re: Some questions about dialogs

Hi Erik, 

Actually, I think we're talking about the same thing, but we're talking 
about two different ways of achieving it.

An author wants to write one dialog template and, at run-time, instantiate 
it multiple times with different parameterizations each time.

One way to do that is to dispatch xforms-show multiple times to the same 
dialog markup, and use event context information for the 
parameterizations.

A second way to do that is to wrap a repeat around the dialog and let the 
number of data nodes in the repeat nodeset determine how many copies of 
the dialog template are created.  Via in-scope evaluation context, the 
repeat nodes provide parameterization for the copies of the dialog. 

The discussion was about whether the first method needed to be added right 
now as a means of implementing the ability to multiply instantiate a 
dialog.  I was supporting the decision not to add that implementation 
because there did exist a second means of implementing the feature using 
the simpler dialog construct in combination with pre-existing language 
features.  It isn't quite as nice to use, but it is not too hard, gets the 
job done, and lets us focus on getting the primary feature specified 
without being overburdened with complicated methods that are not strictly 
necessary even to get the secondary feature of multiple instantiations.

Cheers,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
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:
Erik Bruchez <ebruchez@orbeon.com>
To:
Forms WG <public-forms@w3.org>
Date:
06/23/2009 08:31 PM
Subject:
Re: Some questions about dialogs



John,

I think we are talking about different things:

1. Dispatching multiple xforms-show events to xf:dialog opens that 
dialog more than once.
2. Putting dialog in a repeat as a way of creating multiple runtime 
objects associated with fr:dialog.

I think that the exchange between Nick and I was mostly concerned with 
#1 above.

This said, sure there are use cases for both, but I don't find them 
very compelling.

My feeling is that in practice, 1% of use cases would benefit from the 
"multiple open" functionality, but on the other hand this will require 
probably doubling the amount of wording in the spec related to 
fr:dialog to describe the processing model, and increase the 
complexity of implementations accordingly.

Practically, I don't believe that the YUI dialog, for example, 
supports multiple concurrent openings. An implementor would have to 
duplicate DOM subtrees, adjust ids, etc. to support this. It is 
certainly doable (after all this is done for repeat already) but there 
is a clear implementation cost.

So at this point I don't think the spec should mandate that 
implementors support this.

-Erik

On Jun 20, 2009, at 11:33 AM, John Boyer wrote:

>
> Even accepting that the run-time dialog is mapped directly to 
> markup, same as a group or a switch case, doesn't "close the door" 
> on using it multiple times simultaneously because we have XForms 
> repeat.
>
> The repeat wraps around the dialog and makes one for each node in 
> the nodeset.  Each dialog stores its data within the subtree of that 
> node.  Making a new dialog is an insert.  One would still separately 
> show and hide the new dialog.  In order to do so from outside the 
> repeat, one would have to first set the repeat index, then show the 
> identified dialog.
>
> Sure the bit about the repeat index is a bit less direct than ideal, 
> and sure it would be nicer to have the dialog component contain its 
> own data model to be created any time the component is instantiated, 
> but given how relatively rarely we expect multiple simultaneous 
> instances of the same dialog, it seems reasonable to allow it to be 
> a bit harder to do in our first release of XForms dialogs.
>
> The main thing is that we've thought through this enough to know 
> that the simpler dialog construct we're adding now has no technical 
> obstacle that would prevent it from being used later with a 
> component or subform technology.
>
> Cheers,
> John M. Boyer, Ph.D.
> STSM, Interactive Documents and Web 2.0 Applications
> Chair, W3C Forms Working Group
> 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:
> Erik Bruchez <ebruchez@orbeon.com>
> To:
> Forms WG <public-forms@w3.org>
> Date:
> 06/20/2009 10:43 AM
> Subject:
> Re: Some questions about dialogs
>
>
>
>
> Nick  / all,
>
> > Until we know better how we will handle components I will write the
> > text so that only one instance of a dialog can be open at once.
>
> I also think now that it is better not to add all that complexity to
> the specification and implementation, for a feature which will be used
> only very rarely.
>
> Further, we are not closing the door to supporting this in the future
> if really needed.
>
> -Erik
>
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
>
>
>
>

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/