durusmail: quixote-users: Re: _q_lookup and namespaces
_q_lookup and namespaces
2003-06-10
2003-06-10
Re: _q_lookup and namespaces
2003-06-10
2003-06-11
2003-06-11
2003-06-11
2003-06-13
Re: _q_lookup and namespaces
Graham Fawcett
2003-06-11
VanL wrote:
> Titus Brown wrote:
>
>>
>> If you need to hang stuff off of binary/octal etc., e.g.
>>
>> /numbers/15/binary/not
>>
>> then I'm not sure ;).
>>
>
> This comment gets to my point exactly.  Are the only two ways to chain
> namespaces:
>
> 1. import a module or have an instantiated class hanging around
> 2. _q_lookup
>
> or is there a third way?
>
> VanL

The need to bring in classes and objects just to use _q_lookup seems a bit
heavyweight sometimes: it's not always for 'object publishing'.

You could always subclass Publisher to enhance Quixote and get the precise
namespace resolution that you want...

Here's a variant of your (2). You could use _q_lookup to refer to another
module, rather than an object, passing the "looked-up" value in the _request_
namespace:

in numbers.py:

        import number_representations
        ...
        def _q_lookup(req, name):
                req.number = int(name)
                return number_representations

and in number_representations.py:

        def octal(req):
                number = req.number
                ...
        def binary(req):
                number = req.number
                ...

Of course, number_representations must always be accessed as a successive
namespace to numbers, else the req.number attribute would not be set and an
error would occur.

You could, I suppose, use the same approach as a variant of your first idea:
define a Representations class within numbers. But you could use static methods
(Representations.octal, etc.), and avoid the (admittedly small) instantiation
overhead. That would simply save creating an extra module, at the cost of all
that extra syntax. Otherwise, it would be similar to the above example.

Another (untested) variation might be to define all of your representations
_within_ the numbers module. Then, you could have:

        # numbers.py

        _q_exports = ['octal', 'binary', ...]

        def _q_lookup(req, name):
                req.number = int(name)
                return self

'self' being the trick: the same namespace would be returned, and it contains
octal, binary, etc., so the behaviour succeeds. An anti-case would be that one
could call the URL '/numbers/octal', and this would be Quixotically valid, but
it would skip the _q_lookup and hence the setting of the number attribute (and
fail with an AttributeError). Another suspicious but valid URL would be
'/numbers/1/2/3/octal', in which case _q_lookup is called recursively and
req.number==3!! Then again, such URLs would misbehave no matter what scheme you
used to implement your example: it might be a small price to pay.

I'm not sure if any of these fit with your contrived example, but something
might fit in a real-world app. I think the not-quite-Quixotic approach of
adding data to the request object as it passes through the namespace chain
seems a reasonable alternative.

-- Graham



reply