Thanks for the guidance Rémy, this is why I'm posting to this list, I just want something in the base build that includes this functionality, so whatever it takes is fine by me :D
Pete > [EMAIL PROTECTED] wrote: > >>hi guys, >> >>I'm new to this list, but a long time user of Tomcat. For a long time >> now >>I've had a problem which I'm sure most of you are familiar with ; users. >> >>As always happens with any app in development the final tidy up stuff >> gets >>left too late and some stuff gets missed out. The bit in this case was >>holding screens for long running requests. >> >>I've written a filter which will take any request and after a defined >>period of time send a generic "please wait" page, after the original >>request has finished it will then forward the proper response. >> >>To get this to work properly there is an extra benefit, it can in a lot >> of >>cases stop double clickers by ignoring requests that have been defined as >>those not supposed to run concurrently for a given session. >> >>My current implemntation is container agnostic which I'm not really happy >>with as it means the "please wait" page must be large enough to force a >>send of the data though the response stream, however I'm loathe to hack >>into the tomcat code to get low enough to fix this unless it is part of >>tomcat. The second problem is detecting multi-part requests and not >>allowing the "please wait" page until the multi-part data has been >>gathered, currently I just exclude those requests, again a lower level >>access would allow this to be fixed properly. >> >>Is this filter or a derivative something that would be of interest? >> >>The basic features that I've implemented are : >> >>please wait page after some defined period with no user coding >>Multiple concurrent request per session selectively disabled by URL >> >>I can post the code or distribute however people want if this is >> something >>you are interested in. >> >>In live web-apps I've found this invaluable as users don't get web-apps >>and are very impatient, even if the problem is their dodgy old modem or >>asking an app to do something it was never designed for. >> >>Before anyone says it I know this is a complete perversion of everything >>that is supposed to happen in a web-app, however in the real world users >>won't wait 5 seconds for anything unless they are being told it's under >>way and I've never got holding screens in all the right places yet. This >>covers them all and where possible reduces the ability of a single user >> to >>submit 100 concurrent requests by hammering a submit button in >>frustration. >> >>Any feed back is most welcome >> >> > This is not necessarily evil. Of course, I don't know if it's good or > not before seeing the code first. > > Note: if a filter needs internal access to Tomcat APIs, then it should > likely become a valve. > > Rémy > > > --------------------------------------------------------------------- > 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]
