[albatross-users] revisiting checkboxes..

[Andrew McNamara]

>> One way or another you will have to carry the list of "unchecked"
>> boxes across.
>
>when I use straight HTML, I don't have to.  It's possible to encode all the 
>information in the name and value fields such that you can extract a list of 
>checked and unchecked entries in a single pass.

That's still possible - essentially that's what you're using in option 3,
although my example went further, by using the namespace merging.

BTW, in my example, the <al-input> should be:

        <al-input type="checkbox" value="on" 
                nameexpr="'spamtrap_tokens.' + token_i.value()">

>thanks for the options.  I'm probably going to try something like the last
>one although I am having troubles with names.  I considered the full list
>in a hidden variable unpleasant because at some point, you run out of room
>and you really don't know where that limit is.  Each entry is 16
>characters long not including separator and it's possible for the user to
>configure the system so that there are a few hundred entries visible on
>the screen.  It wouldn't be wise but they can do it.  At what point does a
>hidden variable run out of room and how does that manifest?  Are the
>limits the same for all browsers?  Therefore, I prefer less fragile
>options.

The HiddenField session mixin store the application context in a hidden
input field. I've regularly used this with many kilobytes in the context
with a number of browsers (IE 5.5, IE 6, Mozilla 1.0, Opera, etc, albeit
all modern browsers - I've given up on Netscape 4 aged rendering model
and security problems).

>what I used to do was stick a prefix in front of each spamtrap token and
>make that the name.  The value would be the spamtrap token.  After they
>submit button press, I would look through all the returned values for the
>prefix and check for the checked or unchecked state.  I was hoping for
>something equivalently simple.

Essentially, you're just after a boolean checked/unchecked value for
each token, yes? You don't need to do anything as complex as setting
the input value to the token, as well as having the token in the name -
a simple value="on" should be enough.

>I like your idea of using separate names that you detailed.  As I stated
>above, I'm having trouble with names and it looks a little weird.  For
>example, I have a simple variable called "spamtrap_token" and it looks
>like this: 6212922bbc33af37 if I refer to it simply as """<al-input
>type="checkbox" name="spamtrap_token" """ the name is not translated.  If
>I instead refer to it as """<al-input type="checkbox"
>nameexpr="spamtrap_token" """ I get an error stating:
>
>    return eval(name, {}, self.locals.__dict__)
>   File "<string>", line 1
>     6212922bbc33af37
>                    ^
>SyntaxError: unexpected EOF while parsing

What's happening here is the nameexpr is being evaluated to yield the name
of '6212922bbc33af37', which is then evaluated again to get to input value
(which is where the exception is raised).

You could prepend something to the token (as you suggest earlier) to make
it a valid python expression (albeit one that raises an AttributeError,
which is ignored by albatross):

    <al-input type="checkbox" name="'token' + spamtrap_token">

Setting an explict value="on" attribute will also prevent the error.

The rules and relationships between name, nameexpr, value and valueexpr 
are really too complex for meer mortals (me included).

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/