Re: Some questions about dialogs

Hi John,

I agree with your approach of subclassing existing features so that
there is a 'connection' with the existing spec, although I'm not
convinced that xf:repeat really works in this context.

Another way of ensuring that there is a bridge between the current
spec and the new features, though, is to make the new features a
superclass that the existing spec could harmonise with.

So, say we defined xf:dialog like this:

  <xf:dialog singleton="true | false" level="modal | modeless | ephemeral">
    ...
  </xf:dialog>

then you could define xf:message as being an xf:dialog with a default
value @singleton="true".

I'm not proposing this directly, rather I'm just trying to say that as
long as there is a clear bridge between the current spec and the new
feature, it doesn't really matter whether that bridge is forwards or
backwards; the very fact that there is a bridge makes the feature
easier to comprehend, and to define -- it effectively sets its
boundaries.

Just as a general point, the idea of templates isn't really confined
to repeat, since in order to get reasonable performance,
implementations end up having to use templates on switch/case,
messages, relevant groups, and so on.

Regards,

Mark

On Wed, Jun 24, 2009 at 5:09 AM, John Boyer<boyerj@ca.ibm.com> wrote:
>
> 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/
>
>
>
>
>



-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Wednesday, 24 June 2009 09:18:57 UTC