Hi, Vincent, Camille,
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.
cW
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
De :
mdt-papyrus.dev-bounces@xxxxxxxxxxx
[mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de
LETAVERNIER Camille
Envoyé : mercredi 18 mai 2016 09:40
Ă : Papyrus Project list
<mdt-papyrus.dev@xxxxxxxxxxx>
Objet : [PROVENANCE INTERNET] Re: [mdt-papyrus.dev]
NattablePropertyEditor tries to modify its configuration without a
transaction
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
|