Re: proposal for new submission replace mode 'new'

Nick,

On Sun, May 30, 2010 at 8:07 PM, Nick Van den Bleeken <
Nick.Van.den.Bleeken@inventivegroup.com> wrote:

>  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.
>
Sure - but it is a difference if an attribute has influence (by adding an
aspect) or if it completely overwrites the basic behavior. IMO that can
confuse authors.


>
> 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>
> nick.van.den.bleeken@inventivegroup.com **
>
> <http://www.inventivedesigners.com/>http://www.inventivedesigners.com
>
> <http://be.linkedin.com/in/nvdbleek>Linked in
>
>
>
> *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
> > Linked in
> >
> >> -----Original Message-----
> >> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org<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, and is believed to be clean.
> --
>
>