Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #20821

Re: Generic JList and ListCellRenderer?

Show all headers | View raw

On 12/29/2012 7:11 AM, Chris Uppal wrote:
> Knute Johnson wrote:
>
>> I've been trying to clean up some really old code and I've hit some
>> snags.  I've got several modified JLists and the ListCellRenderers for
>> them and thought it would make sense to have generic classes that could
>> be extended for different data types that need to be displayed.  The
>> example below displays InetAddresses in the JList.  I've got another
>> implementation of JList that does a lot more than what this one does but
>> I wanted to keep this example simple and focus on the ListCellRenderer.
>
> Without knowing what directions you intend/expect to extend the code it's a
> little difficult to make sensible suggestions.
>
> So, proceeding with due absence of sense...
>
> I don't see what the clazz variable (and the associated instance checks) are
> buying you.  You could try removing them and see if that makes your code come
> to life.  It would certainly remove some of the "kludgy" smell.
>
> If that doesn't help, then it may be that you're being bothered by the way that
> ListCellRenderer has (so to speak) too many responsibilities -- it's
> simultaneously about /how/ something is displayed and about /what/ is
> displayed.
>
> So (this is only my guess, of course) you're being pulled in two directions: on
> the one hand your /how/ is pretty much fixed and you want to use nice generic
> code for it whatever the types of the values, but the /what/ is not generic and
> will change according to each application.  You are being required to do
> rampant subclassing of something that shouldn't /need/ subclassing.
>
> If that sounds as if it might relate to your problem, you could introduce a new
> kind of object who's only responsibility is to take a value, the element of the
> List (of type Object -- unless you want to mess with generics), and return a
> String which is to be the contents of the cell.  It might also have a parallel
> method which takes the (same) List element and returns an Icon (or null).
>
> The new object would have appropriate subclasses for InetAddress etc.  (which
> might or might not appear formally as separate classes in your source -- you
> could instead use anonymous classes to make the getTextFor() and getIconFor()
> methods "pluggable").
>
> So then you have just one subclass of ListCellRenderer which holds an instance
> of [a subclass of] this new class (instead of the clazz variable), and which
> always blindly uses that to "fetch" the appropriate String and/or Icon for use
> for each cell.
>
> It's difficult to think of a good name for the new kind of object (and it's
> subclasses), but in this case I don't think that's the danger sign it normally
> would be: the reason that it's difficult to find a name is that the obvious
> names (some variant on "Renderer") are already taken.  "TextSupplier" perhaps
> (or ContentSupplier, or ContentTranslator) ?
>
> It could well be that this kind of picture is over-engineered for your purposes
> (I can't tell).  But even if it is, then the real culprit is the Swing
> architecture which is under-engineered (here), so something may be needed to
> compensate.
>
>      -- chris
>
>

Thanks Chris.

-- 

Knute Johnson

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Generic JList and ListCellRenderer? Knute Johnson <nospam@knutejohnson.com> - 2012-12-28 11:01 -0800
  Re: Generic JList and ListCellRenderer? "John B. Matthews" <nospam@nospam.invalid> - 2012-12-28 20:56 -0500
    Re: Generic JList and ListCellRenderer? Knute Johnson <nospam@knutejohnson.com> - 2012-12-30 08:27 -0800
  Re: Generic JList and ListCellRenderer? "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-29 15:11 +0000
    Re: Generic JList and ListCellRenderer? Knute Johnson <nospam@knutejohnson.com> - 2012-12-30 08:29 -0800

csiph-web