Re: Sticky Sessions

[Kalle Korhonen]

On Thu, Dec 4, 2014 at 4:43 PM, George Christman 
wrote:

> Well before I had it disabled with the load balancer which was causing the
> issues. It seemed to fix things when I activated it, but it had a default
> time of 0. I'll change it to 5mins for now and if I didn't etend it via
> async, what would happen?
>

You mean what happens when a server side session expires? Same as if it was
invalidated, i.e.  "void *invalidate
*
()
  Invalidates this session then unbinds any objects bound to it."

Kalle


>
> On Thu, Dec 4, 2014 at 3:41 PM, Kalle Korhonen  >
> wrote:
>
> > On Thu, Dec 4, 2014 at 12:08 PM, George Christman <
> gchrist...@cardaddy.com
> > >
> > wrote:
> >
> > > I'd have to say 98% of my app is stateless, I only have a few admin
> pages
> > > that still use tapestry grid. Other than that Captcha and Tapestry
> > Security
> > > redirect seem to be the only two items effected by this, so I don't
> think
> > > I'll have a memory issue.
> > >
> >
> > Yeah, that's how it should be.
> >
> >
> > > Kalle, I still use AWS and thus far it's been very reasonable. I just
> > worry
> > > instances being held active and running my bill up because of sticky
> > > sessions. I'll admit, I'm no expert in this, so perhaps my
> understanding
> > > isn't correct.
> > > Is there any recommendation for the timeout? I currently have it set at
> > 0.
> > >
> >
> > That's your issue then, you want to set it to a positive number to let
> them
> > expire. From the servlet spec: "If the timeout is 0 or less, the
> container
> > ensures the default behavior of sessions is never to time out."
> Personally,
> > I'm advocating use of short session expiration (in the order of 1-5
> mins),
> > then extending it via async calls (as described in
> > http://tynamo.org/tapestry-conversations+guide). At least tomcat has a
> > default expiration of 30 mins, I'm not sure if the spec ever said
> anything
> > about it.
> >
> > Kalle
> >
> >
> >
> > > On Thu, Dec 4, 2014 at 1:26 PM, Kalle Korhonen <
> > kalle.o.korho...@gmail.com
> > > >
> > > wrote:
> > >
> > > > On Thu, Dec 4, 2014 at 5:54 AM, George Christman <
> > > gchrist...@cardaddy.com>
> > > > wrote:
> > > >
> > > > > Hi guys, so I've had a slew of strange behaviors over the past few
> > > months
> > > > > with a few different Tapestry components such as Tapestry Grid,
> > > Tapestry
> > > > > Captcha, and writting/removing cookies. Last night I was finally
> able
> > > to
> > > > > fix them, but at the cost of a sticky session. My application sits
> > > > behind a
> > > > > load balancer, so my question is why do I need to use a sticky
> > session
> > > > and
> > > > > how do I avoid the use of them? I'm concerned with the fact this is
> > > going
> > > > > to cause a scaling dilemma.
> > > > >
> > > >
> > > > I'd almost say that sticky sessions are more the norm than the
> > exception
> > > > for Java web applications. Unless you change your implementation, you
> > > have
> > > > a choice between sticky sessions or replicated/centeralized sessions.
> > > > Sessions in your cluster are probably not managed by memcached or
> some
> > > such
> > > > (which is another single point of failure), causing the strange
> > behavior.
> > > > Furthermore, I see neither session usage nor sticky sessions as
> > > inherently
> > > > bad. Memory is cheap although in today's cloud managed solutions
> using
> > > > memory may end up costing extra to you. It depends on how your load
> > > > balancer works and whether the bottleneck in a typical usage pattern
> is
> > > cpu
> > > > or memory. Even if your load balancer does a simple random choice but
> > > > memory doesn't cost you, you are most likely fine with sticky
> sessions.
> > > If
> > > > additional servers cost you, but you can do dynamic horizontal
> scaling
> > > with
> > > > cpu/memory thresholds to spawn new instances, then sticky sessions
> are
> > > > actually desirable.
> > > >
> > > > Kalle
> > > >
> > > > PS. @Alex - yes, can configure default persistence strategy with
> > > > @Meta("tapestry.persistence-strategy=client") per page - but that
> only
> > > > works if the components don't require an explicit persistence
> strategy
> > > >
> > >
> > >
> > >
> > > --
> > > George Christman
> > > CEO
> > > www.CarDaddy.com
> > > P.O. Box 735
> > > Johnstown, New York
> > >
> >
>
>
>
> --
> George Christman
> CEO
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
>

Re: Sticky Sessions

[George Christman]

Well before I had it disabled with the load balancer which was causing the
issues. It seemed to fix things when I activated it, but it had a default
time of 0. I'll change it to 5mins for now and if I didn't etend it via
async, what would happen?

On Thu, Dec 4, 2014 at 3:41 PM, Kalle Korhonen 
wrote:

> On Thu, Dec 4, 2014 at 12:08 PM, George Christman  >
> wrote:
>
> > I'd have to say 98% of my app is stateless, I only have a few admin pages
> > that still use tapestry grid. Other than that Captcha and Tapestry
> Security
> > redirect seem to be the only two items effected by this, so I don't think
> > I'll have a memory issue.
> >
>
> Yeah, that's how it should be.
>
>
> > Kalle, I still use AWS and thus far it's been very reasonable. I just
> worry
> > instances being held active and running my bill up because of sticky
> > sessions. I'll admit, I'm no expert in this, so perhaps my understanding
> > isn't correct.
> > Is there any recommendation for the timeout? I currently have it set at
> 0.
> >
>
> That's your issue then, you want to set it to a positive number to let them
> expire. From the servlet spec: "If the timeout is 0 or less, the container
> ensures the default behavior of sessions is never to time out." Personally,
> I'm advocating use of short session expiration (in the order of 1-5 mins),
> then extending it via async calls (as described in
> http://tynamo.org/tapestry-conversations+guide). At least tomcat has a
> default expiration of 30 mins, I'm not sure if the spec ever said anything
> about it.
>
> Kalle
>
>
>
> > On Thu, Dec 4, 2014 at 1:26 PM, Kalle Korhonen <
> kalle.o.korho...@gmail.com
> > >
> > wrote:
> >
> > > On Thu, Dec 4, 2014 at 5:54 AM, George Christman <
> > gchrist...@cardaddy.com>
> > > wrote:
> > >
> > > > Hi guys, so I've had a slew of strange behaviors over the past few
> > months
> > > > with a few different Tapestry components such as Tapestry Grid,
> > Tapestry
> > > > Captcha, and writting/removing cookies. Last night I was finally able
> > to
> > > > fix them, but at the cost of a sticky session. My application sits
> > > behind a
> > > > load balancer, so my question is why do I need to use a sticky
> session
> > > and
> > > > how do I avoid the use of them? I'm concerned with the fact this is
> > going
> > > > to cause a scaling dilemma.
> > > >
> > >
> > > I'd almost say that sticky sessions are more the norm than the
> exception
> > > for Java web applications. Unless you change your implementation, you
> > have
> > > a choice between sticky sessions or replicated/centeralized sessions.
> > > Sessions in your cluster are probably not managed by memcached or some
> > such
> > > (which is another single point of failure), causing the strange
> behavior.
> > > Furthermore, I see neither session usage nor sticky sessions as
> > inherently
> > > bad. Memory is cheap although in today's cloud managed solutions using
> > > memory may end up costing extra to you. It depends on how your load
> > > balancer works and whether the bottleneck in a typical usage pattern is
> > cpu
> > > or memory. Even if your load balancer does a simple random choice but
> > > memory doesn't cost you, you are most likely fine with sticky sessions.
> > If
> > > additional servers cost you, but you can do dynamic horizontal scaling
> > with
> > > cpu/memory thresholds to spawn new instances, then sticky sessions are
> > > actually desirable.
> > >
> > > Kalle
> > >
> > > PS. @Alex - yes, can configure default persistence strategy with
> > > @Meta("tapestry.persistence-strategy=client") per page - but that only
> > > works if the components don't require an explicit persistence strategy
> > >
> >
> >
> >
> > --
> > George Christman
> > CEO
> > www.CarDaddy.com
> > P.O. Box 735
> > Johnstown, New York
> >
>



-- 
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York

Re: Sticky Sessions

[Barry Books]

I have a URL persist I wrote to solve this problem. It moves the grids data
from the session into URL parameters.

I'll post the code later today

On Thursday, December 4, 2014, Kalle Korhonen 
wrote:

> On Thu, Dec 4, 2014 at 12:08 PM, George Christman  >
> wrote:
>
> > I'd have to say 98% of my app is stateless, I only have a few admin pages
> > that still use tapestry grid. Other than that Captcha and Tapestry
> Security
> > redirect seem to be the only two items effected by this, so I don't think
> > I'll have a memory issue.
> >
>
> Yeah, that's how it should be.
>
>
> > Kalle, I still use AWS and thus far it's been very reasonable. I just
> worry
> > instances being held active and running my bill up because of sticky
> > sessions. I'll admit, I'm no expert in this, so perhaps my understanding
> > isn't correct.
> > Is there any recommendation for the timeout? I currently have it set at
> 0.
> >
>
> That's your issue then, you want to set it to a positive number to let them
> expire. From the servlet spec: "If the timeout is 0 or less, the container
> ensures the default behavior of sessions is never to time out." Personally,
> I'm advocating use of short session expiration (in the order of 1-5 mins),
> then extending it via async calls (as described in
> http://tynamo.org/tapestry-conversations+guide). At least tomcat has a
> default expiration of 30 mins, I'm not sure if the spec ever said anything
> about it.
>
> Kalle
>
>
>
> > On Thu, Dec 4, 2014 at 1:26 PM, Kalle Korhonen <
> kalle.o.korho...@gmail.com 
> > >
> > wrote:
> >
> > > On Thu, Dec 4, 2014 at 5:54 AM, George Christman <
> > gchrist...@cardaddy.com >
> > > wrote:
> > >
> > > > Hi guys, so I've had a slew of strange behaviors over the past few
> > months
> > > > with a few different Tapestry components such as Tapestry Grid,
> > Tapestry
> > > > Captcha, and writting/removing cookies. Last night I was finally able
> > to
> > > > fix them, but at the cost of a sticky session. My application sits
> > > behind a
> > > > load balancer, so my question is why do I need to use a sticky
> session
> > > and
> > > > how do I avoid the use of them? I'm concerned with the fact this is
> > going
> > > > to cause a scaling dilemma.
> > > >
> > >
> > > I'd almost say that sticky sessions are more the norm than the
> exception
> > > for Java web applications. Unless you change your implementation, you
> > have
> > > a choice between sticky sessions or replicated/centeralized sessions.
> > > Sessions in your cluster are probably not managed by memcached or some
> > such
> > > (which is another single point of failure), causing the strange
> behavior.
> > > Furthermore, I see neither session usage nor sticky sessions as
> > inherently
> > > bad. Memory is cheap although in today's cloud managed solutions using
> > > memory may end up costing extra to you. It depends on how your load
> > > balancer works and whether the bottleneck in a typical usage pattern is
> > cpu
> > > or memory. Even if your load balancer does a simple random choice but
> > > memory doesn't cost you, you are most likely fine with sticky sessions.
> > If
> > > additional servers cost you, but you can do dynamic horizontal scaling
> > with
> > > cpu/memory thresholds to spawn new instances, then sticky sessions are
> > > actually desirable.
> > >
> > > Kalle
> > >
> > > PS. @Alex - yes, can configure default persistence strategy with
> > > @Meta("tapestry.persistence-strategy=client") per page - but that only
> > > works if the components don't require an explicit persistence strategy
> > >
> >
> >
> >
> > --
> > George Christman
> > CEO
> > www.CarDaddy.com
> > P.O. Box 735
> > Johnstown, New York
> >
>

Re: Sticky Sessions

[Kalle Korhonen]

On Thu, Dec 4, 2014 at 12:08 PM, George Christman 
wrote:

> I'd have to say 98% of my app is stateless, I only have a few admin pages
> that still use tapestry grid. Other than that Captcha and Tapestry Security
> redirect seem to be the only two items effected by this, so I don't think
> I'll have a memory issue.
>

Yeah, that's how it should be.


> Kalle, I still use AWS and thus far it's been very reasonable. I just worry
> instances being held active and running my bill up because of sticky
> sessions. I'll admit, I'm no expert in this, so perhaps my understanding
> isn't correct.
> Is there any recommendation for the timeout? I currently have it set at 0.
>

That's your issue then, you want to set it to a positive number to let them
expire. From the servlet spec: "If the timeout is 0 or less, the container
ensures the default behavior of sessions is never to time out." Personally,
I'm advocating use of short session expiration (in the order of 1-5 mins),
then extending it via async calls (as described in
http://tynamo.org/tapestry-conversations+guide). At least tomcat has a
default expiration of 30 mins, I'm not sure if the spec ever said anything
about it.

Kalle



> On Thu, Dec 4, 2014 at 1:26 PM, Kalle Korhonen  >
> wrote:
>
> > On Thu, Dec 4, 2014 at 5:54 AM, George Christman <
> gchrist...@cardaddy.com>
> > wrote:
> >
> > > Hi guys, so I've had a slew of strange behaviors over the past few
> months
> > > with a few different Tapestry components such as Tapestry Grid,
> Tapestry
> > > Captcha, and writting/removing cookies. Last night I was finally able
> to
> > > fix them, but at the cost of a sticky session. My application sits
> > behind a
> > > load balancer, so my question is why do I need to use a sticky session
> > and
> > > how do I avoid the use of them? I'm concerned with the fact this is
> going
> > > to cause a scaling dilemma.
> > >
> >
> > I'd almost say that sticky sessions are more the norm than the exception
> > for Java web applications. Unless you change your implementation, you
> have
> > a choice between sticky sessions or replicated/centeralized sessions.
> > Sessions in your cluster are probably not managed by memcached or some
> such
> > (which is another single point of failure), causing the strange behavior.
> > Furthermore, I see neither session usage nor sticky sessions as
> inherently
> > bad. Memory is cheap although in today's cloud managed solutions using
> > memory may end up costing extra to you. It depends on how your load
> > balancer works and whether the bottleneck in a typical usage pattern is
> cpu
> > or memory. Even if your load balancer does a simple random choice but
> > memory doesn't cost you, you are most likely fine with sticky sessions.
> If
> > additional servers cost you, but you can do dynamic horizontal scaling
> with
> > cpu/memory thresholds to spawn new instances, then sticky sessions are
> > actually desirable.
> >
> > Kalle
> >
> > PS. @Alex - yes, can configure default persistence strategy with
> > @Meta("tapestry.persistence-strategy=client") per page - but that only
> > works if the components don't require an explicit persistence strategy
> >
>
>
>
> --
> George Christman
> CEO
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
>

Re: Sticky Sessions

[George Christman]

I'd have to say 98% of my app is stateless, I only have a few admin pages
that still use tapestry grid. Other than that Captcha and Tapestry Security
redirect seem to be the only two items effected by this, so I don't think
I'll have a memory issue.

Kalle, I still use AWS and thus far it's been very reasonable. I just worry
instances being held active and running my bill up because of sticky
sessions. I'll admit, I'm no expert in this, so perhaps my understanding
isn't correct.

Is there any recommendation for the timeout? I currently have it set at 0.

On Thu, Dec 4, 2014 at 1:26 PM, Kalle Korhonen 
wrote:

> On Thu, Dec 4, 2014 at 5:54 AM, George Christman 
> wrote:
>
> > Hi guys, so I've had a slew of strange behaviors over the past few months
> > with a few different Tapestry components such as Tapestry Grid, Tapestry
> > Captcha, and writting/removing cookies. Last night I was finally able to
> > fix them, but at the cost of a sticky session. My application sits
> behind a
> > load balancer, so my question is why do I need to use a sticky session
> and
> > how do I avoid the use of them? I'm concerned with the fact this is going
> > to cause a scaling dilemma.
> >
>
> I'd almost say that sticky sessions are more the norm than the exception
> for Java web applications. Unless you change your implementation, you have
> a choice between sticky sessions or replicated/centeralized sessions.
> Sessions in your cluster are probably not managed by memcached or some such
> (which is another single point of failure), causing the strange behavior.
> Furthermore, I see neither session usage nor sticky sessions as inherently
> bad. Memory is cheap although in today's cloud managed solutions using
> memory may end up costing extra to you. It depends on how your load
> balancer works and whether the bottleneck in a typical usage pattern is cpu
> or memory. Even if your load balancer does a simple random choice but
> memory doesn't cost you, you are most likely fine with sticky sessions. If
> additional servers cost you, but you can do dynamic horizontal scaling with
> cpu/memory thresholds to spawn new instances, then sticky sessions are
> actually desirable.
>
> Kalle
>
> PS. @Alex - yes, can configure default persistence strategy with
> @Meta("tapestry.persistence-strategy=client") per page - but that only
> works if the components don't require an explicit persistence strategy
>



-- 
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York

Re: Sticky Sessions

[Kalle Korhonen]

On Thu, Dec 4, 2014 at 5:54 AM, George Christman 
wrote:

> Hi guys, so I've had a slew of strange behaviors over the past few months
> with a few different Tapestry components such as Tapestry Grid, Tapestry
> Captcha, and writting/removing cookies. Last night I was finally able to
> fix them, but at the cost of a sticky session. My application sits behind a
> load balancer, so my question is why do I need to use a sticky session and
> how do I avoid the use of them? I'm concerned with the fact this is going
> to cause a scaling dilemma.
>

I'd almost say that sticky sessions are more the norm than the exception
for Java web applications. Unless you change your implementation, you have
a choice between sticky sessions or replicated/centeralized sessions.
Sessions in your cluster are probably not managed by memcached or some such
(which is another single point of failure), causing the strange behavior.
Furthermore, I see neither session usage nor sticky sessions as inherently
bad. Memory is cheap although in today's cloud managed solutions using
memory may end up costing extra to you. It depends on how your load
balancer works and whether the bottleneck in a typical usage pattern is cpu
or memory. Even if your load balancer does a simple random choice but
memory doesn't cost you, you are most likely fine with sticky sessions. If
additional servers cost you, but you can do dynamic horizontal scaling with
cpu/memory thresholds to spawn new instances, then sticky sessions are
actually desirable.

Kalle

PS. @Alex - yes, can configure default persistence strategy with
@Meta("tapestry.persistence-strategy=client") per page - but that only
works if the components don't require an explicit persistence strategy

Re: Sticky Sessions

[Alex Kotchnev]

George - sounds like those components might be using session persistence
for some of their data (e.g. in the case of Grid it uses @Persist , which
defaults to session persistence, to store the GridPaginationModel - e.g.
https://github.com/apache/tapestry-5/blob/master/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Grid.java)
. I'm not sure if there is a way to change the default behavior of @Persist
(knowing tapestry , there probably is) if you want your app to be totally
stateless (or at least not store state in the session) but I'm not entirely
sure how much that will buy you in terms of general scalability (other than
being able to check the box of "we're not using the servlet session").

I doubt that this would be a scaling issue but certainly something that
would be nice if there is a way to know that about a component (before you
use it). The Grid javadocs for 5.4 seem to provide an option for that (e.g.
http://tapestry.apache.org/5.4/apidocs/org/apache/tapestry5/corelib/components/Grid.html
, the defaultPaginationModel parameter)

Cheers - Alex K

On Thu, Dec 4, 2014 at 8:54 AM, George Christman 
wrote:

> Hi guys, so I've had a slew of strange behaviors over the past few months
> with a few different Tapestry components such as Tapestry Grid, Tapestry
> Captcha, and writting/removing cookies. Last night I was finally able to
> fix them, but at the cost of a sticky session. My application sits behind a
> load balancer, so my question is why do I need to use a sticky session and
> how do I avoid the use of them? I'm concerned with the fact this is going
> to cause a scaling dilemma.
>

Re: Tapestry5 jquery ajaxupload

[George Christman]

For something simple like messages, you might be able to just pass in your
own json object through params.

https://github.com/got5/tapestry5-jquery/blob/master/src/main/java/org/got5/tapestry5/jquery/components/AjaxUpload.java

It looks like line 164 they are doing a merge.

On Thu, Dec 4, 2014 at 9:04 AM, George Christman 
wrote:

> I ended up having to several modify that component to get it to do what I
> wanted it to do. It's very difficult to modify the template because the
> core file upload js depends on a lot of the elements within the template.
> Anyhow, I ended up using Tapestry5-jquery as a base to build my own version
> and here you'll see my connector and where I'm modifying some of the
> template. https://www.cardaddy.com/modules/upload.js
>
> On Wed, Dec 3, 2014 at 8:33 AM, Bosch, Christian 
> wrote:
>
>> Hello,
>>
>> I'm writing a tapestry component using Tapestry5-Jquery AjaxUpload.
>> I would like to customize UI (template & file template) and change
>> captions/messages. But I can't find any sample to handle this.
>>
>> Do you a sample or a link to a sample AjaxUpload integration ?
>>
>> Thanks for your help.
>>
>> C. Bosch.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>
>
> --
> George Christman
> CEO
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
>
>


-- 
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York

Re: Tapestry5 jquery ajaxupload

[George Christman]

I ended up having to several modify that component to get it to do what I
wanted it to do. It's very difficult to modify the template because the
core file upload js depends on a lot of the elements within the template.
Anyhow, I ended up using Tapestry5-jquery as a base to build my own version
and here you'll see my connector and where I'm modifying some of the
template. https://www.cardaddy.com/modules/upload.js

On Wed, Dec 3, 2014 at 8:33 AM, Bosch, Christian  wrote:

> Hello,
>
> I'm writing a tapestry component using Tapestry5-Jquery AjaxUpload.
> I would like to customize UI (template & file template) and change
> captions/messages. But I can't find any sample to handle this.
>
> Do you a sample or a link to a sample AjaxUpload integration ?
>
> Thanks for your help.
>
> C. Bosch.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>


-- 
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York

Sticky Sessions

[George Christman]

Hi guys, so I've had a slew of strange behaviors over the past few months
with a few different Tapestry components such as Tapestry Grid, Tapestry
Captcha, and writting/removing cookies. Last night I was finally able to
fix them, but at the cost of a sticky session. My application sits behind a
load balancer, so my question is why do I need to use a sticky session and
how do I avoid the use of them? I'm concerned with the fact this is going
to cause a scaling dilemma.

Re: How to access tapestry validation results inside jquery

[Barry Books]

In 5.4 there is an event for this.


define(["jquery","t5/core/events"], *function*($,events) {



   *return* *function*(parameters) {

 $('#'+parameters.id + ' :submit').removeAttr('disabled');



 $('#'+parameters.id).bind(events.form.prepareForSubmit,
*function*() {

$('#'+parameters.id + ' :submit').attr('disabled',
'disabled');

$('#'+parameters.id + ' :submit').val("Please Wait")

 });

   };

});



*public* *class* Sub1 {

   @Inject

   *private* JavaScriptSupport javaScriptSupport;



   @Inject

   *private* FormSupport formSupport;



   *void* afterRender(MarkupWriter writer) {

 JSONObject params = *new* JSONObject();

 params.put("id",formSupport.getClientId());

 javaScriptSupport.require("sub1").with(params);

   }



}

On Wed, Dec 3, 2014 at 7:43 AM, Sumanth  wrote:

> Hello Gurus,
>
> I have a ajax form component with a submit button. My requirement is to
> change the label of the button to "submitting.." and disable the button on
> the form submit. This form component has a select input field.
>
>t:value="selectedTrainee"
> t:model="traineeOptionSelectModel"
>
> t:blankLabel="${message:pages.project.ProjectDetail.blankLabel}"
>   t:blankOption="always" t:validate="required" />
>
> The script to disable the button.
>
> define([ "jquery" ], function($) {
>
>   return function(clientIdOfAjaxSubmitButton, processingLabel) {
>
>   var jquerySelectorString = "#" + clientIdOfAjaxSubmitButton;
>   $(jquerySelectorString).on('click', function() {
>
> var form = $(this).parents('form');
>
> form.submit(function(event) {
>
>   $(this).val(processingLabel);
>
>   $(jquerySelectorString).attr('disabled', 'disabled');
> });
>   });
>   }
> });
>
>
> The problem is even thought the select validation fails, the form gets
> posted to the server (It feels like because) the button gets disabled. Is
> there a way to access these validations from the tapestry in my jquery to
> check and  if there are no errors then make the submit else prevent. Or is
> there any other method?
>