[Seaside] [ANN] SeasideDynamicVariablesDebugger [WAS] Re: [ANN]:
WADynamicVariablesErrorHandler (let me know if I should integrate this)
Mariano Martinez Peck
marianopeck at gmail.com
Mon Feb 29 00:03:26 UTC 2016
This is a quick email to let you know that I pushed the code into it's ow
repository with all the needed documentation:
On Mon, Dec 7, 2015 at 3:36 PM, Mariano Martinez Peck <marianopeck at gmail.com
> 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
> 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
> 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:
> 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!!!).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the seaside