RE: proposal for new submission replace mode 'new'

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

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.

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 Sunday, 30 May 2010 17:42:26 UTC