Re: proposal for new submission replace mode 'new'

Hi Erik,

Aren't the differences of which you speak (in handling of replace all 
based on returned content type) not differences with respect to the XForms 
processor?

Also, one question I'd have is whether one should expect to see the 
xforms-submit-done event on an xforms submission that uses 
target="_blank". 
In 1.1, we do not expect this event on replace="all" because it is 
understood that the XForms processor will be killed by a replace all 
XForms submission.

The argument for replace="target" is that we don't (necessarily) expect 
the XForms processor to be killed.  It does look like there are some 
potential settings that could cause this, but it may be the case that 
these are specified as optional to implement.  On the other hand, 
target="_blank" and target="#ID" (where the identified element does not 
contain the xforms submission) could be specified as "should" or "must", 
and in those cases, we don't expect the spawning xforms submission to be 
killed and therefore probably do expect an xforms-submit-done.

This is the point at which it seems worth creating an authoring 
alternative to replace="all".

Cheers,
John M. Boyer, Ph.D.
STSM, Lotus Forms
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:
"www-forms@w3.org" <www-forms@w3.org>
Date:
05/31/2010 11:19 AM
Subject:
Re: proposal for new submission replace mode 'new'



I would try hard to stay away from adding a new value for "replace" unless 
there is a very strong argument to show that it is absolutely necessary.

As I tried to argue above, with HTML as a host language, replace="all" can 
already result in different behaviors depending on the document type 
returned by the submission.

-Erik

On Mon, May 31, 2010 at 2:59 AM, Joern Turner <joern.turner@googlemail.com
> wrote:
Nick,

On Sun, May 30, 2010 at 8:07 PM, Nick Van den Bleeken <
Nick.Van.den.Bleeken@inventivegroup.com> wrote:
John,
 
I didn’t read your e-mail before sending my previous reply, a value of 
‘target’ for replace sounds reasonable for me. Though I don’t think that 
it is strictly needed, we already have other attributes that if present 
have influence on another attribute.
Sure - but it is a difference if an attribute has influence (by adding an 
aspect) or if it completely overwrites the basic behavior. IMO that can 
confuse authors.

 
Regads,
 
Nick Van den Bleeken
R&D Manager
 
Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com 
http://www.inventivedesigners.com

Linked in
 
From: John Boyer [mailto:boyerj@ca.ibm.com] 
Sent: vrijdag 28 mei 2010 18:40
To: Joern Turner
Cc: Leigh L. Klotz, Jr.; Nick Van den Bleeken; www-forms@w3.org

Subject: Re: proposal for new submission replace mode 'new'
 

Joern raises a good point here, indirectly perhaps. 
Using things like _top may destroy the XForms processor, but this is 
consistent with replace="all" behavior, so that doesn't seems to bad. 
But with target="_blank" or target="#ID", the result is not consistent 
with replacing all of the containing document. 

Might it be better, then, to have one more attribute value for replace, 
e.g. replace="target", which indicates that what to do with the submission 
result is being delegated to the target attribute, and whatever happens 
next is defined by that attribute.  This would at least make things 
explicit at the markup level and at the code level, as Joern originally 
asked, i.e. replace="target" would be clear about what is going on to the 
form author and, for the implementer, would cause execution to follow a 
new code branch in which the target attribute is processed.  At the spec 
level, there would be no need to explain away the various @replace values 
where  @target made no sense. 

I think we may have even discussed this possibility during one of the 
target attribute discussions in the hazy past. 

John M. Boyer, Ph.D.
STSM, Lotus Forms
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: 
Joern Turner <joern.turner@googlemail.com> 
To: 
Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com> 
Cc: 
"Leigh L. Klotz, Jr." <Leigh.Klotz@xerox.com>, "www-forms@w3.org" <
www-forms@w3.org> 
Date: 
05/27/2010 08:07 AM 
Subject: 
Re: proposal for new submission replace mode 'new'
 




On Thu, May 27, 2010 at 4:33 PM, Nick Van den Bleeken
<Nick.Van.den.Bleeken@inventivegroup.com> wrote:
> Hi Joern,
>
> First of all I'm happy that you can live with the target attribute.
i feel generous today ;)

>
> One of the reasons to go with a target attribute is: That we can leave 
the value space of the replace attribute as is 
("all"|"instance"|"text"|"none" | QNameButNotNCName), and define value 
space of the new target attribute as host-language dependent.

This only leads to a problem when using '_top', '_parent' or '_self'
as this results in replacing the current viewport of the browser (the
viewport the form is running in) and this surely should lead to the
destruction of the XForms processor shouldn't it? But in case i use
'_blank' (which was my original use case) i want the processor to keep
on living.  Do we possibly need to constrain the possible value space
of @target?

Joern
>
> This will make it possible to align the attribute, when XForms is using 
XHTML as host language, to be fully compatible with the target attribute 
defined in that host language (if we were re-using the replace attribute 
we would have needed to define a naming schema that allowed the current 
values and targeting a new window, parent frame, other name frame, other 
'window',...).
>
> It is also the case that the default value for the replace attribute is 
'all' so the author can omit the attribute when using the target 
attribute. An implementation can as always log a warning when the target 
attribute is used and replace is not 'all'.
>
> Regards,
>
> Nick Van den Bleeken
> R&D Manager
>
> Phone: +32 3 821 01 70
> Office Fax: +32 3 821 01 71
> nick.van.den.bleeken@inventivegroup.com
> http://www.inventivedesigners.com

> Linked in
>
>> -----Original Message-----
>> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On 
Behalf
>> Of Joern Turner
>> Sent: donderdag 27 mei 2010 15:33
>> To: Leigh L. Klotz, Jr.
>> Cc: www-forms@w3.org
>> Subject: Re: proposal for new submission replace mode 'new'
>>
>> Leigh,
>>
>> thanks for the quick reply.
>>
>> First of all i appreciate that the use case now has been addressed
>> though i'm not completely happy from a design point of view. It might
>> well be my personal indisposition but i don't like it too much if the
>> existence of one attribute (in this case 'target') changes the
>> behavior of another (the replace attribute). IMO this often puzzles
>> users and more easily leads to authoring mistakes than to use distinct
>> values of one attribute for distinct functionalities.
>>
>> This also reflects in implementations: you have to check several
>> attributes before deciding what to do. But anyway, the resolution of
>> the use case is the important thing here and in the end i can live
>> with it.
>>
>> Thanks,
>>
>> Joern
>>
>> On Wed, May 26, 2010 at 6:22 PM, Leigh L. Klotz, Jr.
>> <Leigh.Klotz@xerox.com> wrote:
>> > Joern,
>> >
>> > We agree with your use case, and note that we already have a proposed
>> > feature for XForms 1.2, with a slightly different expression.
>> >
>> > Please see the current proposal at
>> > http://www.w3.org/MarkUp/Forms/wiki/Submission_Embedding

>> >
>> > Briefly, we propose the new attribute submission/@target.  For 
example,
>> in
>> > your use case of a new window in an XHTML+XForms integration, the
>> attribute
>> > value would be XHTML name "_blank" :
>> >
>> >  <submission replace="all" target="_blank" ... />
>> >
>> > As with all XForms 1.2 proposed features, we seek feedback on
>> experimental
>> > implementations.  There is already one implementation, cited in the
>> feature
>> > proposal.
>> >
>> > Please see our discussion at
>> > 
http://lists.w3.org/Archives/Public/public-forms/2010May/att-0025/2010-

>> 05-26.html#topic5
>> >
>> > Leigh.
>> >
>> >
>> >
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>> --
>>
>
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer

>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> --
>
>
>



-- 
This message has been scanned for viruses and 
dangerous content, and is believed to be clean. 
-- 

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer


-- 
This message has been scanned for viruses and 
dangerous content, and is believed to be clean. 
--