|[UMLX] Problem lookingup ambiguous classifiers qualified with its EPackage name [message #608065]
||Mon, 08 October 2007 10:02
Originally posted by: alu2526.etsii.ull.es|
Taking a look to your implementation of classifier 's lookup, i have
detected some problems.
QVTEnvironment has a method which detects the ambiguity in the classifier
lookup, is tryLookupMetaModelClassifier, which delegates the search to the
method lookupMetaModelClassifiers. The problem is that this method only find
unqualified classifiers, or classifiers qualified by a metaModel ID, but It
does not take into account that a classifier could be qualified by package
The problem is partly solved because try lookupMetaModelClassifier would
fail, and a classifier would be found in a normal
EcoreEnvironment.lookupClassifier. But ambiguous classifiers qualified by
its package name would not be detected. For example:
If we lookup comonPackageName::AClassifier we have an undetected ambiguity
of classifier's names.
Besides, when qualifying with a metaModel ID which represents a set of
packages, you could not find a nested package name, since the
QVTEnvironment.getPackagedClassifier implementation is not as complete as
EcoreEnvironment.lookupClassifier implementation is. Instead of having a map
<metaModelID, EPackages> (in QVTrTopLevelEnvironment or
QVTrTransformationEnvironment) and functions (lookupMetamodelClassifier,
getMetaModelContents, etc) to manage them, I encourage you to use
environments (QVTrTransformationEnvironments nest QVTrMetaModelEnvironments
which nest a set of QVTEnvironment which have a package context associated)
and exploit the use of EcoreEnvironment.lookupClassifier.
I have implemented a hierarchical set of environments for my QVTo
implementation, that perhaps it could be applied at a QVTEnvironment and
QVTrEnvironment abstraction level and shared for all QVTo, QVTr, QVTc
implementation to have a better classifier's lookup.
Powered by FUDForum
. Page generated in 0.01707 seconds