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

[Matt Goodall]

Dave Cole wrote:

>>>>>>"Matt" == Matt Goodall <matt at pollenation.net> writes:
>>>>>>            
>>>>>>
>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?
>
In my eyes, I see the real benefit of page_enter and page_leave as 
somewhere to set up and tear down any session data for the page. This 
need is equally true for random apps as non-random apps. Are there any 
other uses of page_enter/leave that you have come across? Obviously, 
there's no way of knowing to clear up session data if someone closes 
their browser but at least you get the chance during normal application 
flow.

Hmm, just a random thought, but would it be useful/possible to take the 
page_enter/leave concept and make pages with persistent state? I'm 
thinking along the lines of pickling the non-transient properties of a 
page instance to the session rather than mucking about with 
add_session_vars. Woah, best stop this train of thought now or I'll want 
to play even more ;-).

>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.
>
Please don't get rid of one, both are required: set_page() essentially 
just changes which page actually gets displayed, redirect() allows you 
to change the URL or jump away from a form post.

IIRC, Sheila mentioned that she didn't like _having_ to redirect in 
random apps, set_page() would help here but redirect() definitely has 
its uses as described above.

>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.
>
Ah, super() ... so nice. I've lost count of the number of times I've 
tried to use it with Albatross before remembering that it's only 
available for new style classes ;-).

>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.
>
Twisted doesn't fork, could that be why you had trouble? ;-). At least, 
I don't think it forks?!

Seriously though, once Twisted is documented and there are more, well 
written example apps it could be a very nice application platform. The 
thought of integrating smtp, nntp, http etc into one application is just 
so lovely. But right now, I'm in the same boat as you - looking 
longingly in with not enough time to play and learn. By the way, have 
you looked at Twisted's LivePage stuff? All I can say is wow!

I think scgi forks. I was wondering about that as yet another request 
adapter but its lacking that "itch to scratch" quality for me now that 
there is fastcgi support.

Perhaps a FeatureRequest page to go alongside the ProposedChanges page 
on the wiki would be a good way of gathering ideas for future versions? 
That might also help keep track of things as people wander in and out of 
the project, as invariably happens with open source.

>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 :-)
>
Yeah, well that's why I've gone a bit quiter on the list this last week 
- I did too much "playing" last week. Python is often like playing 
anyway though :).

Cheers, Matt

-- 
Matt Goodall, Pollenation Internet Ltd
w: http://www.pollenationinternet.com
e: matt at pollenation.net