Shouldn't be Widget an interface?

[Jakub Zvěřina]

Consider this code on the client side (java5 just to be more clear):

List<Service> serivces = Gui.getServicesForUser(user);

for (Service service : services) {
//getTitle is a method of Service interface
final Label menuItem = new Label(serivce.getTitle());
//menu is some VerticalPanel used as menu
menu.add(menuItem);
menuItem.addClickListener(new ClickListener() {
void onClick(Widget sender) {
//contentPanel is for example ScrollPanel already
somewhere in the layout
contentPanel.setWidget(service);
}
});
}

This would be possible if I could declare Service somewhat like this:
public interface Service extends Widget {
public String getTitle();
}

There is no interface for Widget, so I actually have to do something
like this:
public abstract class AbstractService extends Widget implements
Service {
}

or this:
public interface Service {
public String getTitle();
public Widget getWidget();
}

And instead of implementing Service interface (and extending
Composite, Widget, Tree or whatever I'd need), all object would have
to extend AbstractService (that is extending one particular Widget
class - doesn't matter which one) and I'd have to reference this
abstract class in the project instead of the interface.

What do you think?

[Andrew404]

I'm no expert when it comes to Java in general, nor am I SE guru, but
looking at your example code, my 1st impression (after having just
finished my first SE course at Uni) is that it seems as though you're
blurring the MVC pattern a bit.

I would have thought that
contentPanel.setWidget(service)

would be

contentPanel.setWidget( new ServiceUI(service));

where
ServiceUI extends widget and takes a service object in it's
constructor.

I see Widget as pertaining to a family of concrete objects ( UI
object), and not an *interface* to facilitate intercommunication
between some objects.

Anyways, this post probably does absolutely nothing for you or your
question, but I would certainly love for you or anyone else to comment
on and validate/invalidate my grasp of the *fundamentals* pertaining
to this example.

cheers,
Andrew

[Ian Petersen]

On 6/27/07, Andrew404 <andr...@gmail.com> wrote:
> Anyways, this post probably does absolutely nothing for you or your
> question, but I would certainly love for you or anyone else to comment
> on and validate/invalidate my grasp of the *fundamentals* pertaining
> to this example.

I'm a fairly recent grad of a CS programme, so I'm sure there are lots
people on this list with more experience than me, but your intuitions
line up with mine in this case. Widgets are real things (well, as
real as anything gets in computer science) so my intuition is that
they should be instances of a class. I also share your estimation
that Jakub's code is blurring the MVC pattern. The "thing"
(controller, I guess) that marries a data model to a user interface
component should be separate from both and its internal structure
should reflect the separation, too.

Ian

--
Tired of pop-ups, security holes, and spyware?
Try Firefox: http://www.getfirefox.com

[Isaac Truett]

I use a couple of interfaces that define a getWidget() method. These
interfaces are conceptual UI elements, but aren't single HTML tags or
controls (maybe I need to look at Composites...), things like Section
or Page. There will be a widget for each Section, but each not
necessarily the same widget subclass (some sections are
VerticalPanels, others might be TabPanels). The interfaces provide
the API that I want for interacting with my UI (set data, add
listeners, show/hide pieces, etc.) and the getWidget() method gives me
a reference to something that GWT can work with. Plus, saying "get
widget" with the (im)proper pronunciation kinda sounds like "get with
it" which gives my code a little attitude.