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

[Dave Cole]

>   | http://www.object-craft.com.au/projects/albatross/albatross/tag-input-generic.html
> 
>         if user:
>             ctx.locals._user = user
>             ctx.add_session_vars('_user')
>                                   ^
>                              remove the '_' ??

The '_' prefix is there to prevent the browser ever being able to
provide _user as an input field in a request.  It effectively protects
the object from external modification.  From:

    http://www.object-craft.com.au/projects/albatross/albatross/tag-input.html

        When merging browser requests the application object places
        the browser supplied value back into the execution context
        value referenced by the name attribute. The application
        request merging will not merge variable names prefixed by
        underscore. Use this to protect application values from
        browser modification.

>   | http://www.object-craft.com.au/projects/albatross/albatross/tag-input-image.html
> 
> Oooooh, nifty!!
> 
> So, having said I feel stoopid for commenting on the docs...  I notice 
> that the page renders as:
> 
>   <al-input type="image" nextpage="m" srcicons/right.gif" whitespace>
>                                       ^
>                                  missing " again.

That is really bizarre.  Another latex2html bug.  It comes up fine in
the PDF documentation.  The actual file used in the document is
doc/doctest/tags-input-image (from the Albatross top level directory).

It looks like this:

    >>> import albatross
    >>> class Ctx(albatross.SimpleContext):
    ...     def input_add(self, *args):
    ...         print args
    ... 
    >>> ctx = Ctx('.')
    >>> albatross.Template(ctx, '<magic>', '''
    ... <al-input type="image" nextpage="m" src="/icons/right.gif" whitespace>
    ... ''').to_html(ctx)
    ('image', 'nextpage,m', None, 0)
    >>> ctx.flush_content()
    <input type="image" src="/icons/right.gif" name="nextpage,m">

The files in the doc/doctest directory are constructed so that we can
run 'make test' in the doc directory and use all of the documentation
fragments as unit tests.

>   | http://www.object-craft.com.au/projects/albatross/albatross/tag-input-file.html
> 
>    "a flag indicating whether or not the list (5.2.2.4) attribute was
>    present."
> 
> is directly followed by:
> 
>    "The request merging allows the user to submit more than one file in a
>    file input field. To simplify application code the Request always
>    returns a list of FileField objects for file inputs"
> 
> So, 'request merging' allows submitting more than one file in a single
> al-imput, but the list attribute allows for multiple al-inputs of the
> same name? ?? 
> 
> It seems unclear.

I blame Andrew :-)  (*ducks*)

>   | On a personal note, I find StudleyCaps quite disturbing.  In 1994 after bei
>   | ng a 
> [...]
>   | again, this is a long-winded way of saying that ordinary_words 
>   | separated_by_the_underscore_character is preferable to me and that I subscr
>   | ibe 
> 
> 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...

I follow the BDFL.

  http://www.python.org/doc/essays/styleguide.html

        Class Names

        Almost without exception, class names use the CapWords
        convention. Classes for internal use have a leading underscore
        in addition.

Ben (another guy here) says (paraphrased) that when speaking a
(spoken) language you strive to speak like a native, or without an
accent.  The same should apply to programming languages.  If you
follow the BDFL you are less likely to code Python with an accent.

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

The application and execution context cooperate to deal with the
session.  The execution context is where the session data is created
manipulated, but the application is usually responsible to loading
and saving the session.  This allows the application to maintain a
long lived connection with a server if necessary.  Remember that an
execution context lives only long enough to process a single browser
request.

Hope that does not make things less clear...

- Dave

-- 
http://www.object-craft.com.au