[albatross-users] cognitive speed bumps

[Eric S. Johansson]

Since a few folks have urged me to try and document where I missed with 
albatross, I figured I would start with my mental model of this process and go 
from there.  Hopefully it will not be much of a mental goat trail.  I also 
apologize for any speech recognition airs I've missed.  It's sometimes quite 
difficult to catch what's wrong with something you've said by reading.

Internally, I've partitioned the problem of Web programming into a few events:

    * initial setup
    * page creation based on "current known values"
    * retrieval of form data and translation into a set of "current known values"

In the traditional CGI environment, the order seems to be retrieval of form 
data, detection of initial conditions leading to initial set up, then creation 
of "current known values" followed by page creation and display.  It's not very 
intuitive but it is logical once you understand the underlying mechanisms of the 
CGI environment.

However when you introduce a tool to separate presentation information from 
generation of data, that model changes.  My expectation has been somewhat to 
very different from what the various tools smiths have generated.  This is no 
surprise but merely reflects the wide range of mental models folks have for this 
process.

In my expectation, I was picturing templates as named entities which could be 
operated upon by some engine.  The engine would be supplied a template and a set 
of named data elements.  The engine would then apply the value for each named 
data element to each occurrence of the name within the template.  The end result 
of the engines work would be copied/transferred to either an aggregation object 
or storage until all of the components were operated on and ready for display.

Originally I envisioned that the presentation control flow would be part of an 
object encapsulating their representation of a web page.  Unfortunately, that 
becomes rather messy and I can see the wisdom of how albatross put the 
presentation control flow into the HTML template itself.

Data representation on both sides of the fence (CGI, template) should be normal 
python data types such as strings, integers, floats and, objects.  Objects are 
especially important because it may be convenient for an application to 
encapsulate all the data either as methods or instance variables.  In any case, 
it should be possible to run the object and retrieve the appropriate data.

on retrieving data from forms, I think of the data as being logically associated 
by name or by type.  But what should be most important is that *all* of the data 
should be available and that user filters can be applied to reduce or refine the 
data.

the only improvement one could make over the dictionary method of presenting 
data ala cgi.fieldstorage would be if one could logically group the data in the 
form and have a standard tool/method to retrieve just that named set of data and 
place it in a dictionary like structure.

Yes, I like dictionaries and I like even better the ability to use 
__get/setitem__ and related methods to create data transformations.

Now, having explained (hopefully) where my mental model was at, I banged my 
shins rather badly on the attribute based model of albatross.  One failing of 
the documentation is a complete description of the data model used for bridging 
between CGI and template.  When it comes right down to it it doesn't matter a 
piss hole in the snow what model you use as long as it is flexible and 
documented in a way a novice can understand.  Once you know what you have to 
connect to, you can create impedance matching code to translate between your 
object models and the template system object models.

One test for how good the system is comes from the ability to wiggle every 
little widget or knob through a variety of techniques ranging from static data 
assignment through more dynamic data sources such as dictionaries or method 
generated data sets without requiring the user to learn more than a few 
interfaces.  One could argue that the bridge interface between data and 
templates should be the same for all levels of data complexity.

another place I tripped on regarding albatross was the discovery that I could 
not get all of the checkbox data (on and off) back from albatross environment 
without going through a significant amount of convolution which I was willing to 
do but was unsuccessful at getting it to work.

minor points were some of the techniques for determining if a button had been 
pressed or the value of a field by dynamic name.  I'm still not sure the best 
way to handle hidden variables or should I use state preservation techniques? 
I'm sure there is a whole list of techniques we could document for various 
frequently needed circumstances but the question one should always consider is 
that if you are building a large list of tricks, are you solving the problem the 
wrong way?  Good design doesn't need tricks to do the right job.  It should 
follow naturally from the architecture.  It may be necessary to train everyone 
on the new architecture especially if it is based on a very different set of 
techniques from the normal world of experience.  But it should be simple to 
convey and easy to learn enough to get started quickly and still support the 
developer ability to master more complex techniques as the complexity of the 
task rises.

---eric