[albatross-users] Back into albatross... again... :)
Cameron Blackwood
korg at darkqueen.org
Fri May 13 12:54:12 EST 2005
Hi,
I tend to drift into and out of albatross coding, and Im currently
on the way 'back in' :) and I have a few statements and some
questions... :)
Hate though I do to sound like Troy McClure, but you might remember me
from such classic albatros discussions such as 'needing expr="foo(x,y)"
in <al-input type="image">'. :) :)
After a big pause in alb development, Im back :) and Ive
forgotten everything that I previously learnt. :(
So, excuse the length and amount of rambling in this post... and feel
free to comment or ignore as you see fit...
'header' applications.
----------------------
I have this weird idea that I was thinking of, but Ive hit a problem.
Lets say Im dreaming of a number of 'game' applications with a single
user/login/tracking stage. So the flow of use would be:
1 login page
2 user's page
- choice to join or start a game from a list of different ones
(eg, tic tak toe, chess, go etc)
- list of currently 'running' games
(eg, turn 3 of chess game 'fred vrs jane',
ttt turn 2 of 'jane vrs -computer-',
turn 8 of chess 'jane vrs netfoo' )
3 user selects a game and goes and plays for a while
- input is passed to the correct 'game instance' and the
view pages marked up as need using the templates for that
specific game type.
4 user drops back to 2 and logs out or plays another
Assuming the game state is stored in some other server/db and albatross
is just a front end that requests data and marks up the 'view', then
I can see two ways to do this:
1) make an uber app with all the possible app pages loaded in with
a truck load of
s.register_page( 'GameN_pageM', 'GameN_pageM.html')
+ all inside albatross (all games are just albatross pages)
- all pages must be loaded at the start :-/ (hard to modify on
the fly)
- (Im assuming) performace would suck if it was an apache cgi
(given that it would have to create page instances for every
game for every request, which is wastefull if you have 20 games
with 10 pages each) Hmm. looks like I need to look at al-http
2) have some kind of 'farmer' which takes the request and delivers
it to the specific game on the fly.
- specific games wouldnt be albatross apps (atleast I cant think
of any easy way to do it?)
+ lean 'albatross' application on front
+ more 'dynamic' (in that a specific game can have trouble or be
added or removed without changing the pages that the albatross
application knows about)
I like the idea of having the flexability to add/remove new apps as I
go without needing to take the front end down (#2), but I cant see any
nice way to pass the user info on from the front end 'game header' to
an specific albatross 'game' sub-application.
(Except maybe to have the front end store the auth info in a cookie
and then url redirect the user to the game when they select it, which
seems kinda wrong to me for some reason.) (Although I guess if you
stored them in a cookie and then url-redirected to a specific game URL
then the game could unpack the cookie and store the values in its
session context, thus only needing to check it once.)
Having written this out, Im thinking that the #1 idea seems to be the
better way to go as it keeps it keeps all the 'games' as simple
collections of albatross pages (although I guess Id have to keep all
the templates in the same directory, as you have to pass a template
directory to the albatross application constructor (I havnt tried
setting the s.register_page('gameM.pageN','gameM/pageN.html')).
Hmmm. Opinions welcome.... as is mocking laughter. :)
(Ive mostly just hacked up smaller cgi-apps, never thought of
something this 'big'.)
Dynamic images for al-input?
----------------------------
The reason that I asked my (Feb last year) question about
<al-input type="image"> with variable image generation is that I
wanted to do something like this:
<al-input type="image" name="click" srcexpr="create_map_image(ox,oy)">
where create_map_image(ox,oy) talks to the game and generates the
image of the map at the offset ox,oy dynamically. You obviously have
scroll buttons to change ox and oy ;). Previously I used url hackery
to do this, ie, src="create_map_image/54/34" would draw the map at
ox=54 oy=53, but that just seems 'wrong'. :)
Any ideas how to do this? or should I look at hacking src/expr/srcexpr
on al-input for images? (Which I think is probably the Right Thing To
Do(tm) :)
I was thinking about using a:
http://www.object-craft.com.au/projects/albatross/wiki/Macro_20Expand
1 Expanding Albatross Macros in custom tags
and I think that page could do with an example of the _dtml_ that uses
the tags that it just defined. :)
Albatross learning curve.... & wrappers
---------------------------------------
Actually its not that bad, :) I picked it up again pretty quickly.
Ive ended up making a wrapper for albatross because there are some
things that I keep doing all the time and albatross doesnt help me
with (or maybe I dont know how to do them neatly).
Im wondering if anyone else has 'wrapped' the more unfriendly parts
of albatross or does everyone just use it raw? If anyone else has any
'wrapping' suggestions then please post 'em :).
Ive only just started back into albatross, so there is probably some
stuff that Im missing or that will need to be hacking in later, but number
one is that this hides 'context' from the user, so the user just ends
up with code like this:
class Login( Albatross_wrapper.base_Page ):
def work_on_enter(s):
s.create_global('username')
s.create_local('password')
def work_process(s):
login,username,passwd=s['login','username','password']
s.DEBUG('login [%s][%s]',username,passwd)
if login and username=='admin' and passwd=='foo':
s.goto('Game')
elif s['quick:korg']: # quick loging for testing.. remove later
s.DEBUG('quick login')
s['username']='korg'
s['password']='a.secret'
s.goto('Game')
elif s['nuke']: # nuke button?
s.nuke() # remove session store
class GameApp( Albatross_wrapper.base_App ): pass
def main():
app=GameApp( 'toplevel.cgi',
(Login,Game,Map)
)
app.DEBUG('Logging locals %s',__name__)
app.run_cgi( )
create_local and create_global create variables (duh!). (Locals
are destroyed when you leave the page).
You can __setitem__ (will barf if the variable doesnt exist (not sure if
thats what I want just yet)).
You can __getitem__ a variable or a list of variables. Yay! Easy unpacking
without checking for ctx.local.myvariable then accessing it.
Will return 'None' if the variable doesnt exist (again, unsure if thats
what I want, but *shrugs*).
The base_App works out template directories (by looking for
Albatross_templates in your sys.path, which Im not happy with really
as Id rather just pass full path names to the register_page()
function, which I admit I havnt tried yet... and if that works, then I
wont need to pass a template directory as I can just search for each
page template as I register the page :).
It also names the pages from their class names (ie above, Login is
named as Login and uses a template that matches [Ll]ogin{.html|.dtml}.
Id like the wrapper to be able to run as a number of different
albatross servers types, but Im currently only using:
from albatross import SimpleSessionFileApp as Albatross_Application
from albatross import SessionFileAppContext as Albatross_Context
I also want to make it better at being switched between apache cgi and
al-httpd, but I havnt played with al-httpd so Ill do that when I come
to it. (Eg, if you call it it runs al-http, if its called, it works as
an apache cgi.)
I also want to code up an ImagePage that generates page images (with
the dynamic generation above) but I havnt got _that_ far back into it
yet. ;)
Oh and I just like to end by repeating what everyone already knows...
that albatross rocks. :)
cheers,
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 ----------
True happiness will be found only in true love.
More information about the Albatross-users
mailing list