Baseline GUI Architecture (was: Baseline GUI Prototype?)
Newsgroups: comp.lang.java.help,comp.lang.java.programmer
Followup-To: comp.lang.java.programmer
Davej <galt_57@hotmail.com> writes:
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
.
Newsgroups: comp.lang.java.help,comp.lang.java.programmer
Followup-To: comp.lang.java.programmer