Hi folks,

Since my last post regarding this, I've had further opportunity to examine
the code and my patch, and have modified things a bit further.  As detailed
below, the reason for this patch is to allow an object (that was
_q_lookup-ed) or other namespace to handle exceptions raised by themselves,
or by objects/namespaces further down the URL, that happen during the call
to _traverse_url (from try_publish).  Without this patch, those exceptions
can only be handled by the root level _q_exception_handler.

Also, I should point out, if you're going to re/read my original post that
this actually affects ALL namespaces, not just those that are inserted via
_q_lookup...  I just hadn't thought about that when I wrote the first
message.

That said, I have to put things in perspective:

Regardless of the publish.py used, you can handle anything that might come
up, it's just a question of how.

The Pros:
 + I think this approach more intuitive: The same _q_exception_handler stack
get's used regardless of the occasion.
 + I think it's cleaner:  You don't have to embed contextual information
into your exceptions in order to handle them cleanly at the top level.
 + I think it's easier to use:  See above.

The Cons:
 - It's very likely this change will break existing code.  I can't speculate
how much, but any apps which are handling traversal-time exceptions (in the
root _q_exception_handler) that also have _q_exception_handlers in other
areas further down URLs will find that the deeper handlers are catching some
exceptions they didn't used to see.  Surely this will occasionally cause a
problem.  So sayeth Murphy.
 - Ummm...  That's the only con I can think of, but it's a big one.
 - The big unknown...  I don't know that there isn't a good reason that this
hasn't already been tried, because it seems fairly obvious to me (as I'm
sure it would to anyone who dealt with as many traversal-time exceptions as
I did while learning how to use _q_lookup effectively)

The Workaround:
 - I haven't done this, but it would be trivial to enable the 'new-style'
namespace_stack construction only via a constructor param, and thereby give
existing applications the legacy behavior, while new apps can opt for
either.  Of course, this ultimately just postpones the problem...  If
there's interest in this idea, let me know, and I'll do it.

So, if anyone has any feedback about this, I'd like to hear it.  Maybe this
isn't worth the risk to existing code, and if you think so, let me know.

Jason Sibre



-----Original Message-----
From: quixote-users-bounces@mems-exchange.org
[mailto:quixote-users-bounces@mems-exchange.org]On Behalf Of Jason Sibre
Sent: Tuesday, May 27, 2003 2:01 AM
To: quixote-users@mems-exchange.org
Subject: [Quixote-users] _q_exception_handler during _q_lookup


Hi folks,

This is primarily directed to the maintainers, but all insight is welcome.

I'm still new-ish with Quixote, having only tinkered with the demo, and
written one very simple web app using it.  I'm currently working on a more
ambitious application, which is ultimately still just a learning exercise.

Tonight, some time was spent threading my way through the calls in the
Publisher class (I'm actually using the SessionPublisher), and I finally
realized WHY my _q_lookup exceptions weren't being handled as I expected.
The scenario is that I have one object looked up in the root of the
url-space, (a WProject, which is a sub-class of WItem), which then in turn
uses _q_lookup to lookup further components within it (resolving to WTasks,
also sub-classes of WItem).  My problem was that when a task was missing
(TaskMissingError, one of my sub-classes of TraversalError), I couldn't
handle the exception that arose upon a _q_lookup failure in the object doing
the _q_lookup.  Instead, I had to handle it in the _q_exception_handler at
the web app's root level (the first object in the namespace stack).

Well, I poked around a while and finally figured out that the reason for the
behavior is that the namespace_stack that is being created in _traverse_url
doesn't get 'committed' to the Publisher, unless _traverse_url returns
cleanly.  Otherwise, the only item in the stack is the root_namespace...

So here's the reason for my e-mail to you:

Is there a good reason for NOT allowing _traverse_url to directly update the
namespace_stack, and hence allow objects traversed to have a chance to
handle TraversalError exceptions (or other exceptions that may occur during
_traverse_url) ?

It's a simple matter to modify _traverse_url and Publisher to allow them to
work directly on Publisher.namespace_stack, and in fact the patch to do so
is attached, but I'm not sure there isn't a good reason for it not being
done already, since it's so simple.

Please let me know what you think, and I'll test my patch further tomorrow.
After I get some rest...

By the way, guys, thanks for all your effort on Quixote, I'm really enjoying
working with it.

Thanks,

Jason Sibre