Re: proposal for new submission replace mode 'new'

Hi Nick,

On Sun, May 30, 2010 at 7:41 PM, Nick Van den Bleeken
<Nick.Van.den.Bleeken@inventivegroup.com> wrote:
> Hi Joern,
>
> The 'problem' is that the keywords '_blank', '_top', '_parent' or '_self' are defined in the host language (XHTML in this case). And can consequently have different values depending the host language used (XForms just provides the extension point).
Sure - i fully agree.

>
> And yes I think the processor should shutdown if you replace the XForms document(target '_self), but I think this is handled in the same way (at the host language integration integration layer) as a user typing in a new address in the address bar of a web browser that was running an XForms document, or when the document is replaced using javascript or using any host application extension/plugin mechanism.

Again - nothing to object here. Btw '_self' is anyway redundant as it
would behave the same as a plain replace="all".

But i want the processor to continue processing. This lead me to the
statement that the replace="all" behavior would be modified for a
@target="_blank" or to be more explicit that the combination of
replace="all" and target="_blank" is maybe not the ideal solution. And
as you pointed out there might be other targets in a host language
that could have the same ' problem'.

John's proposal to add 'target' for @replace makes things a bit
clearer for authors.

>
> 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 17:06
>> To: Nick Van den Bleeken
>> Cc: Leigh L. Klotz, Jr.; www-forms@w3.org
>> 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 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 Monday, 31 May 2010 09:54:24 UTC