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 > > -- Regards - Ernesto Reinaldo Barreiro
