Re: dialog problem in the latest 4.1.1 snapshot
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.AbstractBinding.createReadOnlyBindingException(AbstractBinding.java:114)
at
org.apache.tapestry.binding.ExpressionBinding.setObject(ExpressionBinding.java:166)
at $Dialog_1030.setHidden($Dialog_1030.java)
at org.apache.tapestry.dojo.html.Dialog.show(Dialog.java:43)
...
In .page file:
component id=aDialog type=Dialog/
I want to show the dialog by clicking an async. DirectLink.
Listener:
public void listen() {
Dialog dialog = ((Dialog)getComponent(aDialog));
dialog.show();
}
After dialog.show() I get the exception. Can anyone help me please?
Regards,
Tine
Norbert Sándor wrote:
Sorry, I wanted to send this to the user list instead the developer:
Hi,
The dojo dialog has problems in the latest svn version: on long pages,
if I scroll down the page, the dialog is displayed incorrectly and it is
not modal: the element which is displayed behind the dialog to hide the
page's content is displayed incorrectly.
See this screenshot: http://www.erinors.com/temp/dojo_dialog.jpg
The same error is reproducable at
http://archive.dojotoolkit.org/nightly/tests/widget/test_Dialog.html
The dialog worked correctly with 4.1.1's previous dojo version.
What do you recommend?
Can I switch to the official 3.1 release without breaking tapestry
client side functionality?
Regards,
Norbi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/dialog-problem-in-the-latest-4.1.1-snapshot-tf2371912.html#a7355371
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ASO Injection Question
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 abstract how will I inject my state object? or what can I do otherwise? Thanks Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASO Injection Question
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. From the sessionCreated/sessionDestroyed method you have access to the HttpSessionEvent object. 2. From the HttpSessionEvent object you have access to the HttpSession object. 3. From the HttpSession object you have access to the ServletContext 4. From the ServletContext object you can look up the HiveMind Registry using the getAttribute method with the key org.apache.tapestry.Registry:SERVLET_NAME where SERVLET_NAME is the name of the Tapestry application servlet you have specified in your web.xml (this is the magic bit since it requires knowing how Tapestry squirrels away the Registry object). 5. You can then get the ApplicationStateManager object from the Registry, and finally your ASO. Hope that helps Richard. Peter Stavrinides wrote: 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 abstract how will I inject my state object? or what can I do otherwise? Thanks Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
preventing double submit in tapestry
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 detect a double submit. If a double submit is detected, the second and subsequent submits wait until the original one returns and then report the outcome of that transaction (if I understand correctly, it's the last submit that issues the response to the user, and the first one does the updating). I'm wondering a) is this indeed the right approach to stop users who are over-enthusiastic in their button clicking from encountering errors, and b) does anyone have an actual example of code that implements this pattern? Thanks very much Denis Mc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASO Injection Question
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 = (Registry) event.getSession().getServletContext().getAttribute(org.apache.tapestry.Registry:IRM); //where IRM is the name of the servlet and then use something like: reg.getService(Visit.class); Thanks again, Peter Richard Kirby wrote: 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. From the sessionCreated/sessionDestroyed method you have access to the HttpSessionEvent object. 2. From the HttpSessionEvent object you have access to the HttpSession object. 3. From the HttpSession object you have access to the ServletContext 4. From the ServletContext object you can look up the HiveMind Registry using the getAttribute method with the key org.apache.tapestry.Registry:SERVLET_NAME where SERVLET_NAME is the name of the Tapestry application servlet you have specified in your web.xml (this is the magic bit since it requires knowing how Tapestry squirrels away the Registry object). 5. You can then get the ApplicationStateManager object from the Registry, and finally your ASO. Hope that helps Richard. Peter Stavrinides wrote: 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 abstract how will I inject my state object? or what can I do otherwise? Thanks Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Stavrinides Albourne Partners (Cyprus) Ltd Tel: +357 22 750652 If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASO Injection Question
Hi Peter,
State objects are not the same as HiveMind services. So reg.getService
will return a service you have defined with service-point / in a
hivemodule.xml. However these are typically equivalent to singletons and
therefore shared across all sessions. A state object is managed by the
ApplicationStateManager and can be either a global object (in many ways
a HiveMind service is equivalent), or a session object which is per user
web session.
Note that you only need to get the ApplicationStateManager object once
(use lazy initialization), as it will last for the lifetime of the web
application, so something like:
class MySessionListener implements HttpSessionListener {
private ApplicationStateManager asm;
public void sessionCreated(HttpSessionEvent event) {
if (asm == null) {
Registry reg =
(Registry)event.getSession().getServletContext().getAttribute(org.apache.tapestry.Registry:IRM);
asm =
(ApplicationStateManager)reg.getService(ApplicationStateManager.class);
}
Visit visit = (Visit)asm.get(visit);
// do stuff
}
}
Cheers
Richard
Peter Stavrinides wrote:
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 = (Registry)
event.getSession().getServletContext().getAttribute(org.apache.tapestry.Registry:IRM);
//where IRM is the name of the servlet
and then use something like:
reg.getService(Visit.class);
Thanks again,
Peter
Richard Kirby wrote:
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. From the sessionCreated/sessionDestroyed method you have access to
the HttpSessionEvent object.
2. From the HttpSessionEvent object you have access to the
HttpSession object.
3. From the HttpSession object you have access to the ServletContext
4. From the ServletContext object you can look up the HiveMind
Registry using the getAttribute method with the key
org.apache.tapestry.Registry:SERVLET_NAME where SERVLET_NAME is the
name of the Tapestry application servlet you have specified in your
web.xml (this is the magic bit since it requires knowing how Tapestry
squirrels away the Registry object).
5. You can then get the ApplicationStateManager object from the
Registry, and finally your ASO.
Hope that helps
Richard.
Peter Stavrinides wrote:
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 abstract how will I
inject my state object? or what can I do otherwise?
Thanks
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ForBean issues
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. We had to use the DefaultPrimaryKeyConverter as Lutz suggested and it works. We fed the converter in pageBeginRender and had to access the collection through the converter.getValues() in the listener. This actually brings up another question. If I have to use the converter by default for getting to the changed values, it doesnt somehow seem right. I thought the converter existed for an all together different purpose of providing the primary key values to the For loop and viceversa, and not to access changed values. Either I am doing something that is absolutely not right or this might be a bug(?). Another thing I forgot to mention which might be of interest to people is that we were using the JAG 6.1 generated files. It looks like their delete function in the list pages which uses checkboxes is also not working for this reason. Thanks, Srini. On 11/15/06, Gabriel Lozano [EMAIL PROTECTED] wrote: Hey what I do is the following: 1. You have to initialize the collection somewhere. Yes, pageBeginRender is ok ( well, sorry for the tapestry gurus, but I have also done it that way ). And dont have to initialize it in the rewind phase. 2. What I do is to hide the collection in the form. Oh, what I did sometime was to persist the collection property ( tap 3) but now I prefer to do this. Items in the collection should implement serializable interface. In your code I would do: form jwcid=[EMAIL PROTECTED] listener=listener:saveFormHistory span jwcid=@Hidden value=ognl:items/ ... tr jwcid=@For source=ognl:items value=ognl:item element=tr tdspan jwcid=@Insert value=ognl:item.question.textQuestion Text/span/td tdinput jwcid=@TextField value=ognl:item.answerText//td /tr 3. I dont pass parameters to the submit method, I think you dont need it. 4. With this, in the submit or in the form listener you should have access to the updated collection. Tell me if this works for you. Gabriel H. Lozano M. On 11/14/06, Srinivas Yermal [EMAIL PROTECTED] wrote: Thanks so much for the response. I will try out the DefaultPrimaryKeyConverter and InvokeListener options. My comments inline - Anyway.. about your code: obviously, I can't tell you which is best. But I think you don't have to pass your items as a parameter to the listener method. Instead, the form fields (in this case, the collection) will be bound to an instance variable in your page object. Maybe you should drop that parameters attribute in the @Submit. But you have to make sure the list is not null during rewind, and has the right length, so you have to refill it before the rewind, and the values will be overwritten during rewind. I tried not passing them as parameter initially, but that didnt work. Setting the parameter was something that I guessed might work, but it doesnot. I have also made sure that the items object is not null during rewind phase by removing the if condition in pageBeginRender, but all it does is gives me the same items without change to any values. On a side note, actually it might turn out be a overhead in large pages if I have to run the query again just for the rewind phase. Moreover, the collection is serialised and is available from the form, isnt it? Shouldnt it be deserialized? I have another observation to add. I have a method that returns the PropertySelectionModel for each item depending on the item. This is required for the dropdowns for each item. The dropdown values depend on the item. During the rewind phase this method gets called and I get proper objects with proper values. But when the submit listener gets called I still get a null collection or the old collection. Is there any other method like say renderComponent of the page that I have to implement? The listener method that is called will be the one referenced in the @Submit component. In your case, the one referenced in the @Form is never called, I think. So you might want to lose on of those two, to avoid confusion. Actually, both the listeners get called. The form listener gets invoked last. I have both the listeners just as an experiment to see if I get a non-null proper collection in any listener at all. Thank you very much for the advice. Will continue trying and see where this goes. Its just that I am running out of time. Regards, Srini. -- http://www.indygosoft.com
Re: ASO Injection Question
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 service-point / in a
hivemodule.xml. However these are typically equivalent to singletons
and therefore shared across all sessions. A state object is managed by
the ApplicationStateManager and can be either a global object (in many
ways a HiveMind service is equivalent), or a session object which is
per user web session.
Note that you only need to get the ApplicationStateManager object once
(use lazy initialization), as it will last for the lifetime of the web
application, so something like:
class MySessionListener implements HttpSessionListener {
private ApplicationStateManager asm;
public void sessionCreated(HttpSessionEvent event) {
if (asm == null) {
Registry reg =
(Registry)event.getSession().getServletContext().getAttribute(org.apache.tapestry.Registry:IRM);
asm =
(ApplicationStateManager)reg.getService(ApplicationStateManager.class);
}
Visit visit = (Visit)asm.get(visit);
// do stuff
}
}
Cheers
Richard
Peter Stavrinides wrote:
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 = (Registry)
event.getSession().getServletContext().getAttribute(org.apache.tapestry.Registry:IRM);
//where IRM is the name of the servlet
and then use something like:
reg.getService(Visit.class);
Thanks again,
Peter
Richard Kirby wrote:
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. From the sessionCreated/sessionDestroyed method you have access
to the HttpSessionEvent object.
2. From the HttpSessionEvent object you have access to the
HttpSession object.
3. From the HttpSession object you have access to the ServletContext
4. From the ServletContext object you can look up the HiveMind
Registry using the getAttribute method with the key
org.apache.tapestry.Registry:SERVLET_NAME where SERVLET_NAME is
the name of the Tapestry application servlet you have specified in
your web.xml (this is the magic bit since it requires knowing how
Tapestry squirrels away the Registry object).
5. You can then get the ApplicationStateManager object from the
Registry, and finally your ASO.
Hope that helps
Richard.
Peter Stavrinides wrote:
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 abstract how will
I inject my state object? or what can I do otherwise?
Thanks
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Peter Stavrinides
Albourne Partners (Cyprus) Ltd
Tel: +357 22 750652
If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: preventing double submit in tapestry
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 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 detect a double submit. If a double submit is detected, the second and subsequent submits wait until the original one returns and then report the outcome of that transaction (if I understand correctly, it's the last submit that issues the response to the user, and the first one does the updating). I'm wondering a) is this indeed the right approach to stop users who are over-enthusiastic in their button clicking from encountering errors, and b) does anyone have an actual example of code that implements this pattern? Thanks very much Denis Mc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: preventing double submit in tapestry
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 made for Tapestry. Any comments? Ideas? quote from Forum Post There is a server-side solution for this problem. Here is the concept: Build a way to identify each form from which a request (or multiple requests, if the form button is clicked several times) arrives. This can be done by having a hidden input element included in the form, whose value is a unique number (typically using the time in milliseconds). Write a filter implementing the javax.servlet.Filter interface, with the following logic in the doFilter() method: Synchronize a code block on a session-scoped object. Inside this block, check if the form-id received through the current request is same as the one received previously. If different, this is the first request received from the form (i.e. the request originated as a result of the first click). If same, this is a subsequent request, generated as a result of multiple clicks. In the first case, invoke FilterChain.doFilter() by passing a ResponseWrapper object instead of the original response object. This ResponseWrapper object should be built with a ByteArrayOutputStream object, so that the response content can be extracted as a String. When the FilterChain.doFilter() method returns, save the response content and the current form-id in session-scope, for subsequent requests and leave the synchronized block. Then outside the synchronized block, forward all the requests (including the first one) to a LoopBackServlet with the original request and response objects. The whole purpose of this LoopBackServlet is to write the saved response content into the response object. In this way, when multiple requests arrive from the same form as a result of multiple clicks, we let the first request thread proceed, with a response-wrapper and block all the other threads. When the first thread returns with the response ready, the response content is stored in session and the same is written to all the blocked threads when they become unblocked. If anybody wants more details, please email me at [EMAIL PROTECTED], I can send the working code. /quote from Forum Post http://forum.java.sun.com/thread.jspa?threadID=665472start=15tstart=0 On 11/15/06, Denis McCarthy [EMAIL PROTECTED] wrote: 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/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 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 detect a double submit. If a double submit is detected, the second and subsequent submits wait until the original one returns and then report the outcome of that transaction (if I understand correctly, it's the last submit that issues the response to the user, and the first one does the updating). I'm wondering a) is this indeed the right approach to stop users who are over-enthusiastic in their button clicking from encountering errors, and b) does anyone have an actual example of code that implements this pattern? Thanks very much Denis Mc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Images aren't showing up if I create my own dojo build and then instruct tapestry to use that.i
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.. :/ Thanks, Josh On 11/14/06, Jesse Kuhnert [EMAIL PROTECTED] wrote: Almost done, just a couple things to fix up on the dojo side first. (probably the part that will take the longest) On 11/14/06, Jesse Kuhnert [EMAIL PROTECTED] wrote: That doesn't sound like much fun. Sorry :/ p.s. i'm working on it now so it'll likely be fixed today or tomorrow On 11/14/06, Josh Long [EMAIL PROTECTED] wrote: I think... that the original dojo/ in the tapestry jar is shadowing mine and so now whether i use dojoSource = .. and dojoPath or not, the same 204k dojo.js is loaded. (this despite a few cache clearings) Anyway, that's a no-go.. Thanks, Josh On 11/14/06, Josh Long [EMAIL PROTECTED] wrote: Thats an idea! .. lemme give it a go and ill get back to you... Thanks, josh On 11/14/06, Jesse Kuhnert [EMAIL PROTECTED] wrote: HmmI wonder what would happen if you renamed your rrl_dojo_04 directory to dojo ? On 11/14/06, Josh Long [EMAIL PROTECTED] wrote: I... dont see any errors in the logs... and that would be kind of weird because the images in my own custom widgets load just fine... And in fact it would be kind of weird if only because the images in the default dojo distro (the one in the jars themselves) load just fine.. Thanks, Josh On 11/14/06, Jesse Kuhnert [EMAIL PROTECTED] wrote: Contains Errors ? Does your server show any errors? Is it possible that jetty or tomcat are deciding to interfere with the images as well? On 11/14/06, Josh Long [EMAIL PROTECTED] wrote: interesting... my firebug doesnt show the path to the image (nor does it even say its requested it) in either the known-to-work version that comes back when i remove the dojoSource/dojoPath params or in my custom build ) However, I moused over oen fo the images and viewed the properties for the image (that is, i do have a blank square that acts as an image where the image should be) and the source is: http://192.168.2.107:8080/view/assets/static/rrl_dojo_04/src/widget/templates/images/combo_box_arrow.png i went ot that url and got: The image http://192.168.2.107:8080/view/assets/static/rrl_dojo_04/src/widget/templates/images/combo_box_arrow.png cannot be displayed, because it contains errors. Anyway, thanks for your prompt reply, Josh On 11/14/06, Jesse Kuhnert [EMAIL PROTECTED] wrote: Do you have FireBug installed? (or fiddler for ie) Can you track the url request for one of these images that aren't showing up and paste it into your location bar to hit it directly and tell me what happens? On 11/14/06, Josh Long [EMAIL PROTECTED] wrote: Images aren't showing up if I create my own dojo build and then instruct tapestry to use that buidl. Everything else seems to work fine, but the images for, say, the autocompleter dont show up. I'm not sure if this is a dojo or a tapestry question. Any help would be appreciated. Josh -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: dialog problem in the latest 4.1.1 snapshot
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 thinking people don't appreciate your work, Kalle On 10/2/06, Jesse Kuhnert [EMAIL PROTECTED] wrote: Yeah, if you must have it working this way until then. (I would normally act faster - but since I'm not directly supporting it yet I'm giving higher priority to other things first. Like the timepicker issue reported today + others.) On 10/3/06, Norbert Sándor [EMAIL PROTECTED] wrote: Thanks, Jesse! Until the weekend should I use the svn head version of dojo? Regards, Norbi Jesse Kuhnert wrote: Yeah that was helpful Norbert, thanks. I've corrected the problem in dojo, it'll be visible in Tapestry the next time I update dojo again. (maybe this weekend? ) On 10/2/06, Norbert Sándor [EMAIL PROTECTED] wrote: I have the same incorrect behaviour in IE6 and FF1.5.0.7, both on the dojo test page and in case of my tapestry application. At http://archive.dojotoolkit.org/nightly/tests/widget/test_Dialog.html I scroll to the second Show link then click it: http://www.erinors.com/temp/1.jpg I drew a red line to indicate the misplaced background element: above the line the screen is modal, below the line it is not modal. I can even select the text behind the dialog: Please see http://www.erinors.com/temp/2.jpg When I scroll the page into any direction the background element grows to the correct size: http://www.erinors.com/temp/3.jpg As you see, now all text is correctly gray behind the dialog. I hope this helps to reproduce the error. I can reproduce it in IE and FF after clearing caches, etc. Regards, Norbi Jesse Kuhnert wrote: I'm sorry but I don't see this behavior with the latest nightly that you pointed out. Is there a specific browser that you are using? I'm going to go ahead and guess that this is with some version of IE right? Are you setting a doctype in your html so as to avoid any quircksmode fun? This can also happen with certain weird css situations where the document body doesn't correctly report back its width/height. On 10/2/06, Norbert Sándor [EMAIL PROTECTED] wrote: Sorry, I wanted to send this to the user list instead the developer: Hi, The dojo dialog has problems in the latest svn version: on long pages, if I scroll down the page, the dialog is displayed incorrectly and it is not modal: the element which is displayed behind the dialog to hide the page's content is displayed incorrectly. See this screenshot: http://www.erinors.com/temp/dojo_dialog.jpg The same error is reproducable at http://archive.dojotoolkit.org/nightly/tests/widget/test_Dialog.html The dialog worked correctly with 4.1.1's previous dojo version. What do you recommend? Can I switch to the official 3.1 release without breaking tapestry client side functionality? Regards, Norbi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.12.11/460 - Release Date: 2006.10.01. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.12.11/460 - Release Date: 2006.10.01. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: dialog problem in the latest 4.1.1 snapshot
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 me. So, if thanks should go anywhere I would put it with the maven2 developers. On 11/15/06, Kalle Korhonen [EMAIL PROTECTED] wrote: 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 thinking people don't appreciate your work, Kalle On 10/2/06, Jesse Kuhnert [EMAIL PROTECTED] wrote: Yeah, if you must have it working this way until then. (I would normally act faster - but since I'm not directly supporting it yet I'm giving higher priority to other things first. Like the timepicker issue reported today + others.) On 10/3/06, Norbert Sándor [EMAIL PROTECTED] wrote: Thanks, Jesse! Until the weekend should I use the svn head version of dojo? Regards, Norbi Jesse Kuhnert wrote: Yeah that was helpful Norbert, thanks. I've corrected the problem in dojo, it'll be visible in Tapestry the next time I update dojo again. (maybe this weekend? ) On 10/2/06, Norbert Sándor [EMAIL PROTECTED] wrote: I have the same incorrect behaviour in IE6 and FF1.5.0.7, both on the dojo test page and in case of my tapestry application. At http://archive.dojotoolkit.org/nightly/tests/widget/test_Dialog.html I scroll to the second Show link then click it: http://www.erinors.com/temp/1.jpg I drew a red line to indicate the misplaced background element: above the line the screen is modal, below the line it is not modal. I can even select the text behind the dialog: Please see http://www.erinors.com/temp/2.jpg When I scroll the page into any direction the background element grows to the correct size: http://www.erinors.com/temp/3.jpg As you see, now all text is correctly gray behind the dialog. I hope this helps to reproduce the error. I can reproduce it in IE and FF after clearing caches, etc. Regards, Norbi Jesse Kuhnert wrote: I'm sorry but I don't see this behavior with the latest nightly that you pointed out. Is there a specific browser that you are using? I'm going to go ahead and guess that this is with some version of IE right? Are you setting a doctype in your html so as to avoid any quircksmode fun? This can also happen with certain weird css situations where the document body doesn't correctly report back its width/height. On 10/2/06, Norbert Sándor [EMAIL PROTECTED] wrote: Sorry, I wanted to send this to the user list instead the developer: Hi, The dojo dialog has problems in the latest svn version: on long pages, if I scroll down the page, the dialog is displayed incorrectly and it is not modal: the element which is displayed behind the dialog to hide the page's content is displayed incorrectly. See this screenshot: http://www.erinors.com/temp/dojo_dialog.jpg The same error is reproducable at http://archive.dojotoolkit.org/nightly/tests/widget/test_Dialog.html The dialog worked correctly with 4.1.1's previous dojo version. What do you recommend? Can I switch to the official 3.1 release without breaking tapestry client side functionality? Regards, Norbi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.12.11/460 - Release Date: 2006.10.01. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.12.11/460 - Release Date: 2006.10.01. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com -- Jesse
Re: dialog problem in the latest 4.1.1 snapshot
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 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 me. So, if thanks should go anywhere I would put it with the maven2 developers. On 11/15/06, Kalle Korhonen [EMAIL PROTECTED] wrote: 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 thinking people don't appreciate your work, Kalle On 10/2/06, Jesse Kuhnert [EMAIL PROTECTED] wrote: Yeah, if you must have it working this way until then. (I would normally act faster - but since I'm not directly supporting it yet I'm giving higher priority to other things first. Like the timepicker issue reported today + others.) On 10/3/06, Norbert Sándor [EMAIL PROTECTED] wrote: Thanks, Jesse! Until the weekend should I use the svn head version of dojo? Regards, Norbi Jesse Kuhnert wrote: Yeah that was helpful Norbert, thanks. I've corrected the problem in dojo, it'll be visible in Tapestry the next time I update dojo again. (maybe this weekend? ) On 10/2/06, Norbert Sándor [EMAIL PROTECTED] wrote: I have the same incorrect behaviour in IE6 and FF1.5.0.7, both on the dojo test page and in case of my tapestry application. At http://archive.dojotoolkit.org/nightly/tests/widget/test_Dialog.html I scroll to the second Show link then click it: http://www.erinors.com/temp/1.jpg I drew a red line to indicate the misplaced background element: above the line the screen is modal, below the line it is not modal. I can even select the text behind the dialog: Please see http://www.erinors.com/temp/2.jpg When I scroll the page into any direction the background element grows to the correct size: http://www.erinors.com/temp/3.jpg As you see, now all text is correctly gray behind the dialog. I hope this helps to reproduce the error. I can reproduce it in IE and FF after clearing caches, etc. Regards, Norbi Jesse Kuhnert wrote: I'm sorry but I don't see this behavior with the latest nightly that you pointed out. Is there a specific browser that you are using? I'm going to go ahead and guess that this is with some version of IE right? Are you setting a doctype in your html so as to avoid any quircksmode fun? This can also happen with certain weird css situations where the document body doesn't correctly report back its width/height. On 10/2/06, Norbert Sándor [EMAIL PROTECTED] wrote: Sorry, I wanted to send this to the user list instead the developer: Hi, The dojo dialog has problems in the latest svn version: on long pages, if I scroll down the page, the dialog is displayed incorrectly and it is not modal: the element which is displayed behind the dialog to hide the page's content is displayed incorrectly. See this screenshot: http://www.erinors.com/temp/dojo_dialog.jpg The same error is reproducable at http://archive.dojotoolkit.org/nightly/tests/widget/test_Dialog.html The dialog worked correctly with 4.1.1's previous dojo version. What do you recommend? Can I switch to the official 3.1 release without breaking tapestry client side functionality? Regards, Norbi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.12.11/460 - Release Date: 2006.10.01. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.12.11/460 - Release Date:
Re: preventing double submit in tapestry
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 certain pages, if necessary. Simplest solution, but not entirely error proof, would be to stick a unique token in the form (I'm not use you can use a session persistent property in the page, as I don't know when those get written into the session - possibly only after the page is finished processing). Then, when processing any form, check the session location for a token, if it matches, just send back a page saying don't do that. If it isn't found, assume that this is the first time you've seen the form and go ahead and process it. You can add increasing complexity to such a solution depending on what kind of user experience you want and how error-proof you want it. The filter trick is cute, since you can actually serve the same response to multiple requests, but that is often not necessary and sometimes not even desired and it takes too much logic out of the core application for my own comfort level. But disabling a button can be pretty effective against all but an actually malicious user (does anyone build javascript-free web apps these days, especially in tapestry?), and a malicious user can override a unique token all too easily, anyway. If there is a true security or data integrity concern, you'll have to do something that is entirely on the server side in order to prevent manipulation by someone with the smarts to interpret an html file and manually send a post. --sam On 11/15/06, John Menke [EMAIL PROTECTED] wrote: 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 made for Tapestry. Any comments? Ideas? quote from Forum Post There is a server-side solution for this problem. Here is the concept: Build a way to identify each form from which a request (or multiple requests, if the form button is clicked several times) arrives. This can be done by having a hidden input element included in the form, whose value is a unique number (typically using the time in milliseconds). Write a filter implementing the javax.servlet.Filter interface, with the following logic in the doFilter() method: Synchronize a code block on a session-scoped object. Inside this block, check if the form-id received through the current request is same as the one received previously. If different, this is the first request received from the form (i.e. the request originated as a result of the first click). If same, this is a subsequent request, generated as a result of multiple clicks. In the first case, invoke FilterChain.doFilter() by passing a ResponseWrapper object instead of the original response object. This ResponseWrapper object should be built with a ByteArrayOutputStream object, so that the response content can be extracted as a String. When the FilterChain.doFilter() method returns, save the response content and the current form-id in session-scope, for subsequent requests and leave the synchronized block. Then outside the synchronized block, forward all the requests (including the first one) to a LoopBackServlet with the original request and response objects. The whole purpose of this LoopBackServlet is to write the saved response content into the response object. In this way, when multiple requests arrive from the same form as a result of multiple clicks, we let the first request thread proceed, with a response-wrapper and block all the other threads. When the first thread returns with the response ready, the response content is stored in session and the same is written to all the blocked threads when they become unblocked. If anybody wants more details, please email me at [EMAIL PROTECTED], I can send the working code. /quote from Forum Post http://forum.java.sun.com/thread.jspa?threadID=665472start=15tstart=0 On 11/15/06, Denis McCarthy [EMAIL PROTECTED] wrote: 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/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 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 detect a double submit. If a double submit is
Q: Tapestry 4.0.2 - Component containing a form containing a property selection fails on submit
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 to know that there is a form. When a new value is selected, Tapestry throws a null pointer exception in PropertySelection.rewindFormComponent trying to access its model via the abstract getter getModel() My component does ensure that the property selection model is created in its prepareForRender method. Does my page need to know about the form inside my component? Is there some component property or method that I need to know about? Is form submission restricted to pages? --- Erik Husby Senior Software Engineer Broad Institute of MIT and Harvard Rm. 2267, 320 Charles St, Cambridge, MA 02141-2023 mobile: 781.354.6669, office: 617.258.9227 email: [EMAIL PROTECTED] AIM: ErikAtBroad
Re: Images aren't showing up if I create my own dojo build and then instruct tapestry to use that.i
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, let me know if there's any more feedback u might need/anything I could (possibly) do.. :/ Thanks, Josh On 11/14/06, Jesse Kuhnert [EMAIL PROTECTED] wrote: Almost done, just a couple things to fix up on the dojo side first. (probably the part that will take the longest) On 11/14/06, Jesse Kuhnert [EMAIL PROTECTED] wrote: That doesn't sound like much fun. Sorry :/ p.s. i'm working on it now so it'll likely be fixed today or tomorrow On 11/14/06, Josh Long [EMAIL PROTECTED] wrote: I think... that the original dojo/ in the tapestry jar is shadowing mine and so now whether i use dojoSource = .. and dojoPath or not, the same 204k dojo.js is loaded. (this despite a few cache clearings) Anyway, that's a no-go.. Thanks, Josh On 11/14/06, Josh Long [EMAIL PROTECTED] wrote: Thats an idea! .. lemme give it a go and ill get back to you... Thanks, josh On 11/14/06, Jesse Kuhnert [EMAIL PROTECTED] wrote: HmmI wonder what would happen if you renamed your rrl_dojo_04 directory to dojo ? On 11/14/06, Josh Long [EMAIL PROTECTED] wrote: I... dont see any errors in the logs... and that would be kind of weird because the images in my own custom widgets load just fine... And in fact it would be kind of weird if only because the images in the default dojo distro (the one in the jars themselves) load just fine.. Thanks, Josh On 11/14/06, Jesse Kuhnert [EMAIL PROTECTED] wrote: Contains Errors ? Does your server show any errors? Is it possible that jetty or tomcat are deciding to interfere with the images as well? On 11/14/06, Josh Long [EMAIL PROTECTED] wrote: interesting... my firebug doesnt show the path to the image (nor does it even say its requested it) in either the known-to-work version that comes back when i remove the dojoSource/dojoPath params or in my custom build ) However, I moused over oen fo the images and viewed the properties for the image (that is, i do have a blank square that acts as an image where the image should be) and the source is: http://192.168.2.107:8080/view/assets/static/rrl_dojo_04/src/widget/templates/images/combo_box_arrow.png i went ot that url and got: The image http://192.168.2.107:8080/view/assets/static/rrl_dojo_04/src/widget/templates/images/combo_box_arrow.png cannot be displayed, because it contains errors. Anyway, thanks for your prompt reply, Josh On 11/14/06, Jesse Kuhnert [EMAIL PROTECTED] wrote: Do you have FireBug installed? (or fiddler for ie) Can you track the url request for one of these images that aren't showing up and paste it into your location bar to hit it directly and tell me what happens? On 11/14/06, Josh Long [EMAIL PROTECTED] wrote: Images aren't showing up if I create my own dojo build and then instruct tapestry to use that buidl. Everything else seems to work fine, but the images for, say, the autocompleter dont show up. I'm not sure if this is a dojo or a tapestry question. Any help would be appreciated. Josh -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source
Re: dialog problem in the latest 4.1.1 snapshot
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
Re: Q: Tapestry 4.0.2 - Component containing a form containing a property selection fails on submit
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 sets the model in its prepareForRender during the rewind. can you put a system.out.println in the Custom Component's prepareForRender and see if it gets printed on the rewind cycle? if not, probably you can consider moving the Form outside your Custom Comp. On 11/16/06, Erik Husby [EMAIL PROTECTED] wrote: 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 to know that there is a form. When a new value is selected, Tapestry throws a null pointer exception in PropertySelection.rewindFormComponent trying to access its model via the abstract getter getModel() My component does ensure that the property selection model is created in its prepareForRender method. Does my page need to know about the form inside my component? Is there some component property or method that I need to know about? Is form submission restricted to pages? --- Erik Husby Senior Software Engineer Broad Institute of MIT and Harvard Rm. 2267, 320 Charles St, Cambridge, MA 02141-2023 mobile: 781.354.6669, office: 617.258.9227 email: [EMAIL PROTECTED] AIM: ErikAtBroad -- Thanks, Karthik
Re: preventing double submit in tapestry
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. I think T4 (via hivemind?) has fixed that particular incarnation. (It happened with all kinds of requests, and when using frames etc.) Use a filter to queue requests from the same client, or discard new ones: http://www.onjava.com/pub/a/onjava/2004/03/24/loadcontrol.html Use a Flow Synchronizer to handle form reposts: http://www.junlu.com/msg/85270.html I find the Flow Synchronizer particularly useful, as I put the bean in my border component and add handling methods to my base page class. Methods such as a simple isRepost() allow special casing the request - to avoid repeating a delete, for instance, but allowing other reposts to proceed. You'll find plenty of posts on the above topics in the list archives. Cheers, Nick. John Menke wrote: 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 and continues normal processing or blocks duplicate requests while caching the response (sounds more complicated than it is) i do see what you mean about the security concern and someone being able to manipulate a post to get past the filter, trying to think of solutions to this problem maybe something where the form included a secure key in a hidden variable and having some sort of check which could determine if a key had been used already if form is secure -- check for valid and unique key -- if key is valid then process the form and expire the key -- don't let another request pass through after key is expired or absent above solution does require the ability to mark certain forms as secure on the server side. with security in place i think the filter solution could be a complete server side solution. I know you mentioned possible side effects did you have anything specific in mind? Bottom line is that there should be a server side solution to this problem in tapestry that is secure and non-invasive. I encourage others to post their ideas in an effort to come to some sort of agreement on best way to accomplish this. -john On 11/15/06, Sam Gendler [EMAIL PROTECTED] wrote: 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 certain pages, if necessary. Simplest solution, but not entirely error proof, would be to stick a unique token in the form (I'm not use you can use a session persistent property in the page, as I don't know when those get written into the session - possibly only after the page is finished processing). Then, when processing any form, check the session location for a token, if it matches, just send back a page saying don't do that. If it isn't found, assume that this is the first time you've seen the form and go ahead and process it. You can add increasing complexity to such a solution depending on what kind of user experience you want and how error-proof you want it. The filter trick is cute, since you can actually serve the same response to multiple requests, but that is often not necessary and sometimes not even desired and it takes too much logic out of the core application for my own comfort level. But disabling a button can be pretty effective against all but an actually malicious user (does anyone build javascript-free web apps these days, especially in tapestry?), and a malicious user can override a unique token all too easily, anyway. If there is a true security or data integrity concern, you'll have to do something that is entirely on the server side in order to prevent manipulation by someone with the smarts to interpret an html file and manually send a post. --sam On 11/15/06, John Menke [EMAIL PROTECTED] wrote: 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 made for Tapestry. Any comments? Ideas? quote from Forum Post There is a server-side solution for this problem. Here is the concept: Build a way to identify each form from which a request (or multiple requests, if the form button is clicked several times) arrives. This can be done by having a hidden input element included in the form, whose value is a unique number
Re: preventing double submit in tapestry
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 friend, not a place where scary hacks happen. It's your UI, embrace it. ;) On 11/15/06, Nick Westgate [EMAIL PROTECTED] wrote: 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. I think T4 (via hivemind?) has fixed that particular incarnation. (It happened with all kinds of requests, and when using frames etc.) Use a filter to queue requests from the same client, or discard new ones: http://www.onjava.com/pub/a/onjava/2004/03/24/loadcontrol.html Use a Flow Synchronizer to handle form reposts: http://www.junlu.com/msg/85270.html I find the Flow Synchronizer particularly useful, as I put the bean in my border component and add handling methods to my base page class. Methods such as a simple isRepost() allow special casing the request - to avoid repeating a delete, for instance, but allowing other reposts to proceed. You'll find plenty of posts on the above topics in the list archives. Cheers, Nick. John Menke wrote: 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 and continues normal processing or blocks duplicate requests while caching the response (sounds more complicated than it is) i do see what you mean about the security concern and someone being able to manipulate a post to get past the filter, trying to think of solutions to this problem maybe something where the form included a secure key in a hidden variable and having some sort of check which could determine if a key had been used already if form is secure -- check for valid and unique key -- if key is valid then process the form and expire the key -- don't let another request pass through after key is expired or absent above solution does require the ability to mark certain forms as secure on the server side. with security in place i think the filter solution could be a complete server side solution. I know you mentioned possible side effects did you have anything specific in mind? Bottom line is that there should be a server side solution to this problem in tapestry that is secure and non-invasive. I encourage others to post their ideas in an effort to come to some sort of agreement on best way to accomplish this. -john On 11/15/06, Sam Gendler [EMAIL PROTECTED] wrote: 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 certain pages, if necessary. Simplest solution, but not entirely error proof, would be to stick a unique token in the form (I'm not use you can use a session persistent property in the page, as I don't know when those get written into the session - possibly only after the page is finished processing). Then, when processing any form, check the session location for a token, if it matches, just send back a page saying don't do that. If it isn't found, assume that this is the first time you've seen the form and go ahead and process it. You can add increasing complexity to such a solution depending on what kind of user experience you want and how error-proof you want it. The filter trick is cute, since you can actually serve the same response to multiple requests, but that is often not necessary and sometimes not even desired and it takes too much logic out of the core application for my own comfort level. But disabling a button can be pretty effective against all but an actually malicious user (does anyone build javascript-free web apps these days, especially in tapestry?), and a malicious user can override a unique token all too easily, anyway. If there is a true security or data integrity concern, you'll have to do something that is entirely on the server side in order to prevent manipulation by someone with the smarts to interpret an html file and manually send a post. --sam On 11/15/06, John Menke [EMAIL PROTECTED] wrote: 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
Re: preventing double submit in tapestry
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 disabled/hidden buttons etc, I've done it, but as I said before, in T3 this server-side trickery is required.) Cheers, Nick. Jesse Kuhnert wrote: 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 friend, not a place where scary hacks happen. It's your UI, embrace it. ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
