On Thu, Dec 11, 2003 at 04:03:28PM +1100, Stuart Hungerford wrote:
> Then the _q_exports instance for "example.web" could contain
> simple callables (functions or templates) to implement the
> first and second URL's
>     _q_exports = ["_q_index", "foo"]

Correct.  It's not necessary to include _q_index in the _q_exports list, but
having it in there is harmless.

> For the third and fourth URL's however I could add a submodule
> "example.web.bar" with callables "baz" and "fiz", OR I could
> create a class with "baz", "fiz" member functions
> (or _q_lookup())?

Correct.  Quixote will check if example.web has a 'bar' attribute; if it
does,  the attribute's value will continue to be traversed.  If there's no
such attribute, Quixote will then try to import example/web/bar.{py,ptl}.
If that module can't be imported, Quixote will call
example.web._q_lookup(request, 'bar').

> I *think* going the class route means you must use a _q_lookup()
> function within "example.web" module to catch the "bar" component
> of the URL and return a class instance that can then be traversed?

Not necessarily.  You could write something like this:

class BarUI: ...
bar = BarUI()

'bar' would then be a module-level variable that's initialized at import
time.  However, it's not very useful to do this, because you could just
make the methods of BarUI module-level functions instead.

> Which of these approaches (or other approaches) are more quixotic?
> Do Quixote developers end up in practice relying on _q_lookup()
> heavily for traversing deep URLs, or do they favour a more 1-1
> mapping to callables?

Usually _q_lookup is used to look up one of many possible objects from a
database.  A less common use case would be if you need a URL that isn't a
legal Python identifier, such as 'index.rss'.  You can't write
'def index.rss (...)', so instead you'd have to do:

def _q_lookup (request, component):
    if component == 'index.rss': return generate_rss()
    ...

--amk