[albatross-users] Newbie albatross question :)

Dave Cole djc at object-craft.com.au
Sun Nov 10 12:01:41 EST 2002


>>>>> "Cameron" == Cameron Blackwood <korg at darkqueen.org> writes:

Cameron> Im liking what I see of albatross :). It's like microzope,
Cameron> with persistance and dtlm type pages and easy cgi's. :) Yum.

The "easy cgi's" is probably the most important thing about Albatross.
Building small to medium web applications which capture and process
complex user input is where Albatross is intended to shine.

Cameron> This was one of the things that moved me away from
Cameron> bobo/zpublisher. :-/ I think the form submission was lost
Cameron> when I redirected, so I had to write _bobo_traverse's which
Cameron> are less than exciting (and dont give you access to the
Cameron> Response, so you cant redirect anyway ;)

Cameron> Not that that would be a problem with albatross, Id just have
Cameron> to save the form into the stored state :) before I redirect.

Yes.  The Python pickling makes sessions very powerful once your data
becomes more complex.

Cameron> I tried Random*App too, but have gone back to the simple.  I
Cameron> considered the Page stuff, but *shrugs* Ill change it if it's
Cameron> a problem. :)

Once you use server-side sessions you are able to mostly avoid using
forms to propagate state.  This means that the redirect becomes
useable again.

Cameron> One annoyance I found in changing, is that the keywords used
Cameron> by the __init__ of the App classes wont accept keywords from
Cameron> other App classes.

Hmmm...  I am not sure that there is much we can do about that without
introducing very hard to find problems.

Cameron> Docs ====
Cameron> From reading the documentation, the difference between
Cameron> App, SessionApp, SessionFileApp and context and applications
Cameron> isnt all that clear. Add in Mixin's and other stuff and it's
Cameron> something that causes some confusion. (Atleast I found it to
Cameron> be so).

Choosing good names for these things is really difficult.  I agree
with you - our choice of names is not as good as it should be.

Cameron> Let me explain further on that. I know that App, SessionApp
Cameron> and SessionFileApp are just client, server daemon and server
Cameron> file storage classes. But the name App suggests _no_
Cameron> session. Wouldnt it be better to call them SessionClientApp,
Cameron> SessionDaemonApp and SessionFileApp? And why does the App
Cameron> care how the Session is stored? Isnt that a context thing?

An execution context is only intended to exist long enough to service
one browser request.  The application can live longer if you deploy in
a non-cgi environment.

When you use a session server it makes sense for the application to
manage the connection so that in a non-cgi environment you open the
connection once and service multiple browser requests with that
connection.

We plan to add a standalone server deployment option which would mean
that the application would simply maintain sessions in a dictionary.

Hopefully this explains why we chose to split the management of
sessions between the application and execution context.

Cameron> And then there are Random, Module, Simple, which are ByURL,
Cameron> ByPythonModule, ByPythonObject, yeah?

Much better naming!!!

We could try to come up with a better naming scheme and keep the old
confusing names as aliases for a couple of releases.

Cameron> I guess I start to get confused when I get to
Cameron> RandomModularSessionFileApp Class. It's a little unclear for
Cameron> newbies.

It is still confusing for me.  I find naming one of the most difficult
tasks in programming.

Cameron> I mean I know that I learn by looking at code, and some of
Cameron> the code examples are a little vague.

[snip discussion of headers]

This is one area where some reorganisation would probably be very
helpful.  At the moment you are expected to subclass the execution
context and override the write_headers() method.

Maybe the write_headers() method should write out a list/dictionary of
headers for which a default was established in the constructor.
During request processing all you would then need to do is alter the
headers.

Something like:

    ctx.set_header('Content-Type', 'image/png')

- Dave

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




More information about the Albatross-users mailing list