Re: The message action is for messages, not arbitrary dialogs

All,

John's arguments are quite convincing to me. We have implemented a
dialog extension in Orbeon forms along those lines, and the reasons
for this decision included:

o xforms:message doesn't even hint in XForms 1.0/1.1 that it can be
   used for a dialog. You have to dig deep into the spec and schema to
   infer that, maybe, and with a significant amount of stretching,
   xforms:message can be understood to mean "xforms:dialog".

o I like explicit over implicit. If you say "message", you mean
   message. I don't know of any user interface framework that uses the
   term "message" to also mean "dialog".

o We figured it made more sense to make the dialog container a
   top-level element within the controls, and to use actions
   (show/hide) to show and hide the dialog, very much like what we do
   now with xforms:case and xforms:toggle. This addresses the following
   issues:

   o Event bubbling is problematic and at best confusing if your dialog
     controls are embedded in an action.

   o You may want to open and close a dialog from different event
     handlers without duplicating your dialog or requiring dispatching
     custom events.

-Erik

John Boyer wrote:
 >
 > Hi Leigh,
 >
 > Thanks for digging up the early minutes on this issue.  The struggle
 > between allowing the (error) message to be only plain text versus
 > allowing host language markup to dress up the message can be seen.
 > It seems pretty clear that not a lot of consideration is given to
 > bending message into something that can do full dialogs.  Otherwise, the
 > content model just within XForms would not be just a mix of characters
 > and output elements only.
 >
 > Cheers,
 > John M. Boyer, Ph.D.
 > STSM: Workplace Forms Architect and Researcher
 > Co-Chair, W3C Forms Working Group
 > Workplace, Portal and Collaboration Software
 > IBM Victoria Software Lab
 > E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/
 >
 > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
 >
 >
 >
 >
 > *"Klotz, Leigh" <Leigh.Klotz@xerox.com>*
 > Sent by: www-forms-request@w3.org
 >
 > 12/04/2006 05:28 PM
 >
 > 	
 > To
 > 	John Boyer/CanWest/IBM@IBMCA, <www-forms@w3.org>
 > cc
 > 	
 > Subject
 > 	RE: The message action is for messages, not arbitrary dialogs
 >
 >
 > 	
 >
 >
 >
 >
 >
 >
 > Date: June 19, 2001
 > - error
 > Sebastian: "error"?
 > Micah: What about just "message"?
 > Roland: We haven't talked about the processing model for "error message".
 > We have talked about caption, hint, and help.
 > Micah: We could merge them because they have the same content model.
 > Roland: They do different things.  The issue is the processing model.
 > Sebastian: How about "alert"?
 > Leigh: Then it will have a JavaScript alert box.
 > Sebastian: Not on cell phones.
 > Doug: So is it for failed validation?
 > Sebastian: No.
 > TV: The help is shown when the user asks for help; the hint when the
 > user hovers; the caption next to the item.  We need to decide when the
 > alert is shown.
 > Sebastian: So we could have an action that triggers it.
 > TV: So we have two proposals: add an alert element as a peer to
 > hint/caption/help, and the processing model says to show it when there
 > is an alert inside a widget and will be shown when validation fails.
 > Also add an alert action handler.  You can use this for rollovers.
 > Micah: And add action for hint and help.
 > Sebastian: For example you can define an alert in a button element
 > (which has no validation) and trigger that.
 > Josef: What is the content model?
 > Sebastian: Plain text.
 > Josef: That's different from help and hint.
 > TV: If XHTML is the host language, then the content model for help and
 > hint is XHTML; it's wrong for us to over-specify it.
 > Micah: The content model for help, hint, and alert is #ALL.
 >
 > ------------------------------------------------------------------------
 > *From:* www-forms-request@w3.org [mailto:www-forms-request@w3.org] *On
 > Behalf Of *John Boyer*
 > Sent:* Saturday, December 02, 2006 10:06 AM*
 > To:* www-forms@w3.org*
 > Subject:* The message action is for messages, not arbitrary dialogs
 >
 >
 > Well, team, based on being the most hotly contested issue at the working
 > group face to face meeting, we do need to spend some time discussing the
 > meaning of the message action.
 >
 > The following is my opinion offered to initiate discussion by the
 > working group and the XForms community.
 >
 > At the working group face to face it was suggested that we should not
 > disallow message from acting as a general dialog just because it is
 > spelled m-e-s-s-a-g-e.
 >
 > Yes, we should.  For starters, the name of the thing should reflect what
 > it does.  Otherwise, why not name all of our vocabulary foo1, foo2, ...,
 > fooN instead of insert, delete, input, ..., repeat.  If you want a
 > dialog, use d-i-a-l-o-g.  Moreover, if the lessons learned about the new
 > prompt action in 1.1 are any indication, a dialog *action* should almost
 > certainly not directly contain the UI content for the dialog.  The
 > dialog UI content should be indicated by reference so that the capture
 > and bubble phases of events for controls within the dialog do not
 > trigger behaviors from the containing UI control(s) that activated the
 > dialog.
 >
 > At the face to face, it was shown that the content model for message
 > includes UIInline, which the spec says that a host language *should* add
 > inline host language markup.  As a minor technicality, we can't really
 > say *should* about the host language.  We can only say *may*.  But
 > regardless of the categorization, the claim is that this sentence means
 > that host languages can put any host language constructs into message.
 >
 > First of all, xforms:input is from XForms not the host language, so
 > changes of UIInline should not include any input controls from XForms.
 >  Moreover, observe that the spec is clear on what elements from XForms
 > can appear in message: output.  Finally, just because a host language
 > *may* add host language markup to the message element does not mean that
 > the host language is allowed all of itself to the extent of violating
 > the very definition of the message action.  Designers of host languages
 > integrations with XForms are expected to be discerning about what gets
 > added and what is allowed to work.  Perhaps XForms could be a little
 > better defined by separating this use of UIInline from others, but the
 > definition of message is as follows:
 >
 > "This action encapsulates a message to be displayed to the user."
 >
 > The above definition for message categorically does not admit a two-way
 > dialog with the user.  The intent of the action is to provide a simple,
 > lightweight ability to provide information *out* to the user.  The
 > ability to make host language additions is intended to support that
 > definition by providing a means to enrich the presentation of the
 > message, not to allow an end-run around the definition of 'message'.
 >
 > We have a future requirement to create a dialog construct.  Let's do
 > that so that we can curb the tendency to misuse message as the feature
 > we need but don't have.
 >
 > Thanks,
 > John M. Boyer, Ph.D.
 > STSM: Workplace Forms Architect and Researcher
 > Co-Chair, W3C Forms Working Group
 > Workplace, Portal and Collaboration Software
 > IBM Victoria Software Lab
 > E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/
 >
 > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
 >


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

Received on Tuesday, 5 December 2006 22:51:18 UTC