Prevent Listeners From Firing/Observer Pattern

J

Jason Cavett

I've implemented the Observer pattern in the GUI that I'm writing so
that any property view to a data object will be updated if that
underlying data object is updated. The problem I am having is
described in this scenario...

1. Open two diff. views to a data object.
2. Updated nameField in view1
3. This updates the data object.
4. Data object notifies its observers that it has been updated.
5. Observers (the views) get the data from the name field and update
themselves.

This is where the problem occurs - when view2 updates itself, it fires
off its listeners (in this case, a DocumentListener and an
UndoableListener). As a result, the action takes place that those
listeners specify. So, in the case of the UndoableListener (which I
don't have any control over - it's built into Java), the field is
updated and it counts as an "edit" so that it is placed on the undo
stack. This, in essence, means that if I have more than one view
open, I get multiple items on the stack for one specific edit.

My question is this - is there any way to prevent listeners from
firing while performing an update? This seems like it's a problem
that should have been solved already because Observer is a pretty
heavily used pattern. However, I can't find any information on it
(and I can't find my GoF book either).
 
H

Hendrik Maryns

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason Cavett schreef:
I've implemented the Observer pattern in the GUI that I'm writing so
that any property view to a data object will be updated if that
underlying data object is updated. The problem I am having is
described in this scenario...

1. Open two diff. views to a data object.
2. Updated nameField in view1
3. This updates the data object.
4. Data object notifies its observers that it has been updated.
5. Observers (the views) get the data from the name field and update
themselves.

This is where the problem occurs - when view2 updates itself, it fires
off its listeners (in this case, a DocumentListener and an
UndoableListener). As a result, the action takes place that those
listeners specify. So, in the case of the UndoableListener (which I
don't have any control over - it's built into Java), the field is
updated and it counts as an "edit" so that it is placed on the undo
stack. This, in essence, means that if I have more than one view
open, I get multiple items on the stack for one specific edit.

My question is this - is there any way to prevent listeners from
firing while performing an update? This seems like it's a problem
that should have been solved already because Observer is a pretty
heavily used pattern. However, I can't find any information on it
(and I can't find my GoF book either).

It seems like the easier solution is to build in a test in the view or
the listener which checks whether such an object is already in the stack
and don’t enter an equivalent one if there is.

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGeVu/e+7xMGD3itQRAlLqAJ0c1zxVUIVKfxdv/85iiNHdv+gCuACffwVF
+qmy459cm76FpafxDgKXigg=
=bqmw
-----END PGP SIGNATURE-----
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,534
Members
45,007
Latest member
obedient dusk

Latest Threads

Top