Home » Eclipse Projects » GEF » model change notification from commands
| model change notification from commands [message #171404] |
Sat, 12 March 2005 16:03  |
Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
all the standard GEF samples show model change notifications being fired
from within the set-methods of the model itself.
however, it seems to me that there are benefits to be gained from having
change notifications be issued by commands (in the execute and undo
methods) rather than by the model.
the issue here is the lack of an obvious place to hook the listener into
the object to be monitored. at the time the command is to be executed,
it needs to figure out all the parts of the UI that need to be notified.
one approach would be to maintain a map of EditParts (for GEF viewers)
or other listeners (applicable to non GEF viewers as well) which are
indexed by model elements. so when the command executes, it figures out
which listeners need to be notified based on the model elements that are
changed. viewer activation and deactivation would have to do maintenance
on this map (instead of hooking into the model directly).
does anyone have any experience with this? is this a reasonable way to
proceed?
regards,
al
|
|
| |
| Re: model change notification from commands [message #171475 is a reply to message #171468] |
Sun, 13 March 2005 09:32  |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
Pratik Shah wrote:
> "Al Major" <alnospammajor@noboxspamspoon.com> wrote in message
> news:d0v3tc$r7v$1@www.eclipse.org...
>
>>all the standard GEF samples show model change notifications being fired
>>from within the set-methods of the model itself.
>>
>>however, it seems to me that there are benefits to be gained from having
>>change notifications be issued by commands (in the execute and undo
>>methods) rather than by the model.
>
>
> Like what? I don't think this is a reasonable way to proceed.
>
>
batching notifications for compound commands for one (to minimize the
number of display refreshes). the fire from set-method is, in general,
quite fine grained.
regards,
al
|
|
|
| Re: model change notification from commands [message #171478 is a reply to message #171404] |
Sun, 13 March 2005 09:37 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
Al Major wrote:
>
> the issue here is the lack of an obvious place to hook the listener into
> the object to be monitored. at the time the command is to be executed,
> it needs to figure out all the parts of the UI that need to be notified.
>
> one approach would be to maintain a map of EditParts (for GEF viewers)
> or other listeners (applicable to non GEF viewers as well) which are
> indexed by model elements. so when the command executes, it figures out
> which listeners need to be notified based on the model elements that are
> changed. viewer activation and deactivation would have to do maintenance
> on this map (instead of hooking into the model directly).
>
i realized a hybrid approach is possible. hook the listeners into the
model as shown in current samples. but make the model's fire/notify
method public. call this fire/notify from within the command code
(instead of from the set-methods of the model code). this appears to
allow the desired flexibility without requiring much change to existing
GEF ways of doing things.
regards,
al
|
|
| |
| Re: model change notification from commands [message #171540 is a reply to message #171515] |
Mon, 14 March 2005 01:52 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
>>>
>>>
>>>Like what? I don't think this is a reasonable way to proceed.
>>>
>>>
>>
>>batching notifications for compound commands for one (to minimize the
>>number of display refreshes). the fire from set-method is, in general,
>>quite fine grained.
>
>
> The display refreshes just once when all the commands in the CompoundCommand
> have executed and all the notification has been fired.
>
>
is that so? that's clever! i'll go look at the code and see what's
going on.
there's a less concrete justification: in my app it seems like a
cleaner design. the model is used not only for graphical editing, but
also in a batch processing mode where there are no listeners. the
commands are only used for graphical editing. so it seemed "obvious" to
put the notifications in the command.
and it's parsimonious. all model changes in graphical editing are being
made through the commands anyway. and the commands have a coarser
grained picture of the model changes and so can minimize the number of
notifications. in that sense it seemed quite reasonable. but i recognize
that this may be a matter of personal taste.
and with the alternative design that i proposed in the other thread,
i.e. listeners in the model, but notification from the command, i can
use most of the standard GEF idiom for "hooking" / "unhooking". so the
initial cost of doing things this way is quite low.
do you see a problem with doing things this way? any concrete downside?
regards,
al
|
|
|
| Re: model change notification from commands [message #171550 is a reply to message #171540] |
Mon, 14 March 2005 04:38 |
 Pratik Shah
Messages: 1077
Registered: July 2009 |
Senior Member |
|
|
"Al Major" <alnospammajor@noboxspamspoon.com> wrote in message
news:d12qq5$s07$1@www.eclipse.org...
> >>>
> >>>
> >>>Like what? I don't think this is a reasonable way to proceed.
> >>>
> >>>
> >>
> >>batching notifications for compound commands for one (to minimize the
> >>number of display refreshes). the fire from set-method is, in general,
> >>quite fine grained.
> >
> >
> > The display refreshes just once when all the commands in the
CompoundCommand
> > have executed and all the notification has been fired.
> >
> >
> is that so? that's clever! i'll go look at the code and see what's
> going on.
You won't find it in GEF. It's in Draw2d. It uses a DeferredUpdateManager
that queues painting on the display thread, and hence first waits for
whatever's on that thread to finish executing.
>
> there's a less concrete justification: in my app it seems like a
> cleaner design. the model is used not only for graphical editing, but
> also in a batch processing mode where there are no listeners. the
> commands are only used for graphical editing. so it seemed "obvious" to
> put the notifications in the command.
I've always seen commands as part of the model. Manipulating the model, and
ignorant of the UI. That way they're only dependent on the model's
minimalistic interface (I say minimalistic because it won't be polluted by
methods like fireNotification()). This is one of the many reasons your
approach is a poor one.
I think what you want is something to wrap the actual model objects. That
something can provide the notifcation mechanism. Maybe it'll become your
view model and can store graphical information that your business model
doesn't really care about (location, size, etc.)
>
> and it's parsimonious. all model changes in graphical editing are being
> made through the commands anyway. and the commands have a coarser
> grained picture of the model changes and so can minimize the number of
> notifications. in that sense it seemed quite reasonable. but i recognize
> that this may be a matter of personal taste.
Everything's a trade-off in software design. The miniscule performance (and
increased complexity) that you're trading off the modifiability, cohesion
and reduced coupling (that our recommended approach presents) for is not
worth it.
>
> and with the alternative design that i proposed in the other thread,
> i.e. listeners in the model, but notification from the command, i can
> use most of the standard GEF idiom for "hooking" / "unhooking". so the
> initial cost of doing things this way is quite low.
>
> do you see a problem with doing things this way? any concrete downside?
>
> regards,
>
> al
|
|
|
| Re: model change notification from commands [message #171557 is a reply to message #171540] |
Mon, 14 March 2005 05:29 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
>>>>
>>>>
>>>> Like what? I don't think this is a reasonable way to proceed.
>>>>
>>>>
>>>
>>> batching notifications for compound commands for one (to minimize the
>>> number of display refreshes). the fire from set-method is, in general,
>>> quite fine grained.
>>
>>
>>
>> The display refreshes just once when all the commands in the
>> CompoundCommand
>> have executed and all the notification has been fired.
>>
>>
> is that so? that's clever! i'll go look at the code and see what's
> going on.
>
> there's a less concrete justification: in my app it seems like a
> cleaner design. the model is used not only for graphical editing, but
> also in a batch processing mode where there are no listeners. the
> commands are only used for graphical editing. so it seemed "obvious" to
> put the notifications in the command.
>
> and it's parsimonious. all model changes in graphical editing are
> being made through the commands anyway. and the commands have a coarser
> grained picture of the model changes and so can minimize the number of
> notifications. in that sense it seemed quite reasonable. but i recognize
> that this may be a matter of personal taste.
>
> and with the alternative design that i proposed in the other thread,
> i.e. listeners in the model, but notification from the command, i can
> use most of the standard GEF idiom for "hooking" / "unhooking". so the
> initial cost of doing things this way is quite low.
>
> do you see a problem with doing things this way? any concrete downside?
>
> regards,
>
> al
You would only be able to use your models from within the commands. If
one model tries to modify another, you will have an issue. Its more
flexible to have the models handle things that have to do with the
models like notificaiton of change. Besides, I may setLocaiton(0,0) and
my model may already be at 0,0,and thus wont fire an event. A command
would have harder time doing that.
CL
|
|
|
| Re: model change notification from commands [message #171580 is a reply to message #171557] |
Mon, 14 March 2005 06:34 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
>
> You would only be able to use your models from within the commands. If
> one model tries to modify another, you will have an issue. Its more
this is not an issue in my design.
> flexible to have the models handle things that have to do with the
> models like notificaiton of change. Besides, I may setLocaiton(0,0) and
> my model may already be at 0,0,and thus wont fire an event. A command
> would have harder time doing that.
>
hmm. that's worth thinking about. thanks.
regards,
al
|
|
|
| Re: model change notification from commands [message #171588 is a reply to message #171550] |
Mon, 14 March 2005 06:47 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
>>is that so? that's clever! i'll go look at the code and see what's
>>going on.
>
>
> You won't find it in GEF. It's in Draw2d. It uses a DeferredUpdateManager
> that queues painting on the display thread, and hence first waits for
> whatever's on that thread to finish executing.
>
thanks for the pointer. how much control does one have on when that
happens?
>
>>there's a less concrete justification: in my app it seems like a
>>cleaner design. the model is used not only for graphical editing, but
>>also in a batch processing mode where there are no listeners. the
>>commands are only used for graphical editing. so it seemed "obvious" to
>>put the notifications in the command.
>
>
> I've always seen commands as part of the model. Manipulating the model, and
> ignorant of the UI. That way they're only dependent on the model's
> minimalistic interface (I say minimalistic because it won't be polluted by
> methods like fireNotification()). This is one of the many reasons your
> approach is a poor one.
>
the commands in GEF are supposed to be relatively ignorant of the UI.
is that not so? at least the way that i'm using them they are. at some
point i imagine they're going into a platform commandstack, so i dont'
want any GEF dependencies if i can help it. i'm not advocating
otherwise. but the commands perform model interactions that are specific
to interactive access.
> I think what you want is something to wrap the actual model objects. That
> something can provide the notifcation mechanism. Maybe it'll become your
> view model and can store graphical information that your business model
> doesn't really care about (location, size, etc.)
>
the way i'm advocating using commands is sort of view specific model
mutators. they can probably be viewed as part of the "view model" in
that sense.
>
> Everything's a trade-off in software design. The miniscule performance (and
> increased complexity) that you're trading off the modifiability, cohesion
> and reduced coupling (that our recommended approach presents) for is not
> worth it.
>
hmm. we appear to have a difference of opinion. i see it as a decrease
in complexity, and a more reasonable separation of concerns. i guess
i'll find out as the complete implentation proceeds. if it turns out
that modifiability, cohesion and reduced coupling are sacrificed (which
they don't currently appear to me to be), i will, of course, change my mind.
incidentally, i've been browsing through some of the larger codebases
that use GEF. the BIRT project has a model in which the "transactions"
are firing off the notifications. they're not GEF "commands" per se, but
the usage is similar to the way that i'm using commands. if you have the
time to look at it i'd appreciate your comments and any critique you may
have about that approach.
are there any other specific objections that you have to this approach?
btw, i appreciate your effort in answering what are somewhat "big
picture" questions.
regards,
al
|
|
|
| Re: model change notification from commands [message #171674 is a reply to message #171588] |
Mon, 14 March 2005 17:34 |
Pratik Shah
Messages: 1077
Registered: July 2009 |
Senior Member |
|
|
GEF will move to the platform's operation framework too (although not for
the 3.1 release).
Here's a quick run-down of some problems I find with your approach --
- CompoundCommand will have to figure out whom to notify -- ask all the
child Commands -- and do some batch notification. Hence, added
responsibility for commands and increased complexity
- duplication of code in several places - if more than one command calls
setXYZ() on a model, they're responsible for notifying its listeners as
well; and if somebody else invokes those methods (such as property sources
for the property sheet), they have to do the same
- littered model interface
- violating encapsulation by providing access to what should be internal to
the model -- the listeners (reduced cohesion and increased coupling stem
from this)
This is my last post on this topic. I hope you'll make the right choice.
"Al Major" <alnospammajor@noboxspamspoon.com> wrote in message
news:d13c2f$tvk$1@www.eclipse.org...
> >>is that so? that's clever! i'll go look at the code and see what's
> >>going on.
> >
> >
> > You won't find it in GEF. It's in Draw2d. It uses a
DeferredUpdateManager
> > that queues painting on the display thread, and hence first waits for
> > whatever's on that thread to finish executing.
> >
> thanks for the pointer. how much control does one have on when that
> happens?
>
> >
> >>there's a less concrete justification: in my app it seems like a
> >>cleaner design. the model is used not only for graphical editing, but
> >>also in a batch processing mode where there are no listeners. the
> >>commands are only used for graphical editing. so it seemed "obvious" to
> >>put the notifications in the command.
> >
> >
> > I've always seen commands as part of the model. Manipulating the model,
and
> > ignorant of the UI. That way they're only dependent on the model's
> > minimalistic interface (I say minimalistic because it won't be polluted
by
> > methods like fireNotification()). This is one of the many reasons your
> > approach is a poor one.
> >
> the commands in GEF are supposed to be relatively ignorant of the UI.
> is that not so? at least the way that i'm using them they are. at some
> point i imagine they're going into a platform commandstack, so i dont'
> want any GEF dependencies if i can help it. i'm not advocating
> otherwise. but the commands perform model interactions that are specific
> to interactive access.
>
> > I think what you want is something to wrap the actual model objects.
That
> > something can provide the notifcation mechanism. Maybe it'll become
your
> > view model and can store graphical information that your business model
> > doesn't really care about (location, size, etc.)
> >
> the way i'm advocating using commands is sort of view specific model
> mutators. they can probably be viewed as part of the "view model" in
> that sense.
>
> >
> > Everything's a trade-off in software design. The miniscule performance
(and
> > increased complexity) that you're trading off the modifiability,
cohesion
> > and reduced coupling (that our recommended approach presents) for is not
> > worth it.
> >
> hmm. we appear to have a difference of opinion. i see it as a decrease
> in complexity, and a more reasonable separation of concerns. i guess
> i'll find out as the complete implentation proceeds. if it turns out
> that modifiability, cohesion and reduced coupling are sacrificed (which
> they don't currently appear to me to be), i will, of course, change my
mind.
>
> incidentally, i've been browsing through some of the larger codebases
> that use GEF. the BIRT project has a model in which the "transactions"
> are firing off the notifications. they're not GEF "commands" per se, but
> the usage is similar to the way that i'm using commands. if you have the
> time to look at it i'd appreciate your comments and any critique you may
> have about that approach.
>
> are there any other specific objections that you have to this approach?
>
> btw, i appreciate your effort in answering what are somewhat "big
> picture" questions.
>
> regards,
>
> al
|
|
|
| Re: model change notification from commands [message #171714 is a reply to message #171580] |
Mon, 14 March 2005 18:27 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
>>
>> You would only be able to use your models from within the commands.
>> If one model tries to modify another, you will have an issue. Its more
>
>
> this is not an issue in my design.
I understand. You will find lots of these types of things in GEF. But
GEF is a library and has to please a lot of different people so its more
general. Sometimes this is less efficient for one application or
another. But it gets the job done in the end. And of course sometimes
it needs to be changed to need the needs of a different application no
one thought about yet.
>
>> flexible to have the models handle things that have to do with the
>> models like notificaiton of change. Besides, I may setLocaiton(0,0)
>> and my model may already be at 0,0,and thus wont fire an event. A
>> command would have harder time doing that.
>>
> hmm. that's worth thinking about. thanks.
>
> regards,
>
> al
|
|
| |
| Re: model change notification from commands [message #171807 is a reply to message #171674] |
Tue, 15 March 2005 06:46 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
thank you for your comments. i'll definitely keep these in mind.
looking back over my previous posts, i realize i've set the wrong tone,
completely unintentionally. it sounds like i disagree with the
notification design decisions in the GEF samples.
i don't. i think the decisions make complete sense in the context of a
model that has been designed from the ground up with GEF in mind.
i'm in a different situation, with an existing model into which
graphical editing is being retrofitted. i want to make minimal changes
to the existing code base. in _this_ context, making the changes
initially in the commands results in the minimum perturbation of
existing code. it is parsimonious.
i apologize for not making this context more clear.
indeed, it's quite possible that eventually the command code will be
refactored into a "view model" as you suggest. but that's for a later
stage in the game.
overall, i think GEF is an excellent library with good design decisions.
the samples are very comprehensive in illustrating how to write GEF code.
it's a measure of how _good_ (successful) the GEF design is, that it's
now being used on pre-existing (non GEF) models. in this process it is
inevitable that people will come up with idioms and design variations
that make sense in their particular context. this is not in itself a bad
thing. nor does it invalidate the decisions made in the sample code.
it's just an acknowledgement of the reality that there is no such thing
as a one size fits all design.
and comments on the cons of particular designs from knowledgeable users
are very valuable. thus i truly appreciate your and CL's feedback.
sorry for going meta-topic, but i think these are points worth making.
and i do want to make clear that i think quite highly of the GEF samples
in particular and the library in general. and of course of the guys that
wrote that code ;-).
regards,
al
Pratik Shah wrote:
> GEF will move to the platform's operation framework too (although not for
> the 3.1 release).
>
> Here's a quick run-down of some problems I find with your approach --
>
> - CompoundCommand will have to figure out whom to notify -- ask all the
> child Commands -- and do some batch notification. Hence, added
> responsibility for commands and increased complexity
> - duplication of code in several places - if more than one command calls
> setXYZ() on a model, they're responsible for notifying its listeners as
> well; and if somebody else invokes those methods (such as property sources
> for the property sheet), they have to do the same
> - littered model interface
> - violating encapsulation by providing access to what should be internal to
> the model -- the listeners (reduced cohesion and increased coupling stem
> from this)
>
> This is my last post on this topic. I hope you'll make the right choice.
>
> "Al Major" <alnospammajor@noboxspamspoon.com> wrote in message
> news:d13c2f$tvk$1@www.eclipse.org...
>
>>>>is that so? that's clever! i'll go look at the code and see what's
>>>>going on.
>>>
>>>
>>>You won't find it in GEF. It's in Draw2d. It uses a
>
> DeferredUpdateManager
>
>>>that queues painting on the display thread, and hence first waits for
>>>whatever's on that thread to finish executing.
>>>
>>
>>thanks for the pointer. how much control does one have on when that
>>happens?
>>
>>
>>>>there's a less concrete justification: in my app it seems like a
>>>>cleaner design. the model is used not only for graphical editing, but
>>>>also in a batch processing mode where there are no listeners. the
>>>>commands are only used for graphical editing. so it seemed "obvious" to
>>>>put the notifications in the command.
>>>
>>>
>>>I've always seen commands as part of the model. Manipulating the model,
>
> and
>
>>>ignorant of the UI. That way they're only dependent on the model's
>>>minimalistic interface (I say minimalistic because it won't be polluted
>
> by
>
>>>methods like fireNotification()). This is one of the many reasons your
>>>approach is a poor one.
>>>
>>
>>the commands in GEF are supposed to be relatively ignorant of the UI.
>>is that not so? at least the way that i'm using them they are. at some
>>point i imagine they're going into a platform commandstack, so i dont'
>>want any GEF dependencies if i can help it. i'm not advocating
>>otherwise. but the commands perform model interactions that are specific
>>to interactive access.
>>
>>
>>>I think what you want is something to wrap the actual model objects.
>
> That
>
>>>something can provide the notifcation mechanism. Maybe it'll become
>
> your
>
>>>view model and can store graphical information that your business model
>>>doesn't really care about (location, size, etc.)
>>>
>>
>>the way i'm advocating using commands is sort of view specific model
>>mutators. they can probably be viewed as part of the "view model" in
>>that sense.
>>
>>
>>>Everything's a trade-off in software design. The miniscule performance
>
> (and
>
>>>increased complexity) that you're trading off the modifiability,
>
> cohesion
>
>>>and reduced coupling (that our recommended approach presents) for is not
>>>worth it.
>>>
>>
>>hmm. we appear to have a difference of opinion. i see it as a decrease
>>in complexity, and a more reasonable separation of concerns. i guess
>>i'll find out as the complete implentation proceeds. if it turns out
>>that modifiability, cohesion and reduced coupling are sacrificed (which
>>they don't currently appear to me to be), i will, of course, change my
>
> mind.
>
>>incidentally, i've been browsing through some of the larger codebases
>>that use GEF. the BIRT project has a model in which the "transactions"
>>are firing off the notifications. they're not GEF "commands" per se, but
>>the usage is similar to the way that i'm using commands. if you have the
>>time to look at it i'd appreciate your comments and any critique you may
>>have about that approach.
>>
>>are there any other specific objections that you have to this approach?
>>
>>btw, i appreciate your effort in answering what are somewhat "big
>>picture" questions.
>>
>>regards,
>>
>>al
>
>
>
|
|
|
| Re: model change notification from commands [message #171847 is a reply to message #171807] |
Tue, 15 March 2005 14:25 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
> thank you for your comments. i'll definitely keep these in mind.
>
> looking back over my previous posts, i realize i've set the wrong tone,
> completely unintentionally. it sounds like i disagree with the
> notification design decisions in the GEF samples.
>
> i don't. i think the decisions make complete sense in the context of a
> model that has been designed from the ground up with GEF in mind.
>
> i'm in a different situation, with an existing model into which
> graphical editing is being retrofitted. i want to make minimal changes
> to the existing code base. in _this_ context, making the changes
> initially in the commands results in the minimum perturbation of
> existing code. it is parsimonious.
>
> i apologize for not making this context more clear.
>
> indeed, it's quite possible that eventually the command code will be
> refactored into a "view model" as you suggest. but that's for a later
> stage in the game.
>
If this is the case, then your best bet is to wrap your existing models
with a class that handles firing the events. Then you won't have to
refactor you commands when eventually the models handle notification
natively.
Its not so bad an idea that each tool that would use your models would
need such a wrapper/adapter class. In this way you can let gEF stick to
the GEF architecture, and your models stick to their architecture. Let
the adapter bridge the gap.
> overall, i think GEF is an excellent library with good design decisions.
> the samples are very comprehensive in illustrating how to write GEF code.
>
> it's a measure of how _good_ (successful) the GEF design is, that it's
> now being used on pre-existing (non GEF) models. in this process it is
> inevitable that people will come up with idioms and design variations
> that make sense in their particular context. this is not in itself a bad
> thing. nor does it invalidate the decisions made in the sample code.
> it's just an acknowledgement of the reality that there is no such thing
> as a one size fits all design.
>
there should be no such thing as a 'GEF' model. As I said in the other
thread, my models have no knowledge of anything but pure java classes,
no eclipse/swt/gef classes whatsoever. And My models were preexisting.
There was one change i made to my models to satisfy GEF, but you are
not having a similar issue at this point.
> and comments on the cons of particular designs from knowledgeable users
> are very valuable. thus i truly appreciate your and CL's feedback.
>
> sorry for going meta-topic, but i think these are points worth making.
> and i do want to make clear that i think quite highly of the GEF samples
> in particular and the library in general. and of course of the guys that
> wrote that code ;-).
I think the wrapper is your best bet. You want to stay as close to the
GEF architecture as you can so you can take advantage of new GEF
features when they are added. I will soon be adding support for snaps
and rulers to my editors soon. I'm hoping for an easy transition as I
have stuck closely to the Gef model.
CL
|
|
|
| Re: model change notification from commands [message #171863 is a reply to message #171674] |
Tue, 15 March 2005 16:06 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> GEF will move to the platform's operation framework too (although not for
> the 3.1 release).
This actually needs to be weighed against the amount of API breakage that
would occur. We still need to investigate this since the platform API is
not finalized.
|
|
|
| Re: model change notification from commands [message #171871 is a reply to message #171404] |
Tue, 15 March 2005 16:11 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Batching model changes is possible. The batching would be done by your
model implementation or a mediator.
Using a single "domain" notifier is also doable. The EditPartRegistry
provides the necessary model->part mapping to dispatch the model changes.
Turning off non-graphical UI updating (such as TreeItem construction) is
possible to. Use SWT's setRedraw(false), and hook into the new command
stack events which tell you whenever something is starting to happen and
when it is completed.
|
|
|
| Re: model change notification from commands [message #172048 is a reply to message #171847] |
Wed, 16 March 2005 03:26 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
>>
>
> If this is the case, then your best bet is to wrap your existing models
> with a class that handles firing the events. Then you won't have to
> refactor you commands when eventually the models handle notification
> natively.
>
> Its not so bad an idea that each tool that would use your models would
> need such a wrapper/adapter class. In this way you can let gEF stick to
> the GEF architecture, and your models stick to their architecture. Let
> the adapter bridge the gap.
>
are you suggesting that for each class in my model i have a delegating
class with identical interface that delegates every single method to the
main class? and a few of the methods fire notifications as well?
basically create a delegating mirror of the entire model hierarchy?
|
|
|
| Re: model change notification from commands [message #172100 is a reply to message #172048] |
Wed, 16 March 2005 14:04 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
>>>
>>
>> If this is the case, then your best bet is to wrap your existing
>> models with a class that handles firing the events. Then you won't
>> have to refactor you commands when eventually the models handle
>> notification natively.
>>
>> Its not so bad an idea that each tool that would use your models would
>> need such a wrapper/adapter class. In this way you can let gEF stick
>> to the GEF architecture, and your models stick to their architecture.
>> Let the adapter bridge the gap.
>>
>
> are you suggesting that for each class in my model i have a
> delegating class with identical interface that delegates every single
> method to the main class? and a few of the methods fire notifications as
> well? basically create a delegating mirror of the entire model hierarchy?
Yes, but a wrapper should be sufficient. You shouldn't need a proper
delegate, since the events are firing by the wrapper and not the wrapee.
Allows all your changes to be within a single class, instead of changing
GEF a bit and changing your models a bit.
CL
|
|
|
| Re: model change notification from commands [message #172210 is a reply to message #172100] |
Thu, 17 March 2005 00:35 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
CL [dnoyeb] Gilbert wrote:
>
> Yes, but a wrapper should be sufficient. You shouldn't need a proper
> delegate, since the events are firing by the wrapper and not the wrapee.
>
> Allows all your changes to be within a single class, instead of changing
> GEF a bit and changing your models a bit.
>
i'm still not sure i understand. if i have a model hierarchy
class A {
public void a ()
...
}
class B extends A {
public void b ()
}
class C extends A {
public void c ()
}
the wrapper is
class Wrapper {
public void modifyA (A obj) {
obj.a ();
obj.fire ();
}
public void modifyB (B obj) {
obj.b ();
obj.fire ();
}
public void modifyC (C obj) {
obj.c ();
obj.fire ();
}
}
is this what you mean? if not, could you provide some pseudocode to clarify?
regards,
al
|
|
|
| Re: model change notification from commands [message #172218 is a reply to message #171871] |
Thu, 17 March 2005 00:36 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
Randy Hudson wrote:
> Batching model changes is possible. The batching would be done by your
> model implementation or a mediator.
>
> Using a single "domain" notifier is also doable. The EditPartRegistry
> provides the necessary model->part mapping to dispatch the model changes.
>
> Turning off non-graphical UI updating (such as TreeItem construction) is
> possible to. Use SWT's setRedraw(false), and hook into the new command
> stack events which tell you whenever something is starting to happen and
> when it is completed.
>
>
thanks!
|
|
|
Goto Forum:
Current Time: Fri Apr 19 04:50:46 GMT 2024
Powered by FUDForum. Page generated in 0.03069 seconds |
] 
Search
Help
Register
Login
Home
