JList doesn't support MVC!!

Thread view:

Jeach! - 08 Dec 2006 04:52 GMT

What does work:

For years my application ran by using my own MVC framework. I have a
couple of hundred different model objects each with their own couple of
views.

Thus far I've been limited to popping up a few windows (dialogs and
frames) which contained one or more views bound to a model. Whenever a
model was updated from a remote entity, all other registered views on
such model would successfully updat themselves.

What doesn't work:

My requirements lately have changed and I must make use of a JList to
display my views instead of JDialogs and JFrames. But at my first wack
at this, I was EXTREMLY disapointed to learn about the limitations of
the JList component...

1. When you use a ListCellRenderer implementation to pass the view to
be rendered, which in my case is a simple JPanel containing a
JCheckBox, JTextField, JRadio or any combination thereof, the damn
thing doesn't actually render as 'itself' (the actual component), but
rather it is rendered as a 'rubber stamp'! Ouch!!!!

2. Now when my models get modified from a remote entity and request for
all views to update... well, they don't because there is no way for the
parent component (the JList) to know that its child (one of the JPanel)
needs updating? Of course I could invoke a validate() and repaint() on
the list, but what kind of object relationship will I have to create
here? It wouldn't be proper for each view (each JPanel) to be aware of
its parent (the JList). Or the model to be aware of the JList.

Has anyone encountered this problem before? Or one of these problems?
I know that some of you will tell me to fix issue #1 by implementing a
JTable to look like a JList and use a cell editor, but this is NOT
acceptable in my opinion!

Reply to this Message

Michael Rauscher - 08 Dec 2006 09:00 GMT

> 1. When you use a ListCellRenderer implementation to pass the view to
> be rendered, which in my case is a simple JPanel containing a
> JCheckBox, JTextField, JRadio or any combination thereof, the damn
> thing doesn't actually render as 'itself' (the actual component), but
> rather it is rendered as a 'rubber stamp'! Ouch!!!!

JList is the view. And the view does render itself.

To render itself, JList doesn't implement the real rendering process but
delegates it to Components which are retrieved from objects that
implement the ListCellRenderer interface.

This way you get two advantages:
a) great flexibility regarding the rendering process
b) in the best case only one object is needed to render all rows.

So, it's not "Ouch" but "Yeah" :)

> 2. Now when my models get modified from a remote entity and request for
> all views to update... well, they don't because there is no way for the
[quoted text clipped - 3 lines]
> here? It wouldn't be proper for each view (each JPanel) to be aware of
> its parent (the JList). Or the model to be aware of the JList.

When your list's model gets modified it has to inform it's
ListDataListeners about the change. That's all - no need to implement
anything like validate()/repaint()...

> Has anyone encountered this problem before? Or one of these problems?

In fact, I don't see any problems here.

> I know that some of you will tell me to fix issue #1 by implementing a
> JTable to look like a JList and use a cell editor, but this is NOT
> acceptable in my opinion!

JList:
"A component that allows the user to select one or more objects from a
list."

If this is not acceptable to you, feel free to implement your own
editable list component. I don't see any needs for this due to the
presence of JTable.

Bye
Michael

Reply to this Message

Jeach! - 08 Dec 2006 20:58 GMT

Andrew Thompson, Sorry for multi-posting!

But different groups have different audiences and specialties so I
still don't really see what the problem is? Regardless, I'll stop
multi-posting!

Michael Rauscher, thanks for your response!

You see, I had to find out the hard way (by using it) that you are
right: A JList is actually a view! But this is exactly why I'm
having problems.

In my opinion a JList should NOT be a view, it should be a view
manager. Meaning that it should accept many views and manage its
layout, selection model (multi or single), view additions and removals
and that's prety much it.

What Sun has implemented makes alot of sense if you consider that you
will be displaying java's basic data models (strings, booleans, numbers
or basic labels). But for a real-world application based on reuse
(view reuse), this makes no sense at all.

But this causes much problems when an application has real models and
for each such models there are several views. The idea is to be able
to REUSE these views in view managers such as a JList. I guess the Sun
team pretty much left us in the ice-age when it comes to sofisticated
applications.

Althoug I didn't want to get into it, I might just have to use a JTable
after all.

Again, thank you for your response!

> > 1. When you use a ListCellRenderer implementation to pass the view to
> > be rendered, which in my case is a simple JPanel containing a
[quoted text clipped - 36 lines]
> Bye
> Michael

Reply to this Message

Oliver Wong - 08 Dec 2006 22:04 GMT

> Andrew Thompson, Sorry for multi-posting!
>
> But different groups have different audiences and specialties so I
> still don't really see what the problem is? Regardless, I'll stop
> multi-posting!

Try crossposting instead -- You'll still address multiple groups, but
there won't be duplicates of your message scattered all over the place:
http://www.cs.tut.fi/~jkorpela/usenet/xpost.html

- Oliver

Reply to this Message

Andrew Thompson - 09 Dec 2006 00:50 GMT

> > Andrew Thompson, Sorry for multi-posting!
> >
> > But different groups have different audiences and specialties so I
> > still don't really see what the problem is? Regardless, I'll stop
> > multi-posting!

Thanks for confirming. I would now turn to your
technical problem, but I see you already have the
benefit of Michael Rauscher's experience, so things
should proceed smoothly..

> Try crossposting instead -- You'll still address multiple groups, but
> there won't be duplicates of your message scattered all over the place:
> http://www.cs.tut.fi/~jkorpela/usenet/xpost.html

Good idea.

Andrew T.

Reply to this Message

JList doesn't support MVC!!

Free Magazines