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

Received on Thursday, 27 May 2010 15:06:11 UTC