[albatross-users] Levelling the "random vs non-random" field

[Dave Cole]

>>>>> "Matt" == Matt Goodall <matt at pollenation.net> writes:

Matt> The other day I was thinking about what _I_ think could make
Matt> Albatross better still. At some point (i.e. if I ever have the
Matt> time) there are a few things I might experiment with in
Matt> Albatross:

Matt>     * Provide random apps with the page lifecycle (specifically
Matt> page_enter and page_leave) that non-random apps benefit from -
Matt> it's a wonderful way to manage session data. This is probably
Matt> more difficult but I suspect it's not impossible. The session
Matt> already has __page__ so I think Albatross has enough to work out
Matt> what's going on, it's just putting the hooks in the right place?

I am not sure that this would be general enough to rely upon in your
application - users would be jumping all over the place.  Does that
matter though?

Matt> * Make ctx.set_page() and ctx.redirect() work for both types of
Matt> apps. I think this is one of the few cases where Albatross
Matt> forces you to decide on an application type right at the start
Matt> and I think that's a shame. Perhaps it's even unnecessary? I
Matt> don't know yet.

That seems like a really good idea.  So good it makes me wonder why it
does not already do that.  Maybe I have forgotten why I thought the
two were sufficiently different enough to warrant different names.

Matt> * Make a RandomPageObject mixin. Or better still, separate the
Matt> random vs non-random and page object vs page module behaviours
Matt> to allow whatever combination makes sense. I don't think this
Matt> would be too difficult and it may be quite useful.

If we required Python 2.2 and changed RandomPageModuleMixin so that it
did not inherit from any other class, then I think we could change the
code to use the super() builtin function where it is currently calling
PageModuleMixin.page_enter() and other methods.  We would still need
to do something about the call to self.load_page_module() though.
Maybe just implement a stubbed method in the PageObjectMixin.

Matt> * More request adapters. The one I'm probably most interested in
Matt> is Twisted. Twisted is a lot of fun and has some some really
Matt> nice features but woven (the web part of the framework) is more
Matt> complex than something like Albatross.

That would be cool to have.  I spent a little time looking at Twisted
when I had to build a forking server.  I could not get Twisted to do
what I wanted and did not have the time to figure it out.

Matt> What are your thoughts on the above? Have you explored any of
Matt> these already and decided its too difficult? Dave/Andrew, is
Matt> there anything that you simply don't want to see happening in
Matt> Albatross?

My immediate response to that is no.  Each time the classes are pushed
in a new direction we are closer to my original goal with Albatross.
I wanted to build a collection of classes that could be used to
construct many different types of web applications.

In my day dreams I imagined different layers on top of Albatross being
used to narrow the focus and raise the functionality for different and
smaller problem domains.  It is still a day dream though.

Matt> Of course, I may never actually find any time to look into any
Matt> of these ;-)

If only people would pay us money to play with this stuff all day :-)

- Dave

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