Newbie GUI questions
I'm new to Java, so I'm sorry if I seem to be asking dumb questions.
1) The examples on this site in the Swing tutorials recommend making your own content pane, and setting the JFrame to use your own. Is this good advice and why ?
2) The menudemo action example uses a single class to handle all events for the gui, essentially making the whole gui class "listen" for an action item, and have a big section of code handling all events. I've been told that I should have individual listening handlers for each menu item? What are the pros and cons?
Tony
[580 byte] By [
TAGBa] at [2007-11-26 19:42:39]
# 1
1) The examples on this site in the Swing tutorials recommend making your own content pane, and setting the JFrame to use your own. Is this good advice and why ?
Good advice compared to what? The obvious alternative is extending JFrame, which is A Bad Idea. Creating a piece of content and then placing it in a JFrame means you can take that same content and place it in a JApplet, or a Window, or a Container, or a JDialog... Inheritance is an overused aspect of OO: where it's appropriate (ie polymorphism is required) it works well, but it's generally damaging where it's not required (ie the same could be achieved by composition - in this case using a component as one element in the composition of a frame).
2) The menudemo action example uses a single class to handle all events for the gui, essentially making the whole gui class "listen" for an action item, and have a big section of code handling all events. I've been told that I should have individual listening handlers for each menu item ? What are the pros and cons?
Using a single handler will become unmaintainable very quickly: essentially you'll have a big conditional clause and a monolithic lump of code which pulls together totally unrelated functionality. It's a thoroughly bad idea. Remember the general rule: cohesion good, coupling bad.
When building menus, toolbars, etc, the best approach by far is to use Actions. These allow you to automate the configuration of all the buttons and menu items, reflect the enabled state, and so on. Anything which suggests using the raw ActionListener interface is bad advice - it's too low-level and means that the code overhead of implementing good button etc behaviour is huge - by using actions that overhead is minimal. Note that AbstractAction is a pretty feeble implementation: it's a good idea to create your own abstract Action class which handles the stuff you need (eg mine auto-configures action properties from language files, has some sophisticated threading functionality - ie allowing for slow actions which require DB./network/file access and callback hooks to the EDT - and so on)
