[Bese-devel] Re: what don't i understand about select-field?

Marco Baringer mb at bese.it
Tue May 16 14:36:14 UTC 2006


"Ties Stuij" <cjstuij at gmail.com> writes:

> Greetings,
>
> I've been looking at the select classes in form.lisp and it seems to
> me there is a lot of double work going on while the benifit is not
> quite clear to me. Since you have your key-value pair ready already,
> why make an index also? Especially with entities like hash tables or
> alists which are supposed to have just one key to retrieve to begin
> with.
>
> Also i didn't really get the mapping-select abstraction, since it
> implements its only method, render-options, exactly the same as
> select-field, just with different names.

that looks like a mistake on my part.

> Anyway as practice i made a select field which brings the amount of
> forms needed down from 12 to 4 (see below). It's the alist-select
> field from form.lisp except for that the value you're after is now
> already in client-value. On top of that i've built simpler select
> field, which in functionality is the same as a normal select-field.
> For the 'selected' attribute of options it compares the value, but
> that could easily be changed to key.
>
> As i said i made it for practice, but perhaps we could use these to
> replace the select fields of form.lisp? hash-table-select and
> plist-select are easily converted i think and the end result is faster
> and easier to read/use.
>
> But then again i probably missed the thing that's handy/good/practical
> about the current setup.

the only thing you'll need to deal with is non-string keys and values,
an even more confusing situation is when you have equal (but not eq)
strings in an eq hash table :(.

-- 
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
	-Leonard Cohen




More information about the bese-devel mailing list