Javascript implementation limitation

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

Javascript implementation limitation

Mats Eklund-2

Hi,

I'm weighing pros and cons of two xforms implementations, one is a server side implementation and the other is a browser side implementation in javascript. It appears to me that one inherent limitation of a javascript implementation is that xforms submissions with replace="all" is impossible to achieve. Any insights welcome?

Thanks,

Mats


Reply | Threaded
Open this post in threaded view
|

Re: Javascript implementation limitation

Joern Turner-4
Mats,

On Dec 3, 2009, at 10:21 PM, Mats Eklund wrote:

> Hi,
>
>
> I'm weighing pros and cons of two xforms implementations, one is a  
> server side implementation and the other is a browser side  
> implementation in javascript. It appears to me that one inherent  
> limitation of a javascript implementation is that xforms submissions  
> with replace="all" is impossible to achieve. Any insights welcome?
>
That's not right. In Chiba we support submission/@replace="all".  
Though it comes to the price of having an additional URI param on the  
resulting URL. On the other hand you can always substitute a replace  
all with a combination of submission and load.

Regards,

Joern

>
> Thanks,
>
> Mats
>
>



Reply | Threaded
Open this post in threaded view
|

RE: Javascript implementation limitation

Alain COUTHURES
In reply to this post by Mats Eklund-2
Hi Mats,

I'm in charge of XSLTForms project and I agree with you about this problem.

Have a look at http://old.nabble.com/A-new-submit-method-for-implementing-replace%3D%22all%22-with-Javascript----td20638952.html

Best regards,
Alain Couthures
<agenceXML>
Bordeaux, France
http://www.agencexml.com/xsltforms

 
Hi,

I'm weighing pros and cons of two xforms implementations, one is a server side implementation and the other is a browser side implementation in javascript. It appears to me that one inherent limitation of a javascript implementation is that xforms submissions with replace="all" is impossible to achieve. Any insights welcome?

Thanks,
Mats

Reply | Threaded
Open this post in threaded view
|

Re: Javascript implementation limitation

Mats Eklund-2
In reply to this post by Joern Turner-4
submission then load is how I currently do it, however, this requires the server to be tweaked to respond with a redirect in a non-conventional way. By conventional I'm referring to the "PRG pattern" (http://en.wikipedia.org/wiki/Post/Redirect/Get). As long as this pattern isn't used, there is no problem. Maybe xforms was not intended to be used with this pattern...?


--- On Fri, 12/4/09, Joern Turner <[hidden email]> wrote:

From: Joern Turner <[hidden email]>
Subject: Re: Javascript implementation limitation
To: "Mats Eklund" <[hidden email]>
Cc: [hidden email]
Date: Friday, December 4, 2009, 10:00 AM

Mats,

On Dec 3, 2009, at 10:21 PM, Mats Eklund wrote:

> Hi,
>
>
> I'm weighing pros and cons of two xforms implementations, one is a server side implementation and the other is a browser side implementation in javascript. It appears to me that one inherent limitation of a javascript implementation is that xforms submissions with replace="all" is impossible to achieve. Any insights welcome?
>
That's not right. In Chiba we support submission/@replace="all". Though it comes to the price of having an additional URI param on the resulting URL. On the other hand you can always substitute a replace all with a combination of submission and load.

Regards,

Joern

>
> Thanks,
>
> Mats
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Javascript implementation limitation

Mats Eklund-2
In reply to this post by Joern Turner-4
btw, I'm not familiar with chiba. how much of the processing is done client-side in chiba? one reason I'm prefering client-side solution is for responsiveness of the ui. other server side implementations introduce a lag which is not acceptable for my app.

--- On Fri, 12/4/09, Joern Turner <[hidden email]> wrote:

From: Joern Turner <[hidden email]>
Subject: Re: Javascript implementation limitation
To: "Mats Eklund" <[hidden email]>
Cc: [hidden email]
Date: Friday, December 4, 2009, 10:00 AM

Mats,

On Dec 3, 2009, at 10:21 PM, Mats Eklund wrote:

> Hi,
>
>
> I'm weighing pros and cons of two xforms implementations, one is a server side implementation and the other is a browser side implementation in javascript. It appears to me that one inherent limitation of a javascript implementation is that xforms submissions with replace="all" is impossible to achieve. Any insights welcome?
>
That's not right. In Chiba we support submission/@replace="all". Though it comes to the price of having an additional URI param on the resulting URL. On the other hand you can always substitute a replace all with a combination of submission and load.

Regards,

Joern

>
> Thanks,
>
> Mats
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Javascript implementation limitation

Erik Bruchez
Joern will correct me if I am wrong, but my understanding is that Chiba and Orbeon have a similar approach and that in Chiba as well most of serious the XForms processing is done on the server.

-Erik

On Fri, Dec 4, 2009 at 4:21 AM, Mats Eklund <[hidden email]> wrote:
btw, I'm not familiar with chiba. how much of the processing is done client-side in chiba? one reason I'm prefering client-side solution is for responsiveness of the ui. other server side implementations introduce a lag which is not acceptable for my app.


--- On Fri, 12/4/09, Joern Turner <[hidden email]> wrote:

From: Joern Turner <[hidden email]>
Subject: Re: Javascript implementation limitation
To: "Mats Eklund" <[hidden email]>
Cc: [hidden email]
Date: Friday, December 4, 2009, 10:00 AM

Mats,

On Dec 3, 2009, at 10:21 PM, Mats Eklund wrote:

> Hi,
>
>
> I'm weighing pros and cons of two xforms implementations, one is a server side implementation and the other is a browser side implementation in javascript. It appears to me that one inherent limitation of a javascript implementation is that xforms submissions with replace="all" is impossible to achieve. Any insights welcome?
>
That's not right. In Chiba we support submission/@replace="all". Though it comes to the price of having an additional URI param on the resulting URL. On the other hand you can always substitute a replace all with a combination of submission and load.

Regards,

Joern

>
> Thanks,
>
> Mats
>
>



Reply | Threaded
Open this post in threaded view
|

RE: Javascript implementation limitation

Klotz, Leigh
In reply to this post by Joern Turner-4
I believe in XForms 1.1 you can do this, to implement post/redirect/get:

<xf:submission replace="instance" instance='foo' ... >
   <xf:load ev:event="xforms-submit-done" resource="instance('foo')/location" if="instance('foo')/location" />
</xf:submission>

In XForms 1.0 you needed to listen for xforms-enabled (or chiba-state-changed) on an xf:output bound to the location node, and it wasn't as reliable across implementations.

It may also work to do this (even in xsltforms, though I haven't checked)


<xf:submission replace="instance" instance='foo' ... >
   <xf:send ev:event="xforms-submit-done" submission="myget" />
</xf:submission>
<xf:submission id="myget" ... />

Leigh.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Joern Turner
Sent: Friday, December 04, 2009 1:01 AM
To: Mats Eklund
Cc: [hidden email]
Subject: Re: Javascript implementation limitation

Mats,

On Dec 3, 2009, at 10:21 PM, Mats Eklund wrote:

> Hi,
>
>
> I'm weighing pros and cons of two xforms implementations, one is a
> server side implementation and the other is a browser side
> implementation in javascript. It appears to me that one inherent
> limitation of a javascript implementation is that xforms submissions
> with replace="all" is impossible to achieve. Any insights welcome?
>
That's not right. In Chiba we support submission/@replace="all".  
Though it comes to the price of having an additional URI param on the resulting URL. On the other hand you can always substitute a replace all with a combination of submission and load.

Regards,

Joern

>
> Thanks,
>
> Mats
>
>