Eclipse Community Forums: GEF » Properties view changes and EditPart

Home » Eclipse Projects » GEF » Properties view changes and EditPart

Properties view changes and EditPart [message #143195]

Mon, 19 July 2004 04:36

Eclipse User

Originally posted by: mastr.arcor.de

Hey!

I use Eclipse and GEF 2.1.3. I have a MultiPageEditor with a GEF- and a
TextEditor.
I have some EditParts (extend AbractGraphicalEditPart) which are created
by an EditPartFactory. Each EditPart has a corresponding IPropertySource
which is set by getAdapter() method in the EditPart class. The
XYZProperties class has a reference to the EditPart's model.

private IPropertySource properties;

public Object getAdapter(Class key) {
if(key == IPropertySource.class) {
if(properties == null)
properties = new XYZProperties(getXYZModel());
return properties;
}
return super.getAdapter(key);
}

The XYZProperties class is build after the "Take control on my properties"
article.
Now, my question:

How do I get the changes on the model (made in the Properties view) and
set the Editors dirty state?

Do I have to specify a special policy to the EditPart?
I'm missing the logical connection between PropertySource (my
XYZProperties class) and my EditPart.

Please help.
Thanks so far, Martin.

Re: Properties view changes and EditPart [message #143261 is a reply to message #143195]

Mon, 19 July 2004 08:04

Eclipse User

Originally posted by: g.wagenknecht.planet-wagenknecht.de

Martin S. wrote:
> How do I get the changes on the model (made in the Properties view)
> and set the Editors dirty state?

Your editor is responsible for this. Your editor need to provide a
_modified_ IPropertySheetPage (see GraphicalEditor#getAdapter). This allows
wrapping of property changes into commands. Any property change will be
executed as command on the command stack. Your editor just listens to the
command stack as usual and will be dirty whenever your command stack is
dirty.

However this concepts with wrapping the property changes into commands is
limited if you also have some views showing the same model elements. I had
to "implement a workaround" in MyViewPart#getAdapter which checks for an
open editor to get a "correct" IPropertySheetPage .. but it works.

> I'm missing the logical connection between PropertySource (my
> XYZProperties class) and my EditPart.

There is no "logical" connection. You should think of both as controlers for
different views to your models.

public class MyModel {
public Object getAdapter(Class type) {
if( class == IPropertySource.class )
return new MyModelPropertySource(this);
if( class == EditPart.class )
return new MyModelEditPart(this);
return null;
}
}

Then your EditPartFactory would just check for
IAdaptable#getAdaper(EditPart.class). BTW, this ist just an implementation
issue.

Cu, Gunnar

Re: Properties view changes and EditPart [message #143289 is a reply to message #143195]

Mon, 19 July 2004 09:49

Eclipse User

Originally posted by: News.Karsten-Becker.de

Hi,
I made my Models implementing IAdaptable and IPropertySource2. And
everytime setPropertyValue is called I create a PropertyChangeCommand.
It works, but I currently don't know why ;-)

Karsten

Re: Properties view changes and EditPart [message #143478 is a reply to message #143289]

Tue, 20 July 2004 00:44

Eclipse User

Originally posted by: g.wagenknecht.planet-wagenknecht.de

Karsten,

Karsten Becker wrote:
> I made my Models implementing IAdaptable and IPropertySource2. And
> everytime setPropertyValue is called I create a PropertyChangeCommand.
> It works, but I currently don't know why ;-)

This is because your editor adapts to IPropertySheetPage. Actually, the
GraphicalEditor does it.

Cu, Gunnar

Re: Properties view changes and EditPart [message #143506 is a reply to message #143261]

Tue, 20 July 2004 04:40

Eclipse User

Originally posted by: mastr.arcor.de

Thanks Gunnar,
but one question left...

> There is no "logical" connection. You should think of both as controlers for
> different views to your models.

> public class MyModel {
> public Object getAdapter(Class type) {
> if( class == IPropertySource.class )
> return new MyModelPropertySource(this);
> if( class == EditPart.class )
> return new MyModelEditPart(this);
> return null;
> }
> }

> Then your EditPartFactory would just check for
> IAdaptable#getAdaper(EditPart.class). BTW, this ist just an implementation
> issue.

In my GraphicalEditor's method createGraphicalViewer() I set
MyEditPartFactory to the viewer. This factory class has one method to
overwrite where I check the type of class. Then I return the EditPart
belonging to the specific Model.

Now, what do I have to do in MyEditPartFactory if I choose your given
solution by adapting the Model class?
Do I already need MyEditPartFactory class?
What would be a sample code for "checking IAdaptable#getAdapter" ?

Thanks in advance, Martin.

Re: Properties view changes and EditPart [message #143526 is a reply to message #143506]

Tue, 20 July 2004 05:56

Eclipse User

Originally posted by: g.wagenknecht.planet-wagenknecht.de

Martin S. wrote:
> What would be a sample code for "checking IAdaptable#getAdapter" ?

Well, it depends on your requirement to the "context" provided in
EditPartFactory#createEditPart. We don't have a requirement for this but it
would allow creating different type of EditParts for the same model object.

The simplest implementation would be:

if(modelObject instanceof IAdaptable) {
return (EditPart) ((IAdaptable)modelObject).getAdapter(EditPart.class);
}

Be aware that you have to add additional API if you're using the
EditPartFactory for TreeEditParts (e.g. in the Outline view). It depends on
the way you'd like to go. We don't use TreeEditParts in the Outline view
because we reuse our existing code (Eclipse JFace viewers).

But the IAdaptable consept has other advantages like contributing adapters
via adapter factories through other plug-ins.

Cu, Gunnar

Previous Topic:	GEF and RCP application Help
Next Topic:	Location Translation

Goto Forum:

-=] Back to Top [=-

Current Time: Fri Nov 07 22:13:35 EST 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter