[ANN] SeasideDynamicVariablesDebugger [WAS] Re: [ANN]: WADynamicVariablesErrorHandler (let me know if I should integrate this)
Mariano Martinez Peck <[email protected]>
| Newsgroups | gmane.comp.lang.smalltalk.squeak.seaside,gmane.comp.lang.smalltalk.squeak.seaside.devel |
|---|---|
| Message-ID | <CAA+-=mWWzGV-HVVXC_qzRrpOOLH_8PhTD6zD0zSkW8SRaujMiw@mail.gmail.com> |
Dear all, This is a quick email to let you know that I pushed the code into it's ow repository with all the needed documentation: https://github.com/marianopeck/SeasideDynamicVariablesDebugger Cheers, On Mon, Dec 7, 2015 at 3:36 PM, Mariano Martinez Peck <[email protected] > wrote: > Dear all, > > For those that have used Seaside, and you try to debug with the Debugger, > you know that upon request processing seaside uses Exceptions mechanism to > always have access to the current request, error handler, etc. The way that > this is done is via subclasses of WADynamicVariable: > > WACurrentRequestContext use: self during: aBlock > > In that case, "self" is the request instance and "aBlock" the closure that > takes care of the request processing. So, inside that closure, everywhere > you do "WACurrentRequestContext value" you get the correct request instance. > > Once inside the debugger, things get complicated. While you can restart, > proceed, etc (because the process you are debugging is inside the scope of > the dynamic variables), you cannot evaluate any piece of code that at the > end use the session or request because you get a WARequestContextNotFound > kind of error. The reason is obvious: The evaluation, do-it, print-it, etc > etc you on a piece of text or via the debugger inspector, creates another > closure/context which is not in the scope of the dynamic variables. > > For a client, we also have custom subclasses of WADynamicVariable, for > example UserContextInformation. And that means that almost every time in > the debugger I really need access to that object. > > To solve that issue, I create a project which is actually a proof of > concept: Check package SeasidePharoDebugging from > http://smalltalkhub.com/#!/~marianopeck/MarianoPublic > It does work for me, and if you think this could be useful for Seaside > itself, I can commit it there. > > The idea is very simple. I have a WADynamicVariablesErrorHandler subclass > of WADebugErrorHandler. We reimplements there #handleException: in order to > simply iterate all values of all dynamic variables (all WADynamicVaraible > subclasses) and store those into a dictionary in a class variable of > WADynamicVariablesErrorHandler. > > Then, I simply override (this is the part that must be cleared if we > integrate this in Seaside) WADynamicVarible >> #defaultAction to be > something like this: > > WADynamicVarible >> #defaultAction > ^ (WADynamicVariablesErrorHandler storedDynamicVariable: self class) > ifNil: [ self class defaultValue ] > > That way... when we handle an exception, we save out all values into a > class side. And then, in the debugger, whenever we evaluate, inspect, print > etc anything that would do a #value over a WADynamicVariable subclass, it > ends up calling #defaultAction (because there will be no handler in the > stack) and there, we first check if the have the value for that dynamic > variable. If we do, we answer that, if not, the defaultValue :) > > There are tests too. There is WACurrentRequestDebuggingTest which you can > try from /tests/seasidepharodebugging > > For the user, there is almost nothing to do. All WADynamicVariable > subclasses are managed automatically. All you need is to register the > exception handler: > > app filter configuration at: #exceptionHandler put: > WADynamicVariablesErrorHandler. > > The only drawback here is that this doesn't work with multiple debuggers > as the last debugger will override the class variable values and hence the > OLD already opened debuggers will be getting a wrong (the latest) value for > the dynamic variables. > > What do you think? I think that while it might not be the best solution > and it has limits, it is every is extremely simple and does the job. > Maybe you see problems I am not seeing? > > Let me know if do you want this integrated or not. In the meanwhile, I am > loading it from my repo for my apps and keeping the override (I would like > to get rid of it!!!). > > Best, > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com _______________________________________________ seaside mailing list [email protected] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside