On Jun 20, 2004, at 5:54 AM, Andriy Shapochka wrote:
> It can be observed the
> majority of "comboboxed" (checkbox, radiobutton, list are the flavors)
> cases
> deals with picking one or several data objects (often although not
> necessarily corresponding to the records in lookup tables) displayed as
> strings to the application users.
...
> The "LookupCache" is all about automation of this fundamental
> activity. It
> maintains the single "library" of dictionaries of the type "string
> view" ->
> data object for use with all those combo boxes, and the main beauty of
> it is
> you have to update the string view only once per object, whenever the
> object
> changes and immediately it becomes available for all the controls
> relying on
> the lookup cache technology. Of course everything is raw to a certain
> degree, but the proof of concept is definitely here.
Yeah, the way ComboBoxModel works totally sucks... It requires all
these horrible workarounds. When working on a Swing bindings project
prototype (aka JStaple -
http://cvs.sourceforge.net/viewcvs.py/jstaple/sandbox/andrus/jstaple-
scratch/ ), I hit the same problem of looking up the original object
for each display label.
On other projects (umm... CayenneModeler which is far from being a
textbook example of a Swing app :-)), I did the label extraction inside
the renderer and this kind of eliminated the need to do the lookup. But
the solution itself seems kind of unclean...
Andrus
This archive was generated by hypermail 2.0.0 : Mon Jun 21 2004 - 02:22:09 EDT