RE: proposal for new submission replace mode 'new'

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.

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 <mailto:nick.van.den.bleeken@inventivegroup.com>
http://www.inventivedesigners.com<http://www.inventivedesigners.com/>
Linked in<http://be.linkedin.com/in/nvdbleek>

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<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 by MailScanner, and is
believed to be clean.
--