[albatross-users] Newbie albatross question :)

[Cameron Blackwood]

Andrew McNamara writes In message <20021108083406.781723C188 at coffee.object-craf
t.com.au>:
  | >I guess, given that the objects are selected from the url,
  | >
  | >    ctx.set_page('postlogin')
  | >
  | >shouldnt work from any of the Random*App classes.  Or is it
  | >just me? :)
  | 
  | I think it's done with redirects, but I can't see the logic for the
  | moment.  Dave should be able to answer this one when he gets a sec.
  | 
  | I was using the RandomPage mixin for an app, but I found that redirects
  | didn't sit well with modern security conscious browsers when they occurred
  | on form submission.


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



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

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

(zpublisher is only the object publishing bit of zope, not
the object database/persistance part).



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

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

Im using:

  from albatross import SimpleSessionFileApp as Albatross_Application

Then I can just use Albatross_Application. Great. 

But.... I cant just change that to SimpleApp, because then
the constructor complains about the args. Wouldnt it be nice
if it just ignored extra args? Still I guess Id have to
rewrite my code anyway, but still, it was a nice thought.

Ok, it's a dumb idea. :)

Actually, now is probably a good time for some feedback.


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

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

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

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

Maybe a few better examples, all the different ways of
making a 'login', 'user info', 'account info', 'transfer
duckets', 'logout' type application?

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


Content-type:
=============
I wanted to return images, so I did this:

class MyContext(Albatross_Context,My_Ablatross_Class):
   def __init__(s,app):
     Albatross_Context.__init__(s,app)
     s.content_type='text/html'
     s.DEBUG('init Content-Type:%s'%(s.content_type))

   def write_headers(s):
     SessionFileContextMixin.write_headers(s)
     s.request.write_header('Pragma', 'no-cache')
     s.DEBUG('write Content-Type:%s'%(s.content_type))
     s.request.write_header('Content-Type', s.content_type)

My reading of the code suggested that if I used 

   Request.write_header("Content-Type","blah/blah")

then it should have worked, but it didnt seem to reliably. I
guess it doesnt in cgiapp.py at all.

Given:

   self.request.write_header('Pragma', 'no-cache')
   self.request.write_header('Content-Type', 'text/html')

seems to occur so often through out the code. See:

   SimpleAppContext.write_header
   SessionAppContext.write_header
   SessionFileAppContext.write_header

Wouldnt it be better to make it a method of AppContext, so
that it could be easily overwritten?

I (from my 1 days looking) think that the context is rebuilt
for each request, so if I change my content-type I guess
it's a little counter intuitive that it changes back.

Maybe you could have a function (in AppContext):

  def     write_standard_headers(self):
    if self.nocache: 
      self.request.write_header('Pragma', 'no-cache')
    if self.overwrite_type: 
      self.request.write_header('Content-Type', self.overwrite_type)
      self.overwrite_type=None
    else:
      self.request.write_header('Content-Type', 'text/html')

  def     only_this_request_and_no_more_change_content_type(self,newtype):
    self.overwrite_type=newtype

:)  

and then just use self.write_standard_headers in
SimpleAppContext, SessionAppContext & SessionFileAppContext.



I should probably stop now.  :-/ Cause Im not sure this is
making sense :)


cheers,
cam

  | 
  | -- 
  | Andrew McNamara, Senior Developer, Object Craft
  | http://www.object-craft.com.au/
  | 

--
 / `Rev Dr' cameron.blackwood at darkqueen.org    Roleplaying, virtual goth \
<   http://darkqueen.org        Poly, *nix, Python, C/C++, genetics, ATM  >
 \  [+61 3] 9809 1523[h]         skeptic, Evil GM(tm). Sysadmin for hire /
                      ---------- Random Quote ----------
One expresses well the love he does not feel.
		-- J.A. Karr