[albatross-users] Re: Albatross-users digest, Vol 1 #176 - 14 msgs

[Eric S. Johansson]

Cameron Blackwood wrote:

> Now I feel silly for commenting on the docs. :-/

shouldn't.  (Too much)
> 
> 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)
> then Id vote for
> 
>  2| SimpleContext                   Context_stored_nowhere(?)
>                                     Context_no_store(?)
>  2| AppContext
>  2|
>  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 sense.

> 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.

The documentation looks like it is very good if you have already absorbed the 
gestalt of albatross.  Unfortunately, I've been reading the documentation and 
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 blame 
by me on that point, just observation.

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 am no 
closer to having a useful knowledge of information transfer issues than I was 
before I started.  The black magic surrounding context.local really isn't clear 
nor is the usage of attributes.  I've been using Python for the better part of 
the year and a half now and I've never used attributes (knowingly).  Maybe it's 
some sort of watershed one must cross in order to become an anointed 
pythoninista, I don't know.

In any case, this gestalt has driven me to the point of admitting failure.  I've 
surveyed a fair number of template/CGI tools and I think albatross is one of the 
better overall and has the best potential for being small and really effective. 
  However, I have been unable to learn enough to do I need to do and I cannot 
ask any more from the community.  You have been more than generous with your 
time  already and for that I am grateful.

on the documentation front, take a look at CherryPY and pso.  while I'm not 
happy with either of them for different reasons, they both have good 
documentation teaching people how to use their system.

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 for 
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 so 
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.

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 
has been to date.  I also believe it should be possible to create a layer over 
the current albatross API to generate this kind of simple interface.

Again, I want to thank everyone who has been so very helpful and I appreciate 
the effort you have expended in helping me.

---eric