- From: Joern Turner <joern.turner@googlemail.com>
- Date: Fri, 28 May 2010 20:15:26 +0200
- To: John Boyer <boyerj@ca.ibm.com>
- Cc: "Leigh L. Klotz, Jr." <Leigh.Klotz@xerox.com>, Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>, "www-forms@w3.org" <www-forms@w3.org>
- Message-ID: <AANLkTil288ocqSwRXztHDNgD0_K4KGdpnO9IJ5i_j_1R@mail.gmail.com>
On Fri, May 28, 2010 at 6:39 PM, John Boyer <boyerj@ca.ibm.com> wrote: > > 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. > Thanks John, that's what i tried to point out. While replace="all" shuts the processor down a target value of "_blank" wouldn't do that. That was meant by my statement that @target modifies the behavior of @replace="all". Joern > > 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. > > -- > > > > > > > > > >
Received on Friday, 28 May 2010 18:15:56 UTC