[Seaside] [ANN]: WADynamicVariablesErrorHandler (let me know if I
should integrate this)
Mariano Martinez Peck
marianopeck at gmail.com
Mon Dec 7 18:36:41 UTC 2015
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
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
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