[Seaside] list of textarea problems with updating

[Avi Bryant]

Tim,

Iterate over ValueHolders instead of Strings.  Then you can
use <textarea sea:id="each.contents"> and you're good to go.  You just
need to do the appropiate munging to and from collections of Strings to
collections of ValueHolders in #choices and #acceptEdits.

Generally, I find it's rare to have a list of strings that needs to be
modified instead of, say, a list of Question objects.

On Mon, 15 Jul 2002, Tim Rowledge wrote:

> I'm trying to create a page for editing my multiple choice questions.
> It's ok so far _except_ that I can't find a way to deal with having an
> arbitrary (though small) number of textareas (I'd probably accept <input
> type="text"> if it really makes a difference) for editing the choices.
>
> Using a perfectly ordinary repeat I can of course create the right
> number of textareas and give them the right contents, but I can't find
> a way to handle the updating and altering of the strings. I'm using a
>
> <ol>
> <li sea:id="each/choices"> <textarea sea:id="editOption"></textarea>
> </ol>
>
> ...sort of arrangement. #editOption is implemented to return locals at:
> #each and the textareas get the proper strings. Unfortunately, I have to
> implement editOption: somehow and I don't seem to get a suitable bunch
> of information to be able to do it. Obviously, I get back the edited
> string, but no way to tell which one it should replace!
>
> I've tried quite a few things so far with little result. I though at
> first that the action attached to my 'accept the edit' button would be
> done first so I could simply nil out the previous list of choices and
> have #editOption: just build a new one. Bzzzzzzt. #editOption: is dealt
> with before it gets anywhere near #acceptEdit. I tried adding the button
> at the top of the form to force the order - no luck. Nor with a hidden
> input at the top.
>
> All plausible ideas welcomed!
>
> tim
>
>