Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EditingDomainActionBarContributor
EditingDomainActionBarContributor [message #418989] Wed, 07 May 2008 13:29 Go to next message
Eric Rizzo is currently offline Eric RizzoFriend
Messages: 3070
Registered: July 2009
Senior Member
In looking at the implementation of
org.eclipse.gmf.ecore.part.EcoreDiagramActionBarContributor (I need a
similar but smaller contributor for my forms-based editors), I noticed
that the contributor adds itself as a property listener on the active
IEditorPart (it responds to property change events by calling update()
to enable/disable the actions, etc.)
I'm presuming it does this so that it is notified when the editor has
gone dirty. But it seems to me that it would be more appropriate for the
contributor to be a listener on the CommandStack. Any thoughts?

Eric
Re: EditingDomainActionBarContributor [message #418990 is a reply to message #418989] Wed, 07 May 2008 13:30 Go to previous messageGo to next message
Eric Rizzo is currently offline Eric RizzoFriend
Messages: 3070
Registered: July 2009
Senior Member
Sorry, this relates to
org.eclipse.emf.edit.ui.action.EditingDomainActionBarContrib utor, NOT
the GMF contributor.

Sorry for the confusion.

Eric Rizzo wrote:
> In looking at the implementation of
> org.eclipse.gmf.ecore.part.EcoreDiagramActionBarContributor (I need a
> similar but smaller contributor for my forms-based editors), I noticed
> that the contributor adds itself as a property listener on the active
> IEditorPart (it responds to property change events by calling update()
> to enable/disable the actions, etc.)
> I'm presuming it does this so that it is notified when the editor has
> gone dirty. But it seems to me that it would be more appropriate for the
> contributor to be a listener on the CommandStack. Any thoughts?
>
> Eric
Re: EditingDomainActionBarContributor [message #418995 is a reply to message #418989] Wed, 07 May 2008 14:32 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33141
Registered: July 2009
Senior Member
Eric,

Well, the command stack listener fires the property change to tell the
editor to check the dirty state after each command is executed and the
contributor is using that to update itself as well...


Eric Rizzo wrote:
> In looking at the implementation of
> org.eclipse.gmf.ecore.part.EcoreDiagramActionBarContributor (I need a
> similar but smaller contributor for my forms-based editors), I noticed
> that the contributor adds itself as a property listener on the active
> IEditorPart (it responds to property change events by calling update()
> to enable/disable the actions, etc.)
> I'm presuming it does this so that it is notified when the editor has
> gone dirty. But it seems to me that it would be more appropriate for
> the contributor to be a listener on the CommandStack. Any thoughts?
>
> Eric


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EditingDomainActionBarContributor [message #419005 is a reply to message #418995] Wed, 07 May 2008 20:31 Go to previous messageGo to next message
Eric Rizzo is currently offline Eric RizzoFriend
Messages: 3070
Registered: July 2009
Senior Member
Ed Merks wrote:
> Eric,
>
> Well, the command stack listener fires the property change to tell the
> editor to check the dirty state after each command is executed and the
> contributor is using that to update itself as well...

I'm not talking about the generated editors; I'm talking about a
hand-written editor that wants to use either
EditingDomainActionBarContributor or something closely derived from it.
If I read it correctly, the code in EditingDomainActionBarContributor
assumes the editor will register a CommandStackListener that does
firePropertyChange(PROP_DIRTY) whenever the command stack changes. While
it does work in that case, it seems to be a lot of assuming on the part
of the contributor, no?

Since I'm writing my own contributor (based on
EditingDomainActionBarContributor ) I'm just wondering if it wouldn't be
better (more reliable, less assumptive) for it to listen to the command
stack directly.

Eric


> Eric Rizzo wrote:
>> In looking at the implementation of
>> org.eclipse.gmf.ecore.part.EcoreDiagramActionBarContributor (I need a
>> similar but smaller contributor for my forms-based editors), I noticed
>> that the contributor adds itself as a property listener on the active
>> IEditorPart (it responds to property change events by calling update()
>> to enable/disable the actions, etc.)
>> I'm presuming it does this so that it is notified when the editor has
>> gone dirty. But it seems to me that it would be more appropriate for
>> the contributor to be a listener on the CommandStack. Any thoughts?
>>
>> Eric
Re: EditingDomainActionBarContributor [message #419007 is a reply to message #419005] Wed, 07 May 2008 21:04 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33141
Registered: July 2009
Senior Member
Eric,

It does seem somewhat indirect in hindsight, but it has always proven
reliable to date. I imagine that editors do always need to check
dirtiness after a command is executed...


Eric Rizzo wrote:
> Ed Merks wrote:
>> Eric,
>>
>> Well, the command stack listener fires the property change to tell
>> the editor to check the dirty state after each command is executed
>> and the contributor is using that to update itself as well...
>
> I'm not talking about the generated editors; I'm talking about a
> hand-written editor that wants to use either
> EditingDomainActionBarContributor or something closely derived from
> it. If I read it correctly, the code in
> EditingDomainActionBarContributor assumes the editor will register a
> CommandStackListener that does firePropertyChange(PROP_DIRTY) whenever
> the command stack changes. While it does work in that case, it seems
> to be a lot of assuming on the part of the contributor, no?
>
> Since I'm writing my own contributor (based on
> EditingDomainActionBarContributor ) I'm just wondering if it wouldn't
> be better (more reliable, less assumptive) for it to listen to the
> command stack directly.
>
> Eric
>
>
>> Eric Rizzo wrote:
>>> In looking at the implementation of
>>> org.eclipse.gmf.ecore.part.EcoreDiagramActionBarContributor (I need
>>> a similar but smaller contributor for my forms-based editors), I
>>> noticed that the contributor adds itself as a property listener on
>>> the active IEditorPart (it responds to property change events by
>>> calling update() to enable/disable the actions, etc.)
>>> I'm presuming it does this so that it is notified when the editor
>>> has gone dirty. But it seems to me that it would be more appropriate
>>> for the contributor to be a listener on the CommandStack. Any thoughts?
>>>
>>> Eric


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:AdapterFactoryLabelProvider, GMF and memory leak
Next Topic:Custom serialization of my model
Goto Forum:
  


Current Time: Fri Apr 26 05:03:46 GMT 2024

Powered by FUDForum. Page generated in 0.03824 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top