proposal for new submission replace mode 'new'

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

proposal for new submission replace mode 'new'

Joern Turner
Dear WG,

recently i came across a use case that is not easy to have with
current XForms: imagine a site that allows to fill in a form and after
you're done opens a window for printing a formatted report composed
from the input data.

To get that in XForms you will need to write a submission with
replace="instance" (returning a URL as response) and fire a load
action on xforms-submit-done to open the new window with show="new'".
So far so good but you are forced to persist the data on the server
and fetch them with the load action. This is inconvenient especially
if the data are transient in nature and forces to have an extra bit of
server-logic that deals with the persisted data on the server (like
cleaning up sometime).

We have implemented a new submission replace mode 'new' (the name
might not be the best but is taken from load/@show="new") that allows
to do it in one step. Besides being easier to read and write for the
author it also avoids being dependent on extra external logic.
Implementation should be easy as it is similar to replace="all"
(besides the fact that the processor will continue to iive) - it just
returns the data as response body and the xforms processor just has to
open a new window to display them.

As the use case seems common it might be a candidate for consideration
for one of the next versions of XForms.

Thanks,

Joern Turner

Reply | Threaded
Open this post in threaded view
|

Re: proposal for new submission replace mode 'new'

Klotz, Leigh
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.


Reply | Threaded
Open this post in threaded view
|

Re: proposal for new submission replace mode 'new'

Joern Turner
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.
<[hidden email]> 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.
>
>
>

Reply | Threaded
Open this post in threaded view
|

RE: proposal for new submission replace mode 'new'

Nick Van den Bleeken-2
Hi Joern,

First of all I'm happy that you can live with the target attribute.

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 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
[hidden email]
http://www.inventivedesigners.com
Linked in

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf
> Of Joern Turner
> Sent: donderdag 27 mei 2010 15:33
> To: Leigh L. Klotz, Jr.
> Cc: [hidden email]
> 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.
> <[hidden email]> 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.
--



Reply | Threaded
Open this post in threaded view
|

Re: proposal for new submission replace mode 'new'

Joern Turner
On Thu, May 27, 2010 at 4:33 PM, Nick Van den Bleeken
<[hidden email]> 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
> [hidden email]
> http://www.inventivedesigners.com
> Linked in
>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On Behalf
>> Of Joern Turner
>> Sent: donderdag 27 mei 2010 15:33
>> To: Leigh L. Klotz, Jr.
>> Cc: [hidden email]
>> 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.
>> <[hidden email]> 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.
> --
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: proposal for new submission replace mode 'new'

John Boyer

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: [hidden email]  

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 <[hidden email]>
To: Nick Van den Bleeken <[hidden email]>
Cc: "Leigh L. Klotz, Jr." <[hidden email]>, "[hidden email]" <[hidden email]>
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
<[hidden email]> 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
> [hidden email]
>
http://www.inventivedesigners.com
> Linked in
>
>> -----Original Message-----
>> From: [hidden email] [
[hidden email]] On Behalf
>> Of Joern Turner
>> Sent: donderdag 27 mei 2010 15:33
>> To: Leigh L. Klotz, Jr.
>> Cc: [hidden email]
>> 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.
>> <[hidden email]> 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.
> --
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: proposal for new submission replace mode 'new'

Joern Turner


On Fri, May 28, 2010 at 6:39 PM, John Boyer <[hidden email]> 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: [hidden email]  

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 <[hidden email]>
To:
Nick Van den Bleeken <[hidden email]>
Cc: "Leigh L. Klotz, Jr." <[hidden email]>, "[hidden email]" <[hidden email]>
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
<[hidden email]> 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
> [hidden email]
>
http://www.inventivedesigners.com
> Linked in
>
>> -----Original Message-----
>> From: [hidden email] [
[hidden email]] On Behalf
>> Of Joern Turner
>> Sent: donderdag 27 mei 2010 15:33
>> To: Leigh L. Klotz, Jr.
>> Cc: [hidden email]
>> 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.
>> <[hidden email]> 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.
> --
>
>
>




Reply | Threaded
Open this post in threaded view
|

RE: proposal for new submission replace mode 'new'

Nick Van den Bleeken-2
In reply to this post by Joern Turner
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
[hidden email]
http://www.inventivedesigners.com
Linked in

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf
> Of Joern Turner
> Sent: donderdag 27 mei 2010 17:06
> To: Nick Van den Bleeken
> Cc: Leigh L. Klotz, Jr.; [hidden email]
> Subject: Re: proposal for new submission replace mode 'new'
>
> On Thu, May 27, 2010 at 4:33 PM, Nick Van den Bleeken
> <[hidden email]> 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
> > [hidden email]
> > http://www.inventivedesigners.com
> > Linked in
> >
> >> -----Original Message-----
> >> From: [hidden email] [mailto:[hidden email]] On
> Behalf
> >> Of Joern Turner
> >> Sent: donderdag 27 mei 2010 15:33
> >> To: Leigh L. Klotz, Jr.
> >> Cc: [hidden email]
> >> 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.
> >> <[hidden email]> 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.
--



Reply | Threaded
Open this post in threaded view
|

RE: proposal for new submission replace mode 'new'

Nick Van den Bleeken-2
In reply to this post by John Boyer

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.

 

Regads,

 

Nick Van den Bleeken

R&D Manager

 

Phone: +32 3 821 01 70

Office Fax: +32 3 821 01 71

[hidden email]

http://www.inventivedesigners.com

Linked in

 

From: John Boyer [mailto:[hidden email]]
Sent: vrijdag 28 mei 2010 18:40
To: Joern Turner
Cc: Leigh L. Klotz, Jr.; Nick Van den Bleeken; [hidden email]
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: [hidden email]  

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 <[hidden email]>

To:

Nick Van den Bleeken <[hidden email]>

Cc:

"Leigh L. Klotz, Jr." <[hidden email]>, "[hidden email]" <[hidden email]>

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
<[hidden email]> 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
> [hidden email]
>
http://www.inventivedesigners.com
> Linked in
>
>> -----Original Message-----
>> From: [hidden email] [
[hidden email]] On Behalf
>> Of Joern Turner
>> Sent: donderdag 27 mei 2010 15:33
>> To: Leigh L. Klotz, Jr.
>> Cc: [hidden email]
>> 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.
>> <[hidden email]> 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.
--

Reply | Threaded
Open this post in threaded view
|

Re: proposal for new submission replace mode 'new'

Joern Turner
In reply to this post by Nick Van den Bleeken-2
Hi Nick,

On Sun, May 30, 2010 at 7:41 PM, Nick Van den Bleeken
<[hidden email]> 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
> [hidden email]
> http://www.inventivedesigners.com
> Linked in
>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On Behalf
>> Of Joern Turner
>> Sent: donderdag 27 mei 2010 17:06
>> To: Nick Van den Bleeken
>> Cc: Leigh L. Klotz, Jr.; [hidden email]
>> Subject: Re: proposal for new submission replace mode 'new'
>>
>> On Thu, May 27, 2010 at 4:33 PM, Nick Van den Bleeken
>> <[hidden email]> 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
>> > [hidden email]
>> > http://www.inventivedesigners.com
>> > Linked in
>> >
>> >> -----Original Message-----
>> >> From: [hidden email] [mailto:[hidden email]] On
>> Behalf
>> >> Of Joern Turner
>> >> Sent: donderdag 27 mei 2010 15:33
>> >> To: Leigh L. Klotz, Jr.
>> >> Cc: [hidden email]
>> >> 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.
>> >> <[hidden email]> 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.
> --
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: proposal for new submission replace mode 'new'

Joern Turner
In reply to this post by Nick Van den Bleeken-2
Nick,

On Sun, May 30, 2010 at 8:07 PM, Nick Van den Bleeken <[hidden email]> 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

[hidden email][hidden email]

http://www.inventivedesigners.com

Linked in

 

From: John Boyer [mailto:[hidden email]]
Sent: vrijdag 28 mei 2010 18:40
To: Joern Turner
Cc: Leigh L. Klotz, Jr.; Nick Van den Bleeken; [hidden email]


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: [hidden email]  

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 <[hidden email]>

To:

Nick Van den Bleeken <[hidden email]>

Cc:

"Leigh L. Klotz, Jr." <[hidden email]>, "[hidden email]" <[hidden email]>

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
<[hidden email]> 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
> [hidden email]
>
http://www.inventivedesigners.com
> Linked in
>
>> -----Original Message-----
>> From: [hidden email] [
[hidden email]] On Behalf
>> Of Joern Turner
>> Sent: donderdag 27 mei 2010 15:33
>> To: Leigh L. Klotz, Jr.
>> Cc: [hidden email]
>> 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.
>> <[hidden email]> 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.
--


Reply | Threaded
Open this post in threaded view
|

Re: proposal for new submission replace mode 'new'

Erik Bruchez
I would try hard to stay away from adding a new value for "replace" unless there is a very strong argument to show that it is absolutely necessary.

As I tried to argue above, with HTML as a host language, replace="all" can already result in different behaviors depending on the document type returned by the submission.

-Erik

On Mon, May 31, 2010 at 2:59 AM, Joern Turner <[hidden email]> wrote:
Nick,

On Sun, May 30, 2010 at 8:07 PM, Nick Van den Bleeken <[hidden email]> 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

[hidden email][hidden email]

http://www.inventivedesigners.com

Linked in

 

From: John Boyer [mailto:[hidden email]]
Sent: vrijdag 28 mei 2010 18:40
To: Joern Turner
Cc: Leigh L. Klotz, Jr.; Nick Van den Bleeken; [hidden email]


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: [hidden email]  

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 <[hidden email]>

To:

Nick Van den Bleeken <[hidden email]>

Cc:

"Leigh L. Klotz, Jr." <[hidden email]>, "[hidden email]" <[hidden email]>

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
<[hidden email]> 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
> [hidden email]
>
http://www.inventivedesigners.com
> Linked in
>
>> -----Original Message-----
>> From: [hidden email] [
[hidden email]] On Behalf
>> Of Joern Turner
>> Sent: donderdag 27 mei 2010 15:33
>> To: Leigh L. Klotz, Jr.
>> Cc: [hidden email]
>> 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.
>> <[hidden email]> 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.
--



Reply | Threaded
Open this post in threaded view
|

Re: proposal for new submission replace mode 'new'

John Boyer

Hi Erik,

Aren't the differences of which you speak (in handling of replace all based on returned content type) not differences with respect to the XForms processor?

Also, one question I'd have is whether one should expect to see the xforms-submit-done event on an xforms submission that uses target="_blank".  
In 1.1, we do not expect this event on replace="all" because it is understood that the XForms processor will be killed by a replace all XForms submission.

The argument for replace="target" is that we don't (necessarily) expect the XForms processor to be killed.  It does look like there are some potential settings that could cause this, but it may be the case that these are specified as optional to implement.  On the other hand, target="_blank" and target="#ID" (where the identified element does not contain the xforms submission) could be specified as "should" or "must", and in those cases, we don't expect the spawning xforms submission to be killed and therefore probably do expect an xforms-submit-done.

This is the point at which it seems worth creating an authoring alternative to replace="all".

Cheers,
John M. Boyer, Ph.D.
STSM, Lotus Forms
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: [hidden email]  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw




From: Erik Bruchez <[hidden email]>
To: "[hidden email]" <[hidden email]>
Date: 05/31/2010 11:19 AM
Subject: Re: proposal for new submission replace mode 'new'





I would try hard to stay away from adding a new value for "replace" unless there is a very strong argument to show that it is absolutely necessary.

As I tried to argue above, with HTML as a host language, replace="all" can already result in different behaviors depending on the document type returned by the submission.

-Erik

On Mon, May 31, 2010 at 2:59 AM, Joern Turner <joern.turner@...> wrote:
Nick,

On Sun, May 30, 2010 at 8:07 PM, Nick Van den Bleeken <Nick.Van.den.Bleeken@...> 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@...

http://www.inventivedesigners.com

Linked in

 

From: John Boyer [mailto:boyerj@...]
Sent:
vrijdag 28 mei 2010 18:40
To:
Joern Turner
Cc:
Leigh L. Klotz, Jr.; Nick Van den Bleeken;
[hidden email]


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

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@...>
To: Nick Van den Bleeken <Nick.Van.den.Bleeken@...>
Cc: "Leigh L. Klotz, Jr." <Leigh.Klotz@...>, "[hidden email]" <[hidden email]>
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@...> 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@...
>
http://www.inventivedesigners.com
> Linked in
>
>> -----Original Message-----
>> From:
[hidden email] [[hidden email]] On Behalf
>> Of Joern Turner
>> Sent: donderdag 27 mei 2010 15:33
>> To: Leigh L. Klotz, Jr.
>> Cc:
[hidden email]
>> 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@...> 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.
--