[Seaside-dev] Enhancement to select tag

[Louis LaBrunda]

Hi Lukas,

Thank you very much for the reply.

>Hi Lou
>
>> I am a NOOB to both Seaside and HTML, and I have great respect for all the
>> developers of Seaside, so I will take his word for it.  As there is only
>> one value returned for the select (not counting multi-selects) and linked
>> to one set of a getter/setter and the values of all the options are not
>> returned, and are not linked to any getter/setters, why does Seaside need
>> to control their values in the way it controls other input field names?
>
>This is true, as long as you only use String instances for the list
>items. Most Seaside applications use a collection of model objects
>instead of Strings.

Good point.  If I didn't have a need for some javascript code to know what
item was selected (see my last comment) before returning to the server, I
wouldn't care either.

>Another disadvantage of your solution is that a hacker might post any
>new string value. This is not possible when Seaside keeps an internal
>mapping.

I see that the current approach is slightly safer but a hacker could also
return any selected value like '9999' instead of the Seaside generated
values.  I expect Seaside would ignore it but with my approach the returned
hacker value would not be in the set of keys from the association
collection and therefore could be ignored too.  This is part of the price
that must be paid to meet the javascript requirement.

>There is no need for Seaside to control anything, but if you let it do
>so things usually become much simpler. These are all low-level things
>we usually let Seaside do.

I agree, and apologize for my clumsy wording.

>I see that the values are local to a single list, so composition
>shouldn't be a big problem. Furthermore the callbacks for each list
>item are not really needed, a simple mapping between key and values
>would probably save some memory. I created an issue for that:
>http://code.google.com/p/seaside/issues/detail?id=374.

Excellent!  Especially if something like a #values: method could be added
that worked like the #labels: method, where the block is used to answer a
label for each element in the list collection.

>In your example I don't see why you want to set the values yourself?
>Clearly I would write less code, if I just let Seaside do everything.

The example is just a simple example.  It was intended only to show that
what I wanted to do could work and not interfere with other returned
values.  I didn't add the javascript nor calls to it like onBlur() because
it would just confuse things.

I believe the system I am building will need this feature in more than one
place.  For example, one of the select lists will include a choice between
Stocks and Bonds (among other similar things).  Other required data would
be "Face Amount" and "Number of Securities".  These values would be in two
different fields.  We would like to disable one of these fields or the
other based upon the selected choice of stock or bond.  If the option value
is generated by Seaside, I have to check the label or the index of the
selected option in order to disable/enable the proper fields.  Both label
and index present a maintenance problem as the label or order can change.
They are both cosmetic and much more likely to change than the key of the
association.

>Lukas

Thanks again.  Your issue report is right on and hopefully will lead to my
being able to dump my code and let Seaside do most if not all of the work
for me.

Lou
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:Lou at Keystone-Software.com http://www.Keystone-Software.com