Hi again,
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.
Thanks,
Christian
On 17 May, 2016 at 16:06:56, Christian Damus (give.a.damus@xxxxxxxxx) wrote:
Hi, Team,
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?
Thanks,
Christian
|