🚀 go-pugleaf

Excellent John! :)

I like your "common model" approach; the way I was processing my events is
very ugly and it seems more "patch" than well done code.

The last months I was working in a UI application with C#. .NET Windows
Forms is a very easy to use UI library, but it does not implement MVC and
the "common model" approach you suggest cannot be implemented. The lack of
this design pattern makes the Windows Forms components hard to customize and
to scale.

Thanks a lot


Ernesto




"John McGrath [TeamB]" <ng-b@JPMcGrath.net> wrote in message
news:40ff6193$1@newsgroups.borland.com...
> On 7/21/2004 at 4:18:27 PM, Ernesto Basc�n wrote:
>
> > By example, I have my own "color chooser dialog"; I want the red, green,
> > blue text fields to show their respective values when the user clicks a
> > color selection panel, and I want the color selection panel selector to
> > move on automatically everytime the text fields value change.
> >
> > When the user clicks the color selection panel, an event tries to modify
> > the text field values and that fact raises an event trying to modify the
> > color selection panel that raises again the event to modify the text
> > field values and so on.....
>
> Got it.  There are two approaches  to do this sort of thing.
>
> Common Model
> ------------
>
> Swing components use a Model-View-Controller (MVC) architecture.  Ignoring
> the controller part, which in Swing is kind of mixed in with the view, you
> have two components:  The model, which holds a value, and the view, which
> shows the value.
>
> Swing UI (view) components will automatically create an appropriate model,
> so it is easy to use them without worrying much about the model, but it is
> always there.  When you get to the more complex components, being aware of
> the separate model and view becomes more and more important.
>
> In your case, you have 4 different view components that all show the same
> value (or one aspect of that value).  If you write your code with a single
> model component, then everything will be updated automatically and you
> will will not have to listen to events and update the other components.
>
> I do not know what your color selection panel looks like, so it is hard to
> say exactly how you would implement this.  My guess is that the simplest
> approach would be to create a model component composed of 3
> PlainDocuments.  These documents would serve as the model for the text
> fields.  This model component would listen to the documents and update the
> color value when one of them changed.  When the color value actually
> changed, it would fire a stateChanged() event.  The color selection panel
> would listen for these stateChanged() events and update itself when that
> occurred.
>
> External Listeners
> ------------------
>
> The second approach is what you have tried.  This is definitely not as
> clean as the above approach, but it is a workable solution.  And in some
> cases, the common model approach cannot be used because you cannot change
> the model.
>
> The biggest trap with using external listeners is the one you have fallen
> into - recursive event firing.  The critical thing is that you only change
> the value of one component when the value of the other component actually
> changes.
>
> If you do that, the change happens like this:  Both components start out
> with the same value, say 1.  The user changes the value of component A to
> 2.  Component A notifies your listener that the value of A has changed,
> and the listener sets the value of component B to 2.  As a result of this
> change, Component B notifies your listener that its value has changed, so
> that listener sets the value of component A to 2.  However, its value was
> already 2, so no change has occurred and the component does not fire an
> event.  This chokes off the recursive event firing.
>
> Two of the possible pitfalls with this approach are temporary change
> events and value rounding.  The first occurs when a component ends up
> changing and then immediately changing back.  Since the component's state
> *does* change, the recursion does not get choked off.  The rounding
> pitfall occurs when a text field is used to display a value and then the
> value is computed from the text field's string value.  In this case, the
> value actually changes, even though it does not appear to be, since the
> text display remains the same.  So again, the recursion is not choked off.
>
> -- 
> Regards,
>
> John McGrath [TeamB]
>
> ---------------------------------------------------
> Before sending me e-mail, please read:
>     http://www.JPMcGrath.net/newsgroups/e-mail.html