The way it was done in the before was, if blocking="true",
regardless of partial or full submit, the _blockOnEverySubmit var is set
to true for that button. I was planning on just pulling that into the
ActionSubmitUtils. So for this, I'm trying to stay away from HOW the
blocking is done... I'd just like something that turns the blocking on
when the button is clicked. Hopefully it wouldn't be wasted effort when
the "how we do blocking" is changed!
Does that point of view make this more agreeable?
Dave
-----Original Message-----
From: Adam Winer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 15, 2007 2:23 PM
To: MyFaces Development
Subject: Re: [Trinidad] commandButton "blocking"
No, that's a good point: swapping out the PPR code
for XMLHttp would just change how we do blocking
for partial submits - it wouldn't affect blocking for
full submits at all.
-- Adam
On 5/15/07, David Brunette <[EMAIL PROTECTED]> wrote:
>
> Thanks Adam.
>
> If the PPR code is going to change soon to an XMLHTTP basis, then
> yeah, it makes sense to not put too much work into this right now. We
> are looking at having this blocking functionality on both partial AND
> full submits. Would this pending work take both kinds of submits into
> account for the blocking? If so, we can probably sit tight until
then.
>
> Dave
>
> -----Original Message-----
> From: Adam Winer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 15, 2007 11:36 AM
> To: MyFaces Development
> Subject: Re: [Trinidad] commandButton "blocking"
>
> Hi Dave,
>
> I'm reluctant to put too much work into the existing PPR JS codebase;
> a big hope of mine is to switch that codebase over to a modern
> XMLHTTP basis, at which point blocking could be much more
> sensibly implemented.
>
> -- Adam
>
>
>
> On 5/15/07, David Brunette <[EMAIL PROTECTED]> wrote:
> > Hi everybody. I am trying to solve the problem of "multiple
> clicks on
> > a submit button" on the browser side for a full form submit (that
is,
> after
> > the user clicks the submit button, show an hour-glass cursor and
block
> the
> > user from clicking again while the action method is doing its work).
> From
> > looking through the code, I see that the deprecated class
> >
org.apache.myfaces.trinidadinternal.ui.laf.base.desktop.ButtonRenderer
> > reads the 'blocking' attribute from the button (or link) and then,
> > eventually, "_blockOnEverySubmit=true;" is added to the onclick for
> the
> > button.
> >
> >
> >
> > But like I said... that class is deprecated. Looking at
> > CommandLinkRenderer or ActionSubmitUtils, it looks like this chunk
of
> code
> > was not carried over. Does anybody know if there was a specific
> reason for
> > leaving this out? We would love to have that functionality back in
> there,
> > and if there was no specific reason to exclude that from
> AutoSubmitUtils
> > then I'd be happy to create an issue and provide a patch...
> >
> >
> >
> > Dave
> > The information transmitted herewith is sensitive information of
> Chordiant
> > Software or its customers and is intended only for use to the
> individual or
> > entity to which it is addressed. If the reader of this message is
not
> the
> > intended recipient, you are hereby notified that any review,
> retransmission,
> > dissemination, distribution, copying or other use of, or taking of
any
> > action in reliance upon, this information is strictly prohibited. If
> you
> > have received this communication in error, please contact the sender
> and
> > delete the material from your computer.
> The information transmitted herewith is sensitive information of
Chordiant Software or its customers and is intended only for use to the
individual or entity to which it is addressed. If the reader of this
message is not the intended recipient, you are hereby notified that any
review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon, this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
>
The information transmitted herewith is sensitive information of Chordiant
Software or its customers and is intended only for use to the individual or
entity to which it is addressed. If the reader of this message is not the
intended recipient, you are hereby notified that any review, retransmission,
dissemination, distribution, copying or other use of, or taking of any action
in reliance upon, this information is strictly prohibited. If you have received
this communication in error, please contact the sender and delete the material
from your computer.
