[albatross-users] Newbie albatross question :)

[Dave Cole]

> One thing that I did spend __AGES__ on was trying to track
> down :
> 
>   [Sun Nov 10 03:27:19 2002] [error] [client 10.0.0.1] Premature end of script headers: /home/httpd/cgi-bin/20c
> 
> It turns out that Id accidently deleted my:
> 
>   def page_display(s,ctx):
>     ctx.run_template('login.html')
> 
> So albatross was processing my object and then displaying nothing.
> Man, that sucked!! It took me about an hour to find. (I deleted it
> as I cut and pasted some of my methods into a parent class, so I
> thought it was that.)
> 
> Maybe albatross should return 'no output generated by object NAME'
> or something from the flush()?
> 
> I cant see any reason why you'd want to not return _anything_.
> Maybe an overwritable 'default/no output' return would be a good
> thing?

The is a bit of an oversight in Albatross.  It should be raising an
exception if you do not define page_display()

> step1
> =====
> Im using:
> 
> from albatross import SessionFileAppContext as Albatross_Context
> from albatross import SimpleSessionFileApp as Albatross_Application
> from albatross import SessionFileContextMixin   # <---to hack the content type
> from albatross.cgiapp import Request
> 
> and Im finding that if i have an error in my code that makes a
> traceback dump, then my state is lost. (IE, if i fix the code and
> then hit reload (which then gives the warning about 'post'ing the
> data again), I am back to my login screen (which is my startup
> page)).
> 
> Is this because my context is being saved as 'empty' because
>    * the context is created at the start of the request 
>    * my code is processed and bombs out
>    * the empty context is saved? 
> or something silly like that?

This is intentional.  If you look at the Application.run() method you
will see that it removes the session when it catches an exception.  It
is a minor annoyance when you are developing, but it prevents you
getting stuck in an exception dead end.  Consider the situation where
an exception is being raised due to some bad data in the session.
This could cause the application to raise an exception for every
browser request.  That would be bad.

> step2
> =====
> Ok, Im dumb. :) 
> 
> It turns out that it was caused by my not setting
> ctx.add_session_vars in each 'create_context'.

Easy enough mistake to make.

> step3
> =====
> Errr, ok maybe it wasnt that either.
> 
> Um. Ok. Confused now.
> 
> Somehow my context is being lost if I get a traceback (I put a
> button which causes a divide by zero error in my code. If I hit
> reload, then my login screen appears.

Yup.  See above.

> If I use SimpleAppContext rather than SessionFileAppContext then my
> problem goes away (becuase the state is stored in the form, so when
> I 'repost' it reloads the state, I guess)

Yes.  The application cannot remove the session currently held at the
browser.

> Questions
> =========
> So, I guess Im asking what happens in the SessionFileAppContext
> state then and how do I get around this?

At the moment the only way to get around it would be to replace the
run() Application method with your own which did not remove the
session when an exception is trapped.

> And just to check, but I dont need to add create_context() each
> create_context() do I? Once it's in the state it's there for good?

Not sure I follow you here.

> Well the documentation uses the form:
>  ModularSessionApp.__init__(self,
>                       base_url = 'popview.py',
>                       module_path = '.',
>                       template_path = '.',
>                       start_page = 'login',
>                       secret = '-=-secret-=-',
>                       session_appid = 'popview4')

[snip]

> _But_, if the same stuff is done to all the __init__ functions, then
> I could change the class from SimpleSessionFileApp to SimpleApp and
> the extra args would just be ignored (if i used the 2nd format!)
> 
> This would be a 'good thing' as it would mean you could change
> storage systems easily. It should be transparent, yeah?

I can see the merit in doing that.  The only downside is you lose the
ability to detect misspelling of keyword arguments for which there are
defaults.  Maybe this is a small price to pay.

- Dave

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