[albatross-users] Renaming application and execution context classes

[Dave Cole]

> Is it possible to combine the classes into one (from the user's
> point of view)?  In an ideal world
> 
> 	app = albatross.App(blah, blah, session_store=albatross.FILE)
> 
> it what I'd like best.
> 
> As for StudyCaps I personally find them much more readable for class
> names, and they point out "hey I'm a class not a function", and use
> lowercase/_'s for var/function names.  This also jives with (most)
> the standard library, and I think it's more important to go along
> with the norm than have your module be different.
> 
> I won't admit how long I used hungarian notation...

Andrew and I thought about something like the above but could not come
up with anything that was not extremely hacky and ugly.

I like the idea of being able to control individual feature sets like
that...

In a sense Albatross is already like that though.  If you look in at
the bottom of albatross/app.py you can hopefully see what I mean.
Take for instance the ModularSessionApp class:

class ModularSessionApp(PickleSignMixin,
                        Application,
                        CachingTemplateLoaderMixin,
                        PageModuleMixin,
                        SessionServerAppMixin):
    def __init__(self, base_url, module_path, template_path, start_page, secret,
                 session_appid, session_server = 'localhost', server_port = 34343, session_age = 1800):
        Application.__init__(self, base_url)
        PickleSignMixin.__init__(self, secret)
        CachingTemplateLoaderMixin.__init__(self, template_path)
        PageModuleMixin.__init__(self, module_path, start_page)
        SessionServerAppMixin.__init__(self, session_appid, session_server, server_port, session_age)

    def create_context(self):
        return SessionAppContext(self)

If we did away with all of the prepackaged classes and changed the
interface to all of the mixins to just accept **kw then the above
could look like this:

class ModularSessionApp(PickleSignMixin,
                        Application,
                        CachingTemplateLoaderMixin,
                        PageModuleMixin,
                        SessionServerAppMixin):
    def __init__(self, **kw):
        Application.__init__(self, **kw)
        PickleSignMixin.__init__(self, **kw)
        CachingTemplateLoaderMixin.__init__(self, **kw)
        PageModuleMixin.__init__(self, **kw)
        SessionServerAppMixin.__init__(self, **kw)

In theory the create_context() method could be removed from the
existing classes.

App Class                       Context Class
SimpleApp                       SimpleAppContext
ModularApp                      SimpleAppContext
RandomModularApp                SimpleAppContext
SimpleSessionApp                SessionAppContext
ModularSessionApp               SessionAppContext
RandomModularSessionApp         SessionAppContext
SimpleSessionFileApp            SessionFileAppContext
ModularSessionFileApp           SessionFileAppContext
RandomModularSessionFileApp     SessionFileAppContext

If we consider SimpleAppContext to be the default execution context
for an application, then all application classes that inherit from
SessionFileAppMixin create a SessionFileAppContext, while all that
inherit from SessionServerAppMixin create SessionAppContext.

Taking the above a little further we could probably allow you to do
something like this:

class MyApp(albatross.AppBase,
            albatross.PickleSignMixin,
            albatross.Application,
            albatross.CachingTemplateLoaderMixin,
            albatross.PageModuleMixin,
            albatross.SessionServerAppMixin):
    pass

Then in Albatross we would define the AppBase class to be something
like this:

class AppBase:
    def __init__(self, **kw):
        for klass in self.__class__.__bases__:
            if klass != AppBase:
                klass.__init__(self, **kw)

All of this is of course untested :-)

One big advantage to all of this is that it allows you to change
application classes very easily.

Going back to yet another suggestion by Cameron Blackwood:

  http://www.object-craft.com.au/pipermail/albatross-users/2002-November/000166.html

This would solve his problem in varying argument lists to application
class constructors.

- Dave

-- 
http://www.object-craft.com.au