[albatross-users] pagination with al-for

[Matt Goodall]

Andrew McNamara wrote:

>>Adding this is next on my list, just awaiting a response on the last
>>patch I sent in (I don't want to get into a version nightmare of pending
>>patches, lol).
>>    
>>
>
>Sigh - remind me what that patch was for? Sorry - been preoccupied with
>other work. If we're talking about the page module loading stuff, I'm
>still concerned that none of the proposed solutions are entirely "clean"
>(backward compatible and tasteful).
>
>I seem to remember that the thread started because someone discovered
>that page modules didn't honour the usual python module heirarchy stuff
>(so a page module couldn't be called "foo.bah"). The path of least
>resistance might be to simply fix this?
>
That was me. Sorry I've been so quiet recently but I have also been 
really busy.

To recap, the issue is that the current page module loading mechanism is 
broken for anything non-trivial. When a page module is imported it is 
registered in sys.modules under its module name. The absence of packages 
means that the page module name can easily clash with other modules and 
packages, overwriting entries in sys.modules. That causes all sorts of 
fun and games ;-).

(Note that Albatross page modules are just Python modules in some 
directory on disk and that page modules in a directory structure are 
just Python modules scattered across are number of different directories 
on disk. There is no package structure.)

There have been a couple of suggestions for how to fix the problem:

   1. Hack the import machinery. Instead of importing page modules as
      is, concoct a package and module name to avoid clashes. I think I
      found a problem with this approach (something to do with importing
      builtin packages like os and os.path) but I can't remember the
      details now. I think I also found a way to avoid the problem.
   2. Force the use of a proper package structure for page modules.
      Albatross could then import modules in the normal way; developers
      would have to scatter a page module directory structure with
      __init__.py files. This all sounds fine but I think it changes the
      concept of page modules a little. It would also break my code but
      I don't think it would be too difficult to fix that.
   3. Use execfile() to "import" page modules. This avoids touching
      sys.modules at all which is great. However, there is a possible
      (i.e. no one has profiled it yet) performance hit for plain old
      CGI users because Albatross would no longer benefit from compiled
      page modules. There is also an issue with storing certain types of
      object is the session caused by the way the pickle machinery works.

Just a couple more comments on the above and then I'll disappear back 
into the hole I've been living in recently ...

On (1) ... personally, I don't like this approach. It's too hacky but it 
can probably be made to work. The benefit is that it has no effect on 
application code.

On (2) ... this is probably the ideal solution, especially as it's 
probably only me it will affect. Hmm, in fact, it would allow be to 
clean up something that's been a slight irritation for me. However, it 
then seems wrong/silly to differentiate page modules from normal 
application modules. It might be best for Albatross to import modules 
using one of the application's packages as the "root", i.e. /one loads 
myapp.pages.one, /one/two load myapp.pages.one.two etc.

On (3) ... I'm skeptical that the performance hit is at all significant. 
If you're using CGI then you've already got the overhead of loading the 
Python binary, loading Albatross packages and loading any additional 
packages your application uses. I can't imagine compiling a (hopefully) 
small page module is going to add much to all that.

Cheers, Matt

-- 
Matt Goodall, Pollenation Internet Ltd
w: http://www.pollenation.net
e: matt at pollenation.net
t: +44 (0)113 2252500