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