[albatross-users] page module import magic

[Andrew McNamara]

>>I can imagine an app where you'd want to map the url to page name - maybe
>>it was a mistake to change it (I was assuming that the old code was broken,
>>and nobody would have been using hierarchies)? Dots seem more natural in
>>the context (and it means the import hook can call the function directly).
>
>For me, using a '.' for this purpose in a URL is odd. URLs are designed 
>to map to resources (real or virtual) so using a '.' is creating your 
>own URL scheme when a normal URL would have been good enough. Hmm ... is 
>there a problem with simply converting a URL of preferences/simple to a 
>module called preferences.simple?

My rational is that it's a module name, not a URL, so it should follow the
python module naming rules.

>>In the flat case, we create a dummy module at the root, called
>>'__alpage__', and we load the page modules into that.  If a hierarchy
>>of page modules is used, dummy modules have to be created to represent
>>the intervening directories. So... if you have the following:
>>
>>        login.py
>>        preferences/simple.py
>>        preferences/advanced.py
>>
>>they would be loaded as:
>>
>>        __alpage__ (dummy)
>>        __alpage__.login.py
>>        __alpage__.preferences (dummy)
>>        __alpage__.preferences.simple
>>        __alpage__.preferences.advanced
>>
>>get_module_holder() just makes sure the dummies are created (recursively)
>>and returns the parent of the module to be loaded.
>
>Ah, ok. I understand now. Would this work if I wanted the URL 
>"preferences" *and* "preferences/simple" to work correctly or would the 
>dummy __alpage__.preferences module get in the way?

No, the dummy will get in the way (and in some obscure ways). 

>I actually thought your preferred solution was to use *real* application 
>packages and modules (which I guess is why I was a little confused about 
>your "dummy parent modules" comment) but I've reread the thread and 
>found mention of a "synthetic namespace". 

The problem with this is backward compatibility.

I'm also not sure how to make the imp module work sensibly with
__init__.py - I'm reading the source now. We can't just use __import__
as that does a lot of stuff we don't want.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/