🚀 go-pugleaf

sven goetgeluck wrote:
> 
> Hi Paul this is my code , ...

Actually, John McGrath has been helping you out
with the latest set of problems.  He may have a
separate response, but I thought I'd jump back into
this.  

First, I notice that your Spinner object has a dependency 
which it really should not have.  It requires a textField.
When designing components, you should design them to be
what is called "contractless".  That means that they should 
be able to stand on their own with no dependencies on other 
components.  

In this case, your spinner control should simply 
allow other components to register themselves as listeners
to any change caused by mouse clicks on either of the buttons.
It should know nothing about who may be listening except that
they implement the appropriate listener interface

So, to do this, you would add the following
instance variable and methods to Spinner:

  private ActionListener actionListener = null;

  public void addActionListener(ActionListener l) {
    actionListener = l;
  }
  public void removeActionListener(ActionListener l) {
    actionListener = null;
  }

You would pass to the listener "positive" or "negative" commands.
Actually, assign actionCommand strings to the two buttons and
just pass that actionCommand string to the listener.  Note, we are
assuming just a single listener.  This may not fit all cases, but
it does fit this particular case.  

I don't see any need for a model in Spinner.  It is simply a control 
which emits notifications/events to listeners of how it has changed.  
It does not need to maintain any sense of "state".

Lastly, with regard to Spinner, it should never receive keyboard focus 
(spinners just don't behave that way), you should not provide KeyEvent 
handling in the spinner.  Instead, that event handling should be done 
in the textfield because it naturally handles key events.  As a 
consequence of this, the "increment()" and "decrement()" don't make 
any sense here.


When you have these changes made to Spinner, put it on a frame, and
register the frame as a listener.  With each new component, you have
to test it in isolation.  To test whether events are being broadcast
properly, just use "System.out.println()" statements in the event
handling method of the frame.  Write a "main()" method which
instantiates the frame, pack and show it.  Click on the 
spinner and see whether you get what you expect. 

After you are sure the spinner works correctly (it just emits 
change events with values of "positive" or "negative") move 
on to the next set of design issues.


Next, let's rename PlusMinusTextField to "NumericEditControl".  It
was my mistake to name it PlusMinusTextField in the first place.  
It's a compound control, so it shouldn't be named after just
one of its subcomponents.  

In the NumericEditControl component, add "this" as a listener
to the spinner subcomponent instance and implement the 
ActionPerformed interface.

I notice from your code in PlusMinusTextField that you have
added a "jTextField" component, and more or less ignored the
original "tf".  Either you want one or the other, not both.

Also, you seem to be using the Designer and then rearranging
things by hand.  Try to avoid this.  Just let JBuilder do its
job, and you fill in the blanks where it asks you to.

The "increment()" and "decrement()" methods would make sense
in the NumericEditControl.  Call these when you handle the
action event which comes from the spinner.  

The NumericEditControl needs an "add<type>Listener()" where
you choose the type of the listener which other components 
should register as in order to get notifications that a change
in value has occurred.  At present, you have no way to register
listeners with this control.  No component should have to 
"reach into" the NumericEditControl just to receive change
notifications.  Essentially, you are "reaching into" when
you get the document and then add the textfield in Frame1
as a listener.  This isn't the way it should be done.  Outsiders
should not know the implementation details. 

For a quick solution, I'd make it an AdjustmentEvent.  Why?

1) The idea behind object-oriented programming is to increase
re-use.  AdjustmentEvent is already written for some very 
similar cases.  It may, at first, seem like overkill.

2) If you implement the Adjustable interface in 
NumericEditControl (use the "Implement interface" Wizard)
lots of the work is already done for you.  And, you could
customize this control so that it would have limits, and
you could do fancy things with how much each mouse click
changes the value.

Finally, when you get all that to work, come back and
we'll talk about subclassing PlainDocument so that only
numeric characters can be inserted into the textfield 
sub-component of NumericEditControl.


If you get stuck, come back to the newsgroup.  I might
have some revised code for you.  But for now, it's 
probably better if you struggle with the issues on
your own.  Good luck.


Paul Furbacher (TeamB)