[mod_python] An odd use of the publisher

Colin Fox cfox at cfconsulting.ca
Sun Mar 14 13:57:18 EST 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Erik Stephens wrote:
|
|>Raising an exception gives me the control I want, it's just that it
|>feels wierd to be doing that as a normal exit, rather than a problem exit.
|
|
| Yeah, it is very weird.  I'm surprised it's working for you.  Maybe
| I'm missing something about your requirements or architecture.

Well, what I'm looking for is actually quite simple. If you write your
own handler instead of using the mod_python.publisher, you get handed an
unprocessed req object, and you respond by returning an apache return
code. This is great. The problem is, your single handler gets executed
regardless of where in the tree you are. So, if in your .htaccess file
you say:
PythonHandler myhandler .py

and if you try to execute:

http://localhost/test1.py

and

http://localhost/folder/test2.py

then your 'myhandler.py' module gets executed for both test1.py and
test2.py. I want to be able to have .py files all over my hierarchy that
get executed, rather than a single handler.

To do that, I have to use mod_python.publisher. However, if I use
mod_python.publisher, then I no longer return an apache code, I return a
string that is to be printed. I don't want to do that - I'll handle that
myself.

So I want some features of both techniques, and to do that I end up
having to end my publisher based calls by raising exceptions.

The system is working perfectly now as far as I can tell, I'm just
concerned that there may be a performance penalty with raising
exceptions like this, or that the system may at  some point be changed
so that any raised exception will be considered an error, which will
cause my stuff to break.

|
|>I'd just like to be sure that nothing odd is going to happen if I raise
|>an exception. Or alternatively, how I could get processing similar to
|>what I get if I write my own handler (where you create a handler()
|>function and return a success code).
|
|
| Can't you just assume that if no exceptions have been raised, then
| everything was successful?  Exception handling seems to me to be more
| powerful and flexible than return codes.

As I said - *I'M* the one raising the exception, to get the behaviour I
need. It has nothing to do with me assuming what an exception means if
someone else raises it.

| I think you may be over-complicating things a bit.  I'd recommend that
| you continue using publisher and factor out how you want each request
| to get handled into a method or class.  Here's just one way:
|
|
| class Page:
|
|     def __call__(self, req):
|         try:
|             return self.get_contents(req)
|         except:
|             pass # your exception handling code here
|
|
| class IndexPage:
|
|     def get_contents(self, req):
|         # This would be where you could put
|         # your current handler stuff
|
|
| index = IndexPage
| about_us = AboutPage
| ...
|

I'm not quite sure what you're illustrating here - the Page class isn't
used or referenced - is Page supposed to be derived from IndexPage? Or
vice versa? And I'm not concerned with HANDLING exceptions, I'm
concerned with what happens to the rest of the mod_python system state
if I THROW exceptions under normal circumstances. Zope, for example,
will execute a database rollback if you raise an exception. I don't want
that kind of thing being added on behind the scenes.

|
| Hope it helps and that I didn't misunderstand you completely :)
|
|
| Best regards,
| Erik

It's funny, but what I need is pretty simple, but the more I explain it
the more it seems to get complicated.

I think the best thing is for me to simply publish what I'm doing, and
point to it so everyone can see in context what I'm doing. I'll put
proper copyright attributions on my files and do just that.

cf

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAVNU9oaQ1/feGlJoRAjRZAJwLjeEmoxFC5+f1CSa4OCZx1f7rKQCeNVyK
w7RwcMbPAqjErlpOF85992M=
=xi9V
-----END PGP SIGNATURE-----


More information about the Mod_python mailing list