Stuart Hungerford wrote:
> Hi all,
>
> I have a question about the most Quixotic use of the
> quixote.util.StaticFile class.
>
> I've setup a series of classes to handle each part of
> the URL path http://example.org/foo/bar/filename
>
> In the class that handles the trailing "filename" part
> of the URL path I have a _q_index() method that needs
> to perform a test and based on the result either
> return the contents of the file or a descriptive
> error message.
>
> Something like:
>
>    class filenameUI:
>
>        def __init__(self, filename):
>         self._filename = filename
>
>        def _q_index [html] (self, request):
>            if sometest(self_.filename):
>                # need to invoke StaticFile contents here
>            else:
>                '''HTML formatted strings'''
>
>
> The question is: am I going about this in the most
> Quixotic way or am I using the whole framework in the
> wrong way?

It looks fine to me. There are a lot of cases where an HTML function or
method has if/else logic, and can return very different responses.

Depending on what your "else" clause represents, you might consider
returning a status code other than 200 OK. That might help clients to
determine whether they've got the file content, or something else,
without having to inspect the content itself. This can be especially
helpful when your client is not a browser, but a library (like httplib
or urllib).

> E.g. Should all the testing logic be instead
> in the class that handles the "bar" part of the URL path?

Is the testing logic common to all members of the "bar" collection? Or
is it specific to the file element?

> Or maybe I need another class that is returned by the
> _q_lookup() function of filenameUI ?

If anything, I think you would just need some extra methods on your
filenameUI class.

Note that if "filename" in the URL

     http://example.org/foo/bar/filename

is being handled by an instance of your filenameUI class, then the class
should have a __call__ method. Whether it needs a _q_index is debatable.

If you need support for URLs like

     http://example.org/foo/bar/filename/         # trailing slash!
     http://example.org/foo/bar/filename/md5sig
     http://example.org/foo/bar/filename/metadata

then filenameUI should have _q_index, and must have a _q_exports list.

If you're just using the "/filename" style, then no _q_* methods or
attributes are required. Without a trailing slash, your object is
expected to be a callable object, e.g. a method, function or an object
with a __call__ method.

If the trailing slash is present (".../filename/"), then the _q_*
mechanisms come into play, and you must have a _q_exports attribute. You
will probably want a _q_index method, and will likely want a bunch of
other methods, one each to handle "md5sig", "metadata" or whatever URLs
you want to support.

Don't know if I explained that well, it's the pre-caffeination phase of
my morning. ;-) Hope it helps.

-- Graham