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

I think we're all pretty much in agreement that we want a nicely
designed xf:dialog element for a later version of XForms.
Personally I think that the freedom to do inline dialogs rather than
pop-up windows is something that should be emphasized; as the XForms
recommendation doesn't really have the authority to describe those
details of UI presentation (certainly since they vary from modality to
modality).

As for the processing model, whether xf:dialog ties back to the original
model seamlessly or submits as you suggest, or works a recursive
composition component model are points to discuss.  Unfortunately, that
will be quite some time before xf:dialog is designed or available,
possibly years.

Until then, I don't think we should penalize 1.0 processors that allow
the host language to include XForms elements inside message, since it's
legal according to the Schema, and some processors already do it. So if
more want to, I don't think it's a problem.

Leigh.

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Daniel Fowler
Sent: Friday, December 08, 2006 4:04 AM
To: www-forms@w3.org
Subject: Re: The message action is for messages, not arbitrary dialogs


Hi All,
 
I like systems that do "what is it says on the tin". Avoids confusion
for people who pick up systems long after the designers have gone.
 
"message" - I've just got something to tell you so read it (listen to
it) and continue, e.g.

 -------------------------------------
|                                     |
|  You have 2 overdue library books.  |
|                                     |
|                 <OK>                |
 ------------------------------------- 

"dialog" (dialogue) - we're having a conversation, I'm
showing/requesting information and expecting a response

 -------------------------------------
|                                     |
|  How many weeks would you like to   |
|                         ----        |
|  extend your borrowing:|0   |       |
|                         ----        | 
|                                     |
|         <Cancel> <Enter>            |
 ------------------------------------- 

Other systems have flexed the meaning of "words" that define behaviour
but that doesn't mean XForms should. For example the Windows API
"MessageBox" takes a parameter to change the type of buttons that appear
then returns one of several possible values based upon the button
pressed (Abort, Cancel, Continue, Ignore, No, OK, Retry, Try Again,
Yes), thus it's no longer a simple message but a dialogue.

A "dialog" is just another XForms, i.e. XForms has all the constructs
for a dialog, so the ability to put two XForms in one file, open the
second as a "dialog" and "submit" the results back to first XForms would
do the job. On the other hand just looking at the design of the
requirement may suffice, instead of opening another window how about
revealing an additional area to be completed or moving to another page.

Regards,
Daniel Fowler
 
 
________________________________

From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of John Boyer
Sent: 08 December 2006 01:10
To: Elliotte Harold
Cc: ebruchez@orbeon.com; www-forms@w3.org; www-forms-request@w3.org
Subject: Re: The message action is for messages, not arbitrary dialogs



Hi Elliotte, 

I should start by saying that, having heard you speak at the XML
conference, this response is not entirely directed to you. 

Still, it is quite difficult to imagine a scenario in which 'message'
might legitimately be used in place of 'dialog' and the many examples
you cited are witnesses to that assertion. 

This keeps happening because of the definition of the word message.  A
message is one-sided.  A dialog would be composed of two or more
messages.  Like, you sent a message, and now I'm sending a message.  The
two together are a dialog. 

But the most telling is the definition of message that actually appears
in XForms recommendation.  It is defined to *display* a message *to* a
user.  There is nothing *from* the user that comes back to XForms.   

The content model is defined to be char data and XForms *output*.  The
spec then allows host language content to be added to message, which is
*not* the same as saying more *XForms* controls can be added to the
message content model.  The host language additions are not intended to
violate the given definition but rather in support of it to allow
decoration of the message.   

Should some example happen to arise where message is (mis)used to mean
dialog, that doesn't mean we should accept that as proper usage in
XForms. 

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





Elliotte Harold <elharo@metalab.unc.edu> Sent by:
www-forms-request@w3.org 

12/07/2006 07:46 AM 

	
To
	ebruchez@orbeon.com
cc
	www-forms@w3.org
Subject
	Re: The message action is for messages, not arbitrary dialogs

	





Erik Bruchez wrote:

> 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".
>

Google MessageBox. .NET, SWT, and ASP.NET all use this term instead of 
DialogBox. Possibly they think of MessageBox as a restricted form of 
DialogBox just for messages; i.e. an alert. I'm not sure, but certainly 
the word message is sometimes used in place of the word dialog.

-- 
Elliotte Rusty Harold  elharo@metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

Received on Friday, 8 December 2006 18:07:42 UTC