Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Compare] Name similarity/Label provider
| |
Re: [EMF Compare] Name similarity/Label provider [message #120353 is a reply to message #120328] |
Mon, 28 April 2008 14:23 |
David Michonneau Messages: 85 Registered: July 2009 |
Member |
|
|
Hi Cedric,
In fact I was referring to this code in the Edit provider of the diff
metamodel:
/**
* This returns the label text for the adapted class. <!--
begin-user-doc --> <!-- end-user-doc -->
*
* @generated NOT
*/
@Override
public String getText(Object object) {
DiffGroup group = (DiffGroup)object;
if (group.getLeftParent() != null) {
try {
return getString("_UI_DiffGroup_type", new Object[]
{group.getSubchanges(), //$NON-NLS-1$
group.getLeftParent().eClass().getName() + " ", //$NON-NLS-1$
NameSimilarity.findName(group.getLeftParent())});
} catch (FactoryException e) {
return getString("_UI_DiffGroup_type", new Object[]
{group.getSubchanges(), //$NON-NLS-1$
group.getLeftParent().eClass().getName(), " model"}); //$NON-NLS-1$
}
}
return getString("_UI_DiffGroup_type", new Object[]
{group.getSubchanges(), "", " model"}); //$NON-NLS-1$ //$NON-NLS-2$
//$NON-NLS-3$
}
I am not sure the patch in bugzilla would solve that problem, since it still
refers in the end to this text provider. My problem is with
group.getLeftParent().eClass().getName() and NameSimilarity.findName(),
could we replace it by something like:
IItemLabelProvider itemLabelProvider = (IItemLabelProvider) AdapterUtils
.getAdapterFactory().adapt(group.getLeftParent(),
IItemLabelProvider.class);
String label =
itemLabelProvider.getText(group.getLeftParent());
return getString(
"_UI_DiffGroup_type", new Object[] {
group.getSubchanges(), //$NON-NLS-1$
label, "" });
So it would use the item provider of the model being compared to display the
string, instead of using the classname+the feature the most likely to be the
name.
Thanks,
David
"C
|
|
|
Re: [EMF Compare] Name similarity/Label provider [message #120407 is a reply to message #120353] |
Mon, 28 April 2008 15:02 |
|
This is a multi-part message in MIME format.
--------------020605050501080409080206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
David,
Indeed this seems like something that would be less error-prone (and
faster?). Can you fill in a bugzilla for this with the sample you
provided? We'll look into it ASAP.
Laurent Goubet
Obeo
David Michonneau a
|
|
| |
Re: [EMF Compare] Name similarity/Label provider [message #617931 is a reply to message #120311] |
Mon, 28 April 2008 12:46 |
Cedric Brun Messages: 431 Registered: July 2009 |
Senior Member |
|
|
Hi David,
in fact this request has already been made and a patch is waiting for
inclusion in the bugzilla :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=199248
It will be considered during the week and should probably be part of the
next build.
regards,
Cédric
David Michonneau wrote:
> Hi,
>
> Why in the Diff model label providers, the code refers to
> NameSimilarity.findName() API to find the name of an EObject, instead of
> using the registered text providers for that EObject in the EMF Edit
> global registry? This prevents to customize the labels in any UI referring
> to the Diff Edit providers. Or maybe the NameSimilarity should provide an
> extension for custom implementation?
>
> Thanks,
>
> David
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
Re: [EMF Compare] Name similarity/Label provider [message #617933 is a reply to message #120328] |
Mon, 28 April 2008 14:23 |
David Michonneau Messages: 85 Registered: July 2009 |
Member |
|
|
Hi Cedric,
In fact I was referring to this code in the Edit provider of the diff
metamodel:
/**
* This returns the label text for the adapted class. <!--
begin-user-doc --> <!-- end-user-doc -->
*
* @generated NOT
*/
@Override
public String getText(Object object) {
DiffGroup group = (DiffGroup)object;
if (group.getLeftParent() != null) {
try {
return getString("_UI_DiffGroup_type", new Object[]
{group.getSubchanges(), //$NON-NLS-1$
group.getLeftParent().eClass().getName() + " ", //$NON-NLS-1$
NameSimilarity.findName(group.getLeftParent())});
} catch (FactoryException e) {
return getString("_UI_DiffGroup_type", new Object[]
{group.getSubchanges(), //$NON-NLS-1$
group.getLeftParent().eClass().getName(), " model"}); //$NON-NLS-1$
}
}
return getString("_UI_DiffGroup_type", new Object[]
{group.getSubchanges(), "", " model"}); //$NON-NLS-1$ //$NON-NLS-2$
//$NON-NLS-3$
}
I am not sure the patch in bugzilla would solve that problem, since it still
refers in the end to this text provider. My problem is with
group.getLeftParent().eClass().getName() and NameSimilarity.findName(),
could we replace it by something like:
IItemLabelProvider itemLabelProvider = (IItemLabelProvider) AdapterUtils
.getAdapterFactory().adapt(group.getLeftParent(),
IItemLabelProvider.class);
String label =
itemLabelProvider.getText(group.getLeftParent());
return getString(
"_UI_DiffGroup_type", new Object[] {
group.getSubchanges(), //$NON-NLS-1$
label, "" });
So it would use the item provider of the model being compared to display the
string, instead of using the classname+the feature the most likely to be the
name.
Thanks,
David
"C
|
|
|
Re: [EMF Compare] Name similarity/Label provider [message #617937 is a reply to message #120353] |
Mon, 28 April 2008 15:02 |
|
This is a multi-part message in MIME format.
--------------020605050501080409080206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
David,
Indeed this seems like something that would be less error-prone (and
faster?). Can you fill in a bugzilla for this with the sample you
provided? We'll look into it ASAP.
Laurent Goubet
Obeo
David Michonneau a
|
|
| |
Goto Forum:
Current Time: Wed Sep 25 22:24:59 GMT 2024
Powered by FUDForum. Page generated in 0.88461 seconds
|