Hi Christian,
Yes, it is ok for me ! Thank you for your contribution
/Vincent
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Christian Damus
Envoyé : mercredi 18 mai 2016 14:13
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : Re: [mdt-papyrus.dev] [PROVENANCE INTERNET] Re: NattablePropertyEditor tries to modify its configuration without a transaction
And I have raised bug 493887 to
track an enhancement to support the on-the-fly listen-feature assignment required by Camille’s use case.
While I’m feeling lucky, perhaps you would also like to comment on review 72992 (uncontroversial
one-liner fix for another problem blocking our Papyrus-RT table property scenario)? 😁
On 18 May, 2016 at 07:26:31, LORENZO Vincent (vincent.lorenzo@xxxxxx) wrote:
Hi Christian,
Yes I agree with your gerrit (I set +1)
Yes, if we need to change the listen feature, the LocalHeaderAxisConfiguration is the
good way. I’m not sure this behavior is already proposed by the property view of the table editor, but it is the way to change the listen feature for flat table.
For TreeTable there is a similar way, it is done by the dialog used to change the listen
categories (feature).
For the general case, the object LocalHeaderAxisConfiguration has been created to override
the TableHeaderAxisConfiguration.
Regards,
--
Vincent Lorenzo
Thanks for your feed-back.
@Vincent, it seems we agree that the solution I am proposing in the Gerrit is
the best for the time being? 😀 And are you suggesting that the TableHeaderAxisConfiguration in the table-configuration model should be a prototype that generates a similar configuration in the table-instance model, and that this latter then should be updated
by the TablePropertyEditor to set the listen-feature on the fly whenever the input data-source changes? That sounds like a good direction to take.
@Camille, indeed, the replication of similar associations around the UML metamodel is tricky. I think there are
very few cases, if any, beyond the ownedAttribute and ownedOperation in the various classifiers. This actually is addressed in a non-standard fashion in the UML2 UML metamodel by a merge of AttributeOwner and OperationOwner metaclasses (and generalizations
to them) in the merged UML metamodel from which the API is generated. I wonder whether that would help your case? Or at least my interpretation of what I think Vincent was suggesting could help to restore the behaviour that you had initially implemented.
On 18 May, 2016 at 04:07:00, LORENZO Vincent (vincent.lorenzo@xxxxxx) wrote:
Hi Christian,
The synchronized feature should always be set in the table configuration model, so this step should not be required.
Nevertheless, if this step was required, we should transform the TableHeaderAxisConfiguration
into a LocalRowHeaderAxisConfigruation and add a EStructuralFeaturevalueFillingConfiguration to it. Some others stuff are probably required to do this changes.
Regards,
--
Vincent Lorenzo
Hi Christian,
As often, there is a
good bad reason for this: this was copied from my example/prototype implementation, which was about “ownedAttribute”. The UML Metamodel has at least 5 different “ownedAttribute” features (For Interface, StructuredClassifier, and a few others), but I
wanted to provide a single table configuration for all of them. So, when displaying the table, I simply replaced the actual feature on-the-fly
Of course, at this time, there were no transaction on this properties view integration of the table, and certainly no ServicesRegistry or ModelSet, so this wasn’t an issue
I believe this fragment of code has been copied as-is, even though it’s certainly not required for the general case (And specific case of Papyrus-RT Parameters), and wouldn’t work anymore with the new Transactional tables
HTH,
Camille
You know, the more I think about it, the more I feel like the NattablePropertyEditor just should not be trying
to modify its table-configuration. It’s a read-only resource, being deployed in a plug-in, and the change that the editor is trying to make is just setting the reference to what it already is (and should be) anyways.
I’ve raised bug 493853 so we can discuss
there if necessary.
On 17 May, 2016 at 16:06:56, Christian Damus (give.a.damus@xxxxxxxxx) wrote:
I am working on rebasing an old Gerrit change (review
66384) onto Neon, which was originally implemented on the Papyrus Mars platform and has been rebased along on Neon in progressive fits and starts. Amongst numerous other refactorings, this needs to account for refactorings in the Nattable implementation
of a property-sheet widget in the Papyrus Properties framework.
On the latest (May 17) Papyrus build, I see this block of code in the NattablePropertyEditor class:
if(null!=synchronizedFeature)
{
TableHeaderAxisConfiguration
rowHeaderAxisconfig =
tableConfiguration.getRowHeaderAxisConfiguration();
for(IAxisConfiguration
axisConfig : rowHeaderAxisconfig.getOwnedAxisConfigurations()) {
if(axisConfig
instanceof EStructuralFeatureValueFillingConfiguration) {
((EStructuralFeatureValueFillingConfiguration)
axisConfig).setListenFeature(synchronizedFeature);
}
}
}
This attempts to set the “listen feature” of an axis configuration in the table-configuration model. But, the
configuration model is loaded in a ModelSet with a transactional editing domain in a dedicated service-registry created by the NattablePropertyEditor so that would have to be done in a read/write transaction. Of course, there is no such transaction when showing
the Properties view for a model selection. Consequently, creation of the table widget blows up with an IllegalStateException on not having a transaction, and the table doesn’t appear in the Properties view.
Are we (Papyrus-RT) doing something wrong? It looks to me like the code snippet above could never possibly work.
Why is it even trying to replace the “listen feature” that is already set in the table-configuration? Is anybody else using a row-header axis configuration that contains a feature-value-filling configuration? Should this protocol-message parameters table
in Papyrus-RT even be using it?
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
|
