[mod_python] how to define publisher when page not found

Maksim Kasimov wrote ..
> Hi Graham, i'm very pleased to get your answer, thank you!
> 
> >I also question why you would want to do that anyway, ie., have a separate
> >not found page for every file resource. Care to explain what you thing
> you
> >get from it?
> 
> take it as "default attribute", not as "not found page", but defining
> default attribute is a native thing (at least for pythonic applications).
> And having ability to define or not define default attribute, in case of
> mod_python.publisher, is also not a bad thing, just make it more flexible.
> Isn't it?
> But any way, i do not  insist.
> 
> As we all know, there not only web related projects that uses Apache
> web-server and can use mod_python.publisher - there are a lot of things
> based on http-protocol.
> For example i'm planning to port my Wireles Village project based on
> pythonic web-server to Apache, and there many of such things that exists
> at
> the moment and can appears in future.
> 
> For web case: all users of my site are mobile operators subscribers, they
> download various content from my site (melodies, pictures and so on). For
> a
> different mobile operators, there are different requirements: page design,
> error messages format, error message text and many other parameters, it
> can
> be wml, xhtml or html format ... and some times some operator can change
> its
> own requirements (as i can see it happens many times) and so on.
> in my turn, i can have a lot of related projects, they must have different
> logic, or just a design or use different technology to download (such as
> drm-technology)
> 
> For various project it is convinient to have different directories, and
> i
> can make some modules with names related to some operator.
> 
> One project can have different parts: web/wap-based part, and some
> http-based part (Wireless Village + gate to another messengers, SyncML
> or
> smth else)
> 
> My case is not unique.
> 
> 
> >Maybe you shouldn't be using mod_python.publisher but should
> >be writing a custom dispatcher of your own.
> 
> it is looks like a discovering a bicycle again and again. But exactly that
> change i've suggest before, do not make some unexpected things for those
> developers that uses mod_python.publisher but did not define _default
> function.

Your change does have the potential to break existing code as publisher at the
moment would ignore anything called _default. With this change publisher would
then treat it as special in some way. If existing code had used this name for
an internal function, data or class name, then that code would then start
failing.

Overall I would suggest that using mod_python.publisher would be a poor choice
for what you are wanting. I sort of get the impression that you chose it
because it was the only option you could find which provided a means of
dispatching different URLs to different functions within different code files.

The problem you are going to have with using mod_python.publisher is that
although it does provide an ability to map URLs to arbitrary functions and
data, the functions aren't normal mod_python handlers and are instead
restricted as to what they can do.

For example, you can only use GET/POST requests against them. Thus, if you want
to use other request methods to implement a more REST like interface it will
not work. Next is that when you do use POST, it will only accept certain types
of content type which correspond to what is used in HTML forms. Thus, you
wouldn't be able to implement using publisher endpoints for JSON-RPC, XML-RPC
servers, REST handlers which want to accept other content types etc etc.

Other problems are that publisher as written expects the full URL to be able to
be mapped, meaning in effect you have a static URL system. There are ways to
overcome this without hacking the publisher internals as you want to do, but
since you didn't precisely explain why you wanted the _default fallback I can't
say that it is because of this issue that you want it.

Thus, although you think you are getting a lot of flexibility, you aren't
really and your users would be quite restricted in what they can do. There
are thus perhaps better ways of doing what you want, but at the moment your
description of what you want to do is very broad and isn't specific about
the desirable features you want.

To give you a better idea of what you could do, you might perhaps indicate
what of the following basic features you are after, plus add any others you
think you want.

1. Have URLs be able to map to handlers in different code files corresponding
to different resources.

2. For a code file for a specific resource, map to different handlers within that
code file based on what format the user wants to view that resource. Ie.,
different handlers based on whether they want to view that resource as HTML,
TXT, CSV, etc.

3. Automatic decoding and mapping to handler parameters of any fields in
a HTML form POST.

4. Ability for a handler to accept other POST content types besides HTML form
POST.

5. Within a code file for a resource, the ability to have the additional path
information be mapped onto handlers contained within instances of classes
contained in that code file.

6. The ability that not all the additional path information be mapped and that
instead any extra path information beyond what was mapped to still be available
to a handler to process.

7. The ability to have parts of the additional path information be passed to
a handler as parameters, overriding what may have been provided in a HTML
form post.

8. The ability to have instances of classes created on the fly specific to each
request rather than all requests being handled by a single instance of a class.

I will have missed some, but to me these are basic desirable features that
one might want. It would actually be interesting if as a group we can come
up with a more complete list of such basic features one might want and that
may even be used as a checklist against available dispatchers/frameworks
to see if it meets ones requirements or at least how they achieve them.

As is, publisher can't do all these. Some it can do but it isn't going to be
obvious to the average user how to achieve it using publisher.

Anyway, try to be more specific of the features you want instead of talking
about the problem domains you users might want to work in and we can
probably give better feedback.

Graham