[albatross-users] page module import magic

[Matt Goodall]

Andrew McNamara wrote:

>>Yes, it's getting a bit ugly. It's certainly not particularly 
>>straightforward.
>>
>>When you say, "maybe we should only support a flat page module 
>>namspace", what do you mean? Do you mean that Albatross should not 
>>support URLs like /login/help , requiring something like /login_help 
>>instead, or something else?
>>    
>>
>
>I'm referring to the page names - with this scheme, you can do things like
>ctx.set_page('preferences.simple') and ctx.set_page('preferences.advanced')
>
>The separator is the normal python namespace separate (dot) - previously,
>the filesystem separator was used, although I'm not convinced hierarchies
>of pages would have worked correctly.
>  
>
Hierarchies of pages do work but not quite correctly in the released 
code base, hence my original bug report. The only problem with them is 
the corruption of sys.modules. Perhaps Albatross was never really meant 
to be used like this?

>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?

Albatross already has a simple mechanism for dynamic URL mapping. 
There's an example in the Wiki, 
http://www.object-craft.com.au/projects/albatross/wiki/get_5fpage_5ffrom_5furi_28_29_20example. 


>  
>
>>Also, I'm not sure what you mean by "dummy parent modules have to be 
>>created". Is this referring to the create_module_holder() magic or 
>>modules that an Albatross user would need to create?
>>    
>>
>
>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?

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". 

>In decode_session(), I've replaced a sys.path fiddle with an import hook.
>On import, if the name starts with __alpage__, the load_page_module()
>method is called instead of the system import code.
>
>That pretty much describes the changes - does it make more sense now?
>
Yes, that's great. Thanks.

>I'm reasonably happy with the result - certainly no less happy that I was
>with the original implementation.
>  
>
I would be grateful if you could keep me updated on the solution you 
choose. I would need to change my code in a number of places to use a 
'.' in the URL but it's probably not too big a problem and I would 
rather use an official Albatross release than my patched version. 
However, nice URLs will be important to me for some future projects.

Thanks for the detailed explanation. If I get time I will try your patch 
to see what happens here. Sadly, I'm not finding much time for anything 
but payed coding at the moment :(.

Cheers, Matt

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