[Glass] [ANN] SeasideDynamicVariablesDebugger [WAS] Re: [ANN]: WADynamicVariablesErrorHandler (let me know if I should integrate this)

Paul DeBruicker via Glass glass at lists.gemtalksystems.com
Thu Apr 7 11:13:23 PDT 2016


thanks Mariano for making and sharing this.  Have you tried it with GemStone? 
I'm getting an error in some of my callback processing code and It'd be nice
to be able to step through the execution on tODE.  


GLASS mailing list wrote
> 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 <

> marianopeck@

> > 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
> 
> _______________________________________________
> Glass mailing list

> Glass at .gemtalksystems

> http://lists.gemtalksystems.com/mailman/listinfo/glass





--
View this message in context: http://forum.world.st/ANN-SeasideDynamicVariablesDebugger-WAS-Re-ANN-WADynamicVariablesErrorHandler-let-me-know-if-I-shoul-tp4881484p4888902.html
Sent from the GLASS mailing list archive at Nabble.com.


More information about the Glass mailing list