Baseline GUI Architecture (was: Baseline GUI Prototype?)

[Stefan Ram]

Newsgroups: comp.lang.java.help,comp.lang.java.programmer
Followup-To: comp.lang.java.programmer

Ok, I've written command line code that way, but surely you don't
begin a desktop GUI project with nothing but an empty Main class. What
do you start with? Is there a standardized prototype? Thanks.

I have an approach, that seems natural to me, but then also
has some problems:

I divide a GUI-app into »appjects«, for example, by their different
lifetime: When an application is opend, one appject is created: The
main appject, a print dialog is created /later/ (it has a different
lifetime), so it's a separate appject.

But the main appject also might contain sub-appjects with the same
lifetime as the main appject, because this helps to modularize the
code into distinct appject sections.

For example, a main GUI window might contain a function graph plotting
area. This might be implemented as a distinct component, so that it
can be used in different applications and has a cleanly separated
source code.

This is straightforward, but there also is a problem: I would like to
add commands for the sub-component to the main application menu. So I
need to define how a components menu is merged into an application's
menu. I need to specify interfaces for this.

And, should the main menu only communicate direcly with the main app,
so that when a component's menu entry is selected, the main app is called
first, and then can forward this command to the component, or should
the components entry in the main menu call a method of the component
directly? The first approach seems to be hierarchically cleaner, while
the second approach seems to be easier to implement.

One can also read something about one implementation of »menu merging«
here:

http://msdn.microsoft.com/en-us/library/bdteyst2(v=vs.71).aspx

 

[markspace]

Newsgroups: comp.lang.java.help,comp.lang.java.programmer
Followup-To: comp.lang.java.programmer



I have an approach, that seems natural to me, but then also
has some problems:

This seems like normal object orient analysis and design to me. You
don't have to call those concepts appjects, calling them objects would
be a perfectly workable term.

I'll also add that for Java, there's some consensus that the NetBeans
platform makes a good start for larger application. (For small ones,
roll-your-own seems the preferred approach.)

This is straightforward, but there also is a problem: I would like to
add commands for the sub-component to the main application menu. So I
need to define how a components menu is merged into an application's
menu. I need to specify interfaces for this.

I believe a Mediator pattern could help here. Mediator simplifies
interaction between objects, and also loosens coupling. The basic idea
imo is to make an object that injected into each large subsystem or
"appject" in your application, which that system or appject then uses to
communicate with the rest of the app.

I call this Mediator object an ApplicationContext. It provides services
such as access to the GUI, persistence, command line
properties/configuration, etc. whatever the app needs. It's all in one
place and it's injected so testing is now much easier. I think this
works better than using static factory methods, which get embedded into
your code and can represent undesirable "global" objects.

The ApplicationContext can get unwieldy and turn into a God Object if
you're not careful; keep it's interaction at a high level and push all
of the functionality into the services that it just hands around to
different objects.

 

[markspace]

I'm sure it does, but I'm building a couple side projects on top of
Eclipse and it's very robust and extensible too, plus NetBeans used to
be really slow. (Don't know if it still is.)

Just to be clear, there's a difference between NetBeans the IDE, and
NetBeans Platform. The latter is a large API of classes that go beyond
the Swing API. NetBeans Platform seems to be popular and well
respected. I haven't used it personally however.

Moar infos:

<http://netbeans.org/features/platform/>

 

[Arne Vajhøj]

I'll also add that for Java, there's some consensus that the NetBeans
platform makes a good start for larger application. (For small ones,
roll-your-own seems the preferred approach.)

Really?

My impression is that custom on top of Swing - Eclispe RCP - NetBeans
Platform goes about 100:10:1 in usage.

Arne