[albatross-users] Re: Albatross-users digest, Vol 1 #177 - 13 msgs

Tue Jul 1 21:23:02 EST 2003

From: "Eric S. Johansson" <esj at harvee.org>:
  | 
  | Cameron Blackwood wrote:
  | > 
  | > Im with you there, man. :) 
  | > 
  | > Long descriptive names and '_'s up the whazoo for me :)
  | > 
  | > I want going to comment because I didnt write albatross, so I didnt
  | > feel that I could comment on coding style, but now you mention it...
  | > 
  | > Now, if we cant use generic classes with initiators like:
  | >    Context(storage=Albatross.file)

This would be my preferred solution actually :) 

or even Application(contest=Albatross.store_on_client) 
:)

  | >  2| SimpleAppContext                Context_stored_client
  | >  2| SessionAppContext               Context_stored_server_process
  | >  2| SessionFileAppContext           Context_stored_server_file
  | 
  | I like this series of proposed names because it's something that makes sens
  | e.

*nod* instantly readable! Thats gotta be a Good Thing(tm)

  | 
  | > And the same but longer for the Apps (although again, Id prefer
  | > the app not to need to know how the context was stored, but maybe
  | > thats just me).
  | 
  | there is a couple things about albatross that has plagued me and excessive 
  | visibility of what should be internals is one of them.

*nod* Im agree 100%. Trying to nut out the difference between all the
Application types etc is something I hit again and again.

  | trying to understand the gestalt without much success.  Goodness knows I've
  |  
  | written my fair share of train-by-telepathy documentation so there is no bl

*haha*

  | 
  | one of the gestalt points is communicating information from the python side
  |  to 
  | the HTML side and back.  I've been mucking with it for about a week and I a
  | m no 
  | closer to having a useful knowledge of information transfer issues than I w
  | as 
  | before I started.  The black magic surrounding context.local really isn't c
  | lear 
  | nor is the usage of attributes.  I've been using Python for the better part

I just tend to put everyting in context.local.variable_name
and then  ctx.add_session_vars('variable_name')  and magically it's
useable from my template. Maybe its just laziness on my part, but it
just kinda works.

Yeah, I agree. Albatross is so tauntingly almost perfect ;).
(Im not saying I could do better, but there just seem to be a couple
of things that poke me in the eye everytime I think I fully understand
it :)

Actually, one thing that I think Albatross __REALLY__ __REALLY__ needs
are some simple example/skeleton code fragments. Maybe this should be
a list effort, not something we all wait for object-craft.com.au to
do.

What kind of demo would help you get your stuff done? I was thinking
along the lines of...

1) An demo page that takes input and dumps it to some python code and 
   displays the results in various ways. (Kind of already there, but one
   that tests the various template tags.)

2) An example app that lets you:
     Login,
        user,
          edit user.details
          change user.picture
          edit user.story

3) A more complex example with a custom al-session-daemon that holds a
   number of 'users' and 'chess games' and (using the newly 
   renamed Context_stored_server_process  :) lets you:
     Login,
        user,
          list/create game
          join game
          play game
            make move
            send message
   (this one is more complex because you have the whole state saving and 
   parallel input problem)

This is top of my head stuff, but if we as a list could come up with a
set of 'these examples would be great', then Id sure be up for trying
to code some of them. (I mean, it'd be a good learning exercise ;)

  | 
  | If you can accept a suggestion, I would suggest creating an very simple 
  | user-friendly layer.  It would reflect the simple nature of CGI environment
  | .  It 
  | would consist of a couple of functions/methods.  The first would be used fo
  | r 
  | generating output.  It would associate a dictionary with an albatross HTML 
  | template.  The keys of the dictionary would map to variable names in the 
  | template.  The matching value to a given key would be substituted into the 
  | variables.  Obviously, nested lists, dictionaries etc. would be permitted s
  | o 
  | that for loops etc. in the templates could be used.
  | 
  | the second function would extract information back from CGI forms.  I haven
  | 't 
  | thought long on the form it would take but I suspect it would also be some 
  | form 
  | of dictionary based structure based on an albatross HTML template.
  | 

Ive been abusing cgi forms for ages :) Im sure we could would work out
a few good examples here. :)

Ive been avoiding templates :) so Im not sure I could do it alone. :-/

  | obviously these ideas aren't fully formed but they are a reflection of my 
  | confidence that that the whole process can be simplified even further than 
  | it 

*nod* I have a hope that it could be simplified, but the objectcraft
people are smart, so maybe it cant.

  | has been to date.  I also believe it should be possible to create a layer o
  | ver 
  | the current albatross API to generate this kind of simple interface.

*nod* although a set of good useable examples would take away the
need, maybe?

cam

--
 / `Rev Dr'   cam  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 ----------
$100 invested at 7% interest for 100 years will become $100,000, at
which time it will be worth absolutely nothing.
		-- Lazarus Long, "Time Enough for Love"