No argument there. But like any respectable programmer, I am lazy. ;-)
I'm using a framework to take the drudgery out of web programming.
Do I have to add disabling code for every request-sending widget?
If the answer is yes then ... this is why I have not done it!
(When a client has requested d
And where exactly does the "user experience" fit in to all of this cool
server side trickery? I mean, even in a basic swing application I would
disable input on things people aren't allowed to use when I'm doing
something that will potentially take a long time to complete.
The browser is your fri
IMO, disabling a submit with javascript is a hack. The problem is common,
and a natural consequence of using Tapestry to develop a web application.
Tapestry should be taking care of it for us.
In any case, this can be solved in the same way that the old "locked after
a commit()" errors in T3 were
erik,
from what i understand you have
Custom Component -> contains Form -> contains PropSel
- when the PropSel changes, then its enclosing Form causes the submit.
i have a suspicion this Form might be causing your Custom Component not to
rewind and hence probably the
Custom Component never
The filter solution does use a unique token on the form and you can disable
the filter by not including the token on a form. I did have to add logic to
the posted solution to handle errors but even with that code included the
code seems to be non-invasive -- all it does is check for form variable
Jesse, you rock!
What I love about tapestry - 2 Books - TIA, EWDT4, and a small forum with
experts on it. Just the right recipe for a wonderful framework :-)
Thanks, Karthik
Fixed and deploying now. (I think... )
On 11/15/06, Josh Long <[EMAIL PROTECTED]> wrote:
Oh man, so there _is_ a cure. Wonderful news.
I was pulling out my hair(s -- were down to just a few at this point that
have the staying power required of a programmers head of hair)..
Thanks again Jesse,
I've created a component that contains a form that contains a
property selection. The property selection item has the submit on
change property. The property selection model and value are on the
component. The form listener is on the component. The page containing
my component does not need
That seems like a complex solution to the problem which does things in
a filter, where it might be difficult to predict side effects or
override the behaviour in certain circumstances. I'd be more inclined
to implement a unique token solution in a base page class so that I
could overload it in ce
You are certainly not without the credit, but I happen to agree with your
Maven2 statement. It has completely changed the way how a lot of Java
projects think about and manage the complexity.
Kalle
On 11/15/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
Thank you for the sentiment. While I do ap
Thank you for the sentiment. While I do appreciate it I have to wonder if
what I'm doing is no different than any other os developer, the only major
difference I see is that maven2 has made managing/deploying
documentation/code changes out to the public an almost completely
transparent process for
Jesse, you are already acting way faster than anybody's used to in an open
source project. Your responsiveness and the short turnaround time for coming
up with these fixes others are reporting continue to amaze me.
Just thought some patting on the back would be in order so you wouldn't
start thin
Oh man, so there _is_ a cure. Wonderful news.
I was pulling out my hair(s -- were down to just a few at this point that
have the staying power required of a programmers head of hair)..
Thanks again Jesse, let me know if there's any more feedback u might
need/anything I could (possibly) do.. :/
Is there a non-javascript solution to this problem? I have been
experimenting with code based on the forum post below. Has anyone developed
a solution for Tapestry? I propose some sort of consensus should
be reached as to what the best method is to handle double submits and a
patch should be ma
I was looking for a sledgehammer to crack a nut. That's how I ended up
doing it (after spending the day looking for an enterprisey solution!)
Thanks
Denis
Jesse Kuhnert wrote:
Why don't you just disable the submit buttons in question when they submit?
(set the disabled attribute to true)
On 11
Why don't you just disable the submit buttons in question when they submit?
(set the disabled attribute to true)
On 11/15/06, Denis McCarthy <[EMAIL PROTECTED]> wrote:
Hi,
I'm encountering a problem in my app where users are double submitting a
form, creating a hibernate exception in the back
Thanks so much!
Richard Kirby wrote:
Hi Peter,
State objects are not the same as HiveMind services. So reg.getService
will return a service you have defined with in a
hivemodule.xml. However these are typically equivalent to singletons
and therefore shared across all sessions. A state objec
Hi Gabriel,
Thanks for the detailed steps. We tried this out, but it didnt work. The
observation here was that only the first item in the collection has the user
entered value while others in the collection dont have their values set.
However I am happy to report that we have solved the issue. W
Hi Peter,
State objects are not the same as HiveMind services. So reg.getService
will return a service you have defined with in a
hivemodule.xml. However these are typically equivalent to singletons and
therefore shared across all sessions. A state object is managed by the
ApplicationStateMa
Thanks Richard, this is truly a bit of magic, one question though
regarding the last step:
Is there any reason why I would need to use the ApplicationStateManager
object, can I rather access a service directly using getService() ?
For instance, I get the registry like so:
Registry reg = (Regi
Hi,
I'm encountering a problem in my app where users are double submitting a
form, creating a hibernate exception in the back end where two
sessions are attempting to update the same collection. I've read some
posts about preventing form resubmission by using a unique token in the
form to det
Hi Peter,
One way of doing this is to access the HiveMind Registry object that
Tapestry creates, from within your listener class, so that you can then
access the ApplicationStateManager, and from that access your ASO.
However, you have to use a little magic to access the Registry object:
1.
What is the best approach for the following scenario:
I have a listener class that listens for session activity, its
configured only in my web.xml (not for instance in hivemind)
I have a state object that I need to inject into the listener class, but
since I cannot make the listener class abstr
Hello,
I have another problem with my dialog:
org.apache.tapestry.BindingException: Binding for parameter hidden default
value (ExpressionBinding[... true]) may not be updated.
[classpath:/org/apache/tapestry/dojo/html/Dialog.jwc, line 29, column 53]
at
org.apache.tapestry.binding.Abstra
24 matches
Mail list logo
