I meant for the blocking Button, i also remember implementing this from time to time, so i wondered if there was a general solution to this.
Johannes On 2019-12-31 15:48, Ernesto Reinaldo Barreiro wrote: > Do you mean for the blocker thing? Or for login errors? Or both? > > Happy new year to all. > > On Tue, Dec 31, 2019 at 4:07 PM Johannes Renoth <johannes.ren...@gmx.de> > wrote: > >> Hi Ernesto Reinaldo Barreiro , >> >> Can you provide example code for a solution? Since this is a general >> Problem, maybe it would be helpful to add it to the wicket core libaries. >> >> Have a happy new year, >> >> Johannes Renoth >> >> On 2019-12-30 16:52, Ernesto Reinaldo Barreiro wrote: >>> Hi, >>> >>> One thing I immediately do for any wicket application is rolling a >> blocker >>> DIV preventing users to double click on AJAX links: Situation? User >> clicks >>> in some AJAX link and meanwhile request is being processed the user >> clicks >>> on something "that will not be there" when AJAX request finishes. This >>> blocking logic can be added globally and it is also easy to mark "request >>> and don't show blocker". In my current customer's main application >> rolling >>> out such a solution drastically reduced the number of such errors. >>> >>> For other application, a side project, I remember rolling out a >>> IRequestCycleListener >>> that logged details from errors into some external storage so I had not >>> fight with logs (and there you can store the precise info you need to >> track >>> user's actions). >>> >>> >>> >>> On Mon, Dec 30, 2019 at 5:03 PM Bas Gooren <b...@iswd.nl> wrote: >>> >>>> Hi! >>>> >>>> We see these typos of errors every now and then too. It’s usually people >>>> navigating to old pages, double clicking on links etc. >>>> >>>> Nevertheless, in our logs these are relatively easy to find: we send out >>>> e-mail notifications when such errors occur, and the e-mail includes >> quite >>>> some details (page, component, session id, logged in user etc, user ip); >>>> So far, I have always been able to trace the user’s steps by simply >>>> grepping the access logs for their IP around the time of the exception. >>>> >>>> Should you not be able to do that, I guess it would be relatively >> simple to >>>> track user actions (e.g. the last 10 actions) yourself in the user >> session. >>>> Simply write a request cycle listener, and get some meaningful >> information >>>> from the next handler to be executed. >>>> >>>> E.g. override onRequestHandlerScheduled() and deduct the action from the >>>> request handler; >>>> >>>> ListenerRequestHandler: component or behavior invoked >>>> etc. >>>> >>>> Store the actions as strings (e.g. “render pageX(pageParams=XYZ)”, >> “Click >>>> on link a.b.c in PageX”, “Submit form path.to.component in PageX”). >>>> >>>> If you have an app where users are logged in, you can track the last X >>>> actions in the user’s session; Otherwise you could externalize this >> (either >>>> in-memory by IP, or some other backing store). >>>> When an exception occurs, you can catch it in your request cycle >> listener >>>> and fetch the last user actions. Together, these should provide a better >>>> trail of actions leading up to the exceptions. >>>> >>>> Met vriendelijke groet, >>>> Kind regards, >>>> >>>> Bas Gooren >>>> >>>> Op 30 december 2019 bij 05:24:19, Илья Нарыжный (phan...@ydn.ru) >> schreef: >>>> Hello, >>>> >>>> We have pretty widely used software with thousands of visits per day. >>>> And from time to time we observe pretty weird Wicket related errors >>>> in logs. Commonly it's something about components structure: no such >>>> child, there is already such element and etc. But the problem is that >>>> commonly we can't reproduce the problem right away: page is working as >>>> expected. So such mysterious problems just lie in logs and not being >>>> fixed. >>>> And here is the question: is there some good way to retrieve and log >>>> previous user actions and etc.? Theoretically everything should be in >>>> PageStore. What can you recommend to handle such problems properly? >>>> >>>> P.S. To be able to catch such problems we even build a system for >>>> gathering all logs on a central server and correlate them with each >>>> other according to some correlation logic. But still - no big luck - >>>> so we really believe that problem is in fact that we know only current >>>> user page/location and do not know historical aspect. >>>> >>>> Thanks, >>>> Ilia >>>> >>>> --------------------------------------------- >>>> Orienteer(http://orienteer.org) - open source Business Application >>>> Platform >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org