Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to distinguish between user selection and programatic selection with ListSelectionListener

Scott Palmer <email@hidden> wrote:

>This is entirely unreasonable. You are effectively saying that I must
>replace the default model of almost every single GUI widget in my
>application

No I'm not. I'm saying that the JComponents need to have models
(model-instance objects) which are mutually consistent in their
representation of the conceptual model.

If that is done with custom model-objects, or by coordinating between
default model instances doesn't matter.


>If you load a document/project and need to initialize the GUI without
>the Swing components calling back to listeners that end up marking the
>document as modified or triggering intensive processing unless you have
>additional logic in the listeners to ignore the 'programmatic changes'
>to the model..

Please give a concrete example. It should have the kinds of listeners that
mark the document as modified when displaying the initial state, since
that's the part that I really can't figure out here.

When the document model is initializing its many model-instance objects,
the document should be in an INITIALIZING state, not in a LIVE state. The
INITIALIZING state shouldn't accept editing events, because they would be
spurious at that point. That INITIALIZING state is part of the conceptual
model's mechanism for managing its (perhaps many) concrete model-instance
objects underlying JComponents.

How you manage the INITIALIZING state depends entirely on implementation.
It could be an overt state variable (e.g. a boolean or int) or it could be
that all initial values are set before any listeners are attached. No
matter how it's done, it has to be atomic with respect to the overall
model's state. That's why the overall model design matters.

Conceptually, the INITIALIZING state is similar to Java's constructor
methods. There are certain guarantees about who sees what values when, and
the number of times a constructor is invoked (exactly once). The
guarantees only get confusing when you have things like a superclass
constructor calling a subclass method that (mistakenly) assumes the
subclass constructor has completed execution.

Or if you wish, it can be compared to the synchronized keyword, whose
purpose is to allow coding of atomic changes.

As a hardware analogy, I'm also thinking of reset code that initializes the
state of the CPU and other hardware, and only then enables interrupts and
DMA. Otherwise there's garbage state and incoherent behavior.

The other thing I can't figure out is what this has to do with programmatic
vs. user-initiated events. Well, I can sorta understand it, since
INITIALIZING can be seen as discarding or ignoring certain events. But the
INITIALIZING vs. LIVE state distinction is simply to obtain consistent
model behavior. It has nothing at all to do with the origin of the events,
only with the point in the model's lifetime when it should or shouldn't be
accepting and acting on the events. Once the model (i.e. all its
individual model-object instances) gets past the INITIALIZING state, then
all events, whether programmatic or user-initiated, should change the
model's state in the coherent model-defined way.

-- GG
_______________________________________________
java-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/java-dev
Be sure to read the FAQ http://developer.apple.com/java/faq/ before posting
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.