Identifying fields of a class

[Thomas G. Marshall]

Dale King coughed up:

Thomas G. Marshall wrote:
....[rip]...

It's not a bad goal. But regarding GUI's, I tend to want the
entirety of the gui elements all in one place.

And I find that usually means I am trying to do too much in one place.
It shows I am trying to put all the logic in one place rather than
distributing it over a bunch of lightweight objects.

I think you're wrong here.

Most gui designers I know using swing, in fact /all/ of them, do nearly
everything in GridBagLayout. It just so easy to cut and paste the
structural gobledy-gook once you have the thing mastered. And it gives you
full resizing control (well, mostly ). SpringLayout may one day be the
most commonly used LM, but GBL seems very popular. And with GBL, you often
end up laying out many components in a single container.

I want those components in one place, along with all the others. It allows
me to easily change, say, ThingyButtons for SmedlyButtons, should the need
arise.

I question whether it is the gui component it should talk to or the
model, but we'll sidestep that one.

I question whether you meant model or controller here, but we'll sidestep
that one.

And the answer is simply that the object that implements the listener
interface itself has the reference to the other component.

So if the listener for component a needs to talk to component b then
you might have:

a.addFooListener( new AFoolistener( b ) );

Yep. And I've done that extensively as well, in the deeper past. *However*
, I would argue that it smells of over-design in many cases. {shrug} I'm
discovering that I don't care much for this toopic.

 

[Thomas Hawtin]

SpringLayout may one day be the
most commonly used LM, but GBL seems very popular.

Let's hope they manage to get baselines in simple examples to line up first.

http://java.sun.com/docs/books/tutorial/figures/uiswing/layout/SpringDemo3.gif

There are some good things about SpringLayout. It deals with distances
between grid lines (well, components normally) rather than insets. Code
using GridBagLayout.insets looks daft when the style guide calls for odd
separations. Using spacer components is arguably better, but is more
obviously daft.

I had a go at using SpringLayout, because I think the concept is good.
However I ended up witting my own Springs and the hole experience was a
let down. Should have been pulled.

Tom Hawtin

 

[Dale King]

Dale King coughed up:

Thomas G. Marshall wrote:

....[rip]...

It's not a bad goal. But regarding GUI's, I tend to want the
entirety of the gui elements all in one place.

And I find that usually means I am trying to do too much in one place.
It shows I am trying to put all the logic in one place rather than
distributing it over a bunch of lightweight objects.

I think you're wrong here.

Most gui designers I know using swing, in fact /all/ of them, do nearly
everything in GridBagLayout. It just so easy to cut and paste the
structural gobledy-gook once you have the thing mastered. And it gives you
full resizing control (well, mostly ). SpringLayout may one day be the
most commonly used LM, but GBL seems very popular. And with GBL, you often
end up laying out many components in a single container.

I want those components in one place, along with all the others. It allows
me to easily change, say, ThingyButtons for SmedlyButtons, should the need
arise.

I think you totally mistinterpreted what I was referring to. Layouts
have nothing to do with it. I am supposing that there is a method in a
class somewhere that creates the GUI. It will have local variables for
the component as it builds them and it can lay them out however it
wants. The issue is whether that component then needs *instance*
variables for all the components.

What I meant by doing too much in one place is a design where the class
that creates the GUI also implements the linstener interfaces and when
creating the GUI it does things like:

component.addXXXListener( this );

What I meant by distributing it over lightweight objects where you
instead create other classes, perhaps anonymous classes, to do the work
rather than funelling everything into one master object. Each of these
lightweight objects is doing one simple thing.

I question whether you meant model or controller here, but we'll sidestep
that one.

No, I meant model. For example if one of the things I need to control is
whether a certain button is enabled then it really isn't the JButton I
need, but the ButtonModel implementation underneath that Button. This
can particularly come into play where you might have a menu item and a
toolbar button that do the same thing. They can share the underlying
model so that you only have to change the model and both components are
changed.

Yep. And I've done that extensively as well, in the deeper past. *However*
, I would argue that it smells of over-design in many cases. {shrug} I'm
discovering that I don't care much for this toopic.

And I usually do tend to over-design things, but then again I only write
Java as a hobby and don't get paid to program in it (which unfortunately
most employers think that means I have no experience in it).