Home » Modeling » M2T (model-to-text transformation) » Correct use of workaround for namespace handling?
| Correct use of workaround for namespace handling? [message #59506] |
Wed, 15 April 2009 13:34  |
 No real name
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Hi,
I use JET (0.9.2) to load a UML model created in RSARTE (by specifying the
model loader org.eclipse.jet.xml under plugin.xml ->
org.eclipse.jet.transform -> modelLoader.
After discovering the XPath caveats in JET, I have tried in different ways
to navigate through the model using XPath expressions. I have two
questions:
1) I'm trying different ways of selecting node sets and I have tried the
tips from:
http://dev.eclipse.org/newslists/news.eclipse.modeling.m2t/m sg00399.html
>
> Instead of:
>
> //packagedElement[@xmi:type = 'uml:Association']
>
> Try:
>
> // packagedElement[self::Association]
>
I have a model containing several nodes such as in this snippet:
<packagedElement name="Controller" xmi:id="_llg7oBlLEd6cf-0BDxo56w"
xmi:type="uml:Class">
I would, for example, like to iterate over all packagedElements that are
of xmi:type = "uml:Class".
The advice, as I interpret it, is to use the XPath select statement:
<c:iterate select="//packagedElement[self::Class]" >
... Do something interesting
</c:iterate>
but this does not result in any selected nodes. What can I have missed
that causes the suggestions to fail in my case?
2) The XPath implementation does not support the id function, and I'm
again interpreting the post linked above as saying that there exists
workarounds for this.
The base_Class attribute of the following Capsule node contains the id of
the packagedElement above. I would like to navigate from the Capsule node
to the packagedElement.
<UMLRealTime:Capsule base_Class="_llg7oBlLEd6cf-0BDxo56w"
xmi:id="_lltv8BlLEd6cf-0BDxo56w"/>
If $capsule points to this Capsule node, then could I use some variant of
<c:get select="//packagedElement[xmi:id = $capsule/base_Class]" />
to obtain the packagedElement node?
Thanks,
Lars
|
|
|
| Re: Correct use of workaround for namespace handling? [message #59579 is a reply to message #59506] |
Tue, 21 April 2009 20:36  |
Paul Elder
Messages: 849
Registered: July 2009 |
Senior Member |
|
|
Lars wrote:
> 1) I'm trying different ways of selecting node sets and I have tried the
> tips from:
> http://dev.eclipse.org/newslists/news.eclipse.modeling.m2t/m sg00399.html
>>
>> Instead of:
>>
>> //packagedElement[@xmi:type = 'uml:Association']
>>
>> Try:
>>
>> // packagedElement[self::Association]
>>
This assumes that, instead of the XML model loader, you use the EMF model
loader (org.eclipse.jet.emf). With the EMF model loader, JET is loading
the UML model using the UML2 APIs - these ones:
http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.uml2.doc/references/javadoc/org/eclipse/uml2/uml/package-s ummary.html
In this case, XPath steps first try to match a 'feature name'. Failing
that, they take a look at the eContents of the current object, and try to
match a contained object whose eClass().getName() equals the step name.
The bottom line: if you use the EMF loader, you can stop looking at the
XMI representation of your UML model, and start looking at it from the
perspective of the UML2 API. Advantages:
* the XMI omits all values that are defaults - the UML2 API lets you see
them
* with the UML2 API, you can use steps to follow non-containment
references (for example, if $prop is a UML Property, the $prop/type/@name
is equivalent to prop.getType().getName()). With the XMI, you'd have to be
chasing things down via their GUIDs - very ugly indeed.
Final tip. If switching to the EMF model loader from the XML/XMI view of
the work, most of your XPaths will work unmodified, except for:
* any references to xmi:type and xmi:id will be broken - the UML2 API does
not reveal the 'id' of an EObject (you have to dig for this), and the
xmi:type translates into the eObject.eClass().getName().
* there are subtle differences in the meaning of the initial / in XPath
expresions. With XML, it is the org.w3c.dom.Document object. With EMF, it
is the org.eclipse.emf.ecore.resource.Resource object. This main
difference is what the first 'step' is from /.
With an XMI serialization of the model, there is a single root element,
matched by /XMI or /Model or /Package, depending on how your model is
rooted on a Package or a Model, and whether any Stereotypes are applied.
With the EMF serialization, there may be multiple children directly of of
/. The first one is always the UML Package or Model that forms the root of
the model. Any subsequent elements are stereotypes. You can use the
following expressions to match the Model/Package:
/Model - matches a Model object only
/Package - matches a Package object only
/contents[1] - matches the first contained child (a Package or a Model)
/*[1] - matches the first contained child (a Package or a Model)
You can match all the stereotype applications by an expresion such as:
/contents[position() > 1] - you'll need to escape the > with \ in a tag
such as:
<c:iterate select="/contents[position() \> 1]" var="st">
<c:setVariable var="element"
select="$st/*[starts-with(local-name(),'base_')]
Stereotype <c:get select="name($st)"/> applies to <c:get
select="name($element)"/> with qualified name <c:get
select="$element/@qualifiedName"/>
</c:iterate>
> I have a model containing several nodes such as in this snippet:
> <packagedElement name="Controller" xmi:id="_llg7oBlLEd6cf-0BDxo56w"
> xmi:type="uml:Class">
> I would, for example, like to iterate over all packagedElements that are
> of xmi:type = "uml:Class".
> The advice, as I interpret it, is to use the XPath select statement:
> <c:iterate select="//packagedElement[self::Class]" >
> ... Do something interesting
> </c:iterate>
This will work if you use the EMF model loader...
> 2) The XPath implementation does not support the id function, and I'm
> again interpreting the post linked above as saying that there exists
> workarounds for this.
No, it does not. But, if you follow my suggestion, and load the model via
EMF and you don't have to follow those GUID references. And, as an added
bonus, you can follow non-local references (those to other files/profiles).
> The base_Class attribute of the following Capsule node contains the id of
> the packagedElement above. I would like to navigate from the Capsule node
> to the packagedElement.
> <UMLRealTime:Capsule base_Class="_llg7oBlLEd6cf-0BDxo56w"
> xmi:id="_lltv8BlLEd6cf-0BDxo56w"/>
This is a stereotype reference. If you are using the EMF loader, you
should be able to get them by doing:
<c:iterate select="/Capsule" var="capsule">
Stereotype applied to: <c:get select="$capsule/base_Class/@name"/>
</c:iterate>
Also, in messages:
http://dev.eclipse.org/newslists/news.eclipse.modeling.m2t/m sg01134.html
http://dev.eclipse.org/newslists/news.eclipse.modeling.m2t/m sg01214.html
I make some suggestions on custom XPath functions for accessing
stereotypes.
> Thanks,
> Lars
Paul
|
|
|
| Re: Correct use of workaround for namespace handling? [message #59653 is a reply to message #59579] |
Wed, 22 April 2009 10:53 |
No real name
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Paul Elder wrote:
> This assumes that, instead of the XML model loader, you use the EMF model
> loader (org.eclipse.jet.emf). With the EMF model loader, JET is loading
> the UML model using the UML2 APIs - these ones:
>
http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.uml2.doc/references/javadoc/org/eclipse/uml2/uml/package-s ummary.html
OK, I started using this approach but didn't (and still don't) find
everything that I need to extract by looking at the dump.xml produced by
the transformation when I use the EMF model loader.
For example, I am most interesed in capsules and their state machines, but
the XML dump does not reveal the code executed in the transision (the
effect). Nor can I see in the dump what triggers the transition. When I
use the XML model loader all of this becomes visible. This was the reason
I felt compelled to switch.
> In this case, XPath steps first try to match a 'feature name'. Failing
> that, they take a look at the eContents of the current object, and try to
> match a contained object whose eClass().getName() equals the step name.
> The bottom line: if you use the EMF loader, you can stop looking at the
> XMI representation of your UML model, and start looking at it from the
> perspective of the UML2 API. Advantages:
> * the XMI omits all values that are defaults - the UML2 API lets you see
> them
> * with the UML2 API, you can use steps to follow non-containment
> references (for example, if $prop is a UML Property, the $prop/type/@name
> is equivalent to prop.getType().getName()). With the XMI, you'd have to be
> chasing things down via their GUIDs - very ugly indeed.
Yes, it quickly becomes quite messy with lots of ugly iterations over
attributes. (Actually, the messiness sort of snuck up on me..)
> Final tip. If switching to the EMF model loader from the XML/XMI view of
> the work, most of your XPaths will work unmodified, except for:
> <snip>
Great! Am I correct in believing that this means that I can still extract
the effect and trigger of a transition and the Entry and Exit code of
states using XPath expressions, even though I cannot see it in the dump?
> Also, in messages:
> http://dev.eclipse.org/newslists/news.eclipse.modeling.m2t/m sg01134.html
> http://dev.eclipse.org/newslists/news.eclipse.modeling.m2t/m sg01214.html
>
> I make some suggestions on custom XPath functions for accessing
> stereotypes.
I will take a look!
I find it somewhat difficult to sort out how my XPath expressions should
look if they do not immediately correspond to what I see in the dump
produced. How, for example would I iterate over all states belonging to
the statemachine in the variable $stm and print out their respective entry
and exit code?
I can for example see the following in the dump:
<uml:region name="Region1"
qualifiedName="TrafficSystem::Controller::ControllerSTM::Region1 ">
<uml:subvertex/>
<uml:subvertex name="nsGreen"
qualifiedName="TrafficSystem::Controller::ControllerSTM::Region1::nsGreen ">
<uml:connectionPoint name="goNSYellow"
qualifiedName=" TrafficSystem::Controller::ControllerSTM::Region1::nsGreen:: goNSYellow "
kind="exitPoint"/>
</uml:subvertex>
<uml:subvertex name="nsYellow"
qualifiedName="TrafficSystem::Controller::ControllerSTM::Region1::nsYellow ">
<uml:connectionPoint kind="exitPoint"/>
</uml:subvertex>
...
<uml:transition name="Initial"
qualifiedName="TrafficSystem::Controller::ControllerSTM::Region1::Initial ">
<ecore:eAnnotations source="uml2.alias">
<ecore:details key="Initial"/>
</ecore:eAnnotations>
<uml:effect name="Effect"
qualifiedName=" TrafficSystem::Controller::ControllerSTM::Region1::Initial:: Effect "
language="C++"/>
</uml:transition>
<uml:transition name="goNSYellow"
qualifiedName=" TrafficSystem::Controller::ControllerSTM::Region1::goNSYello w ">
<uml:effect name="Effect"
qualifiedName=" TrafficSystem::Controller::ControllerSTM::Region1::goNSYello w::Effect "
language="C++"/>
<uml:trigger name=""/>
</uml:transition>
<uml:transition name="goEWGreen"
qualifiedName=" TrafficSystem::Controller::ControllerSTM::Region1::goEWGreen ">
<uml:effect name="Effect"
qualifiedName=" TrafficSystem::Controller::ControllerSTM::Region1::goEWGreen ::Effect "
language="C++"/>
<uml:trigger name=""/>
</uml:transition>
...
</uml:region>
Thanks,
Lars
|
|
| |
| Re: Correct use of workaround for namespace handling? [message #59725 is a reply to message #59653] |
Wed, 22 April 2009 13:22 |
Paul Elder
Messages: 849
Registered: July 2009 |
Senior Member |
|
|
Lars wrote:
> OK, I started using this approach but didn't (and still don't) find
> everything that I need to extract by looking at the dump.xml produced by
> the transformation when I use the EMF model loader.
To quote myself in another of today's posts:
The c:dump tag is incapable of displaying all the information found in
object network such as an ECore model. The best it can do is traverse the
containment features, and show the values of EAttribute features.
It cannot:
* show you non-containment EReferece features
* EReference features that are derived from others (such as eAttributes,
eAllAttributes, ...)
c:dump was intended to be a quick and dirty 'let me see the structure of
my input, and any annotations I've placed on it (via c:set)'. It is
certainly not a reliable and complete serialization of the input model.
Bottom line: when using an EMF-based model as input, don't look at the XML
either in the input document or that produced by c:dump. Look at the Java
API for the model.
<snip>
> Great! Am I correct in believing that this means that I can still extract
> the effect and trigger of a transition and the Entry and Exit code of
> states using XPath expressions, even though I cannot see it in the dump?
Yes. Stop looking at the dump. Get familiar with the UML2 API instead. If
you can see it in your UML model, JET can see it. The only place were JET
needs some assistance is in stereotypes.
I wrote the following advice on navigating the UML2 API in the IBM
Redbooks "Strategic Reuse with Asset Based Development". It provides some
tips on how to find the names of reference and attribute features by
looking at your UML model in the IBM Rational modeling tools. Here's a
link to the section
http://www.redbooks.ibm.com/redbooks/SG247529/wwhelp/wwhimpl /api.htm?href=18-6-6.htm
> I find it somewhat difficult to sort out how my XPath expressions should
> look if they do not immediately correspond to what I see in the dump
> produced. How, for example would I iterate over all states belonging to
> the statemachine in the variable $stm and print out their respective entry
> and exit code?
I work on the same floor as the team that puts together the IBM Rational's
modeling tools. I remember my first attempt to make sense of the nearly
1000 pages that are the UML2 spec. Even after 5+ years, I still get
confused by it, and I figure other mortals (even those smarter than me)
would be confused, too.
Some of the features of JETs navigation of models are intended to make
this simpler. In particular, I decided that:
* In a tool like RSA, it is much more evident what the type of an UML
element is than what its containing feature is. In RSA, the model
explorer/project explorer shows icons representing UML element types
(Package, Class, Property, Interface, Region, ...). If you select any one
of these, the Properties view kindly tells you what kind of object it is
in the title bar.
So, the XPath engine tries to let you navigate that way. Assuming you get
the 'stereotype' function I suggested early working, you could write
expressions like:
/Model//Class[stereotype(., 'UMLRealTime::Capsule')]/StateMachine
If $sm referred to a StateMachine, then you could do things like:
$sm/Region
or
$sm/Region/State
$sm/Region/PseudoState
With state machines, however, there is no substitute for knowing a bit of
the API. For example, if $state is a State, you'd want to be able to write:
$state/incoming
and
$state/outgoing
In the limited play I have done with state machines, I have found much
more useful to use incoming and outgoing, than to try and find Transitions
directly (where ever they may be).
> Thanks,
> Lars
Glad to help,
Paul
|
|
| |
| Re: Correct use of workaround for namespace handling? [message #59889 is a reply to message #59725] |
Thu, 23 April 2009 14:22 |
No real name
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Great help!
> Yes. Stop looking at the dump. Get familiar with the UML2 API instead. If
> you can see it in your UML model, JET can see it. The only place were JET
> needs some assistance is in stereotypes.
Got it. I stopped :)
> I wrote the following advice on navigating the UML2 API in the IBM
> Redbooks "Strategic Reuse with Asset Based Development". It provides some
> tips on how to find the names of reference and attribute features by
> looking at your UML model in the IBM Rational modeling tools. Here's a
> link to the section
>
http://www.redbooks.ibm.com/redbooks/SG247529/wwhelp/wwhimpl /api.htm?href=18-6-6.htm
Read that, it helped and I now understand much better how to navigate
around the non-stereotype things.
> So, the XPath engine tries to let you navigate that way. Assuming you get
> the 'stereotype' function I suggested early working, you could write
> expressions like:
> /Model//Class[stereotype(., 'UMLRealTime::Capsule')]/StateMachine
OK, this is where I'm at now. Instead of trying to jump as I described in
an earlier post, I should use the stereotype function as a filter of
sorts. That should also give me access to stereotype attributes that I
will need such as:
<c:get select="stereotype($port, 'UMLRealTime::RTPort')/@isConjugate" />
which should give me the isConjugate attribute from the RTPort stereotype
of the $port element.
I have tried to create the XPath extension as described in:
http://wiki.eclipse.org/JET_FAQ_How_do_I_create_custom_XPath _Function%3F
and dropping in the code for the stereotype function that you provide at:
http://dev.eclipse.org/newslists/news.eclipse.modeling.m2t/m sg01214.html
I also tried to add the extension directly to the JET project by going to
plugin.xml -> Extensions -> Adding new xpathFunctions and creating the
stereotype function there instead.
This may be more due to my lack of Eclipse skills but when I then try to
use the two jet snippets above the Xpath expression returns no results:
templates/capsuleTemplates/genPort.pml.jet(36,2): <c:get
select="stereotype($port, 'UMLRealTime::RTPort')/@isConjugate">
Error: XPath expression returned no result
(The Capsule snippet iteration produces nothing)
Does JET not know about the function or am I using it wrong?
Thanks!
/Lars
|
|
|
| Re: Correct use of workaround for namespace handling? [message #60088 is a reply to message #59889] |
Tue, 28 April 2009 08:19 |
No real name
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Hi,
As an addition to what I wrote previously, here is some more info on what
I've tried so far:
First of all, I'm using the org.eclipse.jet.emf model loader.
> I have tried to create the XPath extension as described in:
> http://wiki.eclipse.org/JET_FAQ_How_do_I_create_custom_XPath _Function%3F
> and dropping in the code for the stereotype function that you provide at:
> http://dev.eclipse.org/newslists/news.eclipse.modeling.m2t/m sg01214.html
> I also tried to add the extension directly to the JET project by going to
> plugin.xml -> Extensions -> Adding new xpathFunctions and creating the
> stereotype function there instead.
> This may be more due to my lack of Eclipse skills but when I then try to
> use the two jet snippets above the Xpath expression returns no results:
> templates/capsuleTemplates/genPort.pml.jet(36,2): <c:get
> select="stereotype($port, 'UMLRealTime::RTPort')/@isConjugate">
> Error: XPath expression returned no result
> (The Capsule snippet iteration produces nothing)
To clarify, I can iterate over all classes and get their names:
<c:iterate select="/Model//Class" var="class" >
<c:get select="$class/@name" />
</c:iterate>
However, I cannot use the stereotype function to get only those classes
which are also a capsule:
<c:iterate select="/Model//Class[stereotype(., 'UMLRealTime::Capsule')]"
var="class" >
<c:get select="$class/@name" />
</c:iterate>
This produces nothing.
(I've tried both single and double ':' just to be on the safe side..)
Finally, I've also tried your suggestion for listing stereotype
applications from
http://www.eclipse.org/newsportal/article.php?id=1459&gr oup=eclipse.modeling.m2t#1459
> You can match all the stereotype applications by an expresion such as:
>
> /contents[position() > 1] - you'll need to escape the > with \ in a tag
> such as:
>
<c:iterate select="/contents[position() \> 1]" var="st">
<c:setVariable var="element"
select="$st/*[starts-with(local-name(),'base_')]" />
Stereotype <c:get select="name($st)"/> applies to <c:get
select="name($element)"/> with qualified name <c:get
select="$element/@qualifiedName"/>
</c:iterate>
This produces the following:
...
Stereotype contents applies to with qualified name
Stereotype contents applies to with qualified name
Stereotype contents applies to with qualified name
...
Are these symptoms related?
> Does JET not know about the function or am I using it wrong?
I'm now assuming that JET must know about the function, because if I
change the name I get an error:
Error: Unknown function name: stereotype3
Unknown function name: stereotype3
Therefore, I'm probably using it wrong or I have failed to make some
setting somewhere?
Thanks a lot for your help, I'm getting nowhere fast...
/Lars
|
|
| |
| Re: Correct use of workaround for namespace handling? [message #60325 is a reply to message #60227] |
Fri, 01 May 2009 15:13 |
Paul Elder
Messages: 849
Registered: July 2009 |
Senior Member |
|
|
Lars:
An update. After chatting with a few people more knowledgeable than me,
and some experimentation, I have an way of moving you forward. I'll attach
some examples at the end.
The solution involves creating a JET 'model loader' specific to IBM
Rational .emx (UML models) and epx (UML profiles) files. You must:
1) create a plug-in with the code I'll attach.
2) export it as a 'deployable plug-in'
3) install it in your RSARTE plugins directory and restart
4) reference it in your JET transformation.
The code itself is fairly simple, but it makes use of RSARTE APIs (rather
than just open source APIs), so I can't put it into JET itself.
--- my example code ---
I created a plug-in project named 'com.ibm.example.rsx.jetloader'. It has
not UI dependencies and no activator (questions asked in the wizard).
I added dependencies on two plug-ins:
* org.eclipse.jet - to define the model loader
* com.ibm.xtools.modeler.ui - to access the public APIs to load the
emx/.epx files
I created an 'org.eclipse.jet.modelLoaders' extension to declare the
loader to JET. I gave the loader the ID 'uml2', so, if you use my sample
as is, the fully qualified model loader ID is
'com.ibm.example.rsx.jetloader.uml2'
---- plugin.xml contents ----
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>
<plugin>
<extension
point="org.eclipse.jet.modelLoaders">
<loader
class="com.ibm.example.rsx.jetloader.RsxUml2ModelLoader"
dynamicTypes="false"
id="uml2"
name="Rational UML2 model loader">
<type
fileType="emx">
</type>
<type
fileType="epx">
</type>
</loader>
</extension>
</plugin>
----- end plugin.xml contents ----
----- class RsxUml2ModelLoader contents -----
package com.ibm.example.rsx.jetloader;
import java.io.IOException;
import java.net.URL;
import org.eclipse.emf.common.util.URI;
import org.eclipse.jet.runtime.model.IModelLoader;
import com.ibm.xtools.modeler.ui.UMLModeler;
public class RsxUml2ModelLoader implements IModelLoader {
public boolean canLoad(String kind) {
return "emx".equals(kind) || "epx".equals(kind);
}
public Object load(URL modelUrl) throws IOException {
URI emfURI = URI.createURI(modelUrl.toExternalForm());
return load(modelUrl, emfURI.fileExtension());
}
public Object load(URL modelUrl, String kind) throws IOException {
URI emfURI = URI.createURI(modelUrl.toExternalForm());
if("emx".equals(kind)) {
return UMLModeler.openModelResource(emfURI).eResource();
} else {
return UMLModeler.openProfile(emfURI);
}
}
public Object loadFromString(String serializedModel, String kind)
throws IOException {
throw new UnsupportedOperationException();
}
}
----- end class RsxUml2ModelLoader contents -----
|
|
|
| Re: Correct use of workaround for namespace handling? [message #60349 is a reply to message #60088] |
Fri, 01 May 2009 15:30 |
Paul Elder
Messages: 849
Registered: July 2009 |
Senior Member |
|
|
A final follow-up.
You asked about this code snippet.
<c:iterate select="/contents[position() > 1]" var="st">
<c:setVariable var="element"
select="$st/*[starts-with(local-name(),'base_')]" />
Stereotype <c:get select="name($st)"/> applies to <c:get
select="name($element)"/> with qualified name <c:get
select="$element/@qualifiedName"/>
</c:iterate>
In short, it doesn't work as I intended. In particular, the XPath name()
function doesn't give the type of an UML element, it containing feature.
In the case case of the stereotype applications, they are all contained
directly in the EMF Resource, so JET returns 'contents'. Similarly,
name($element) doesn't work as I had wanted.
What's needed is yet another XPath function - one that returns the EClass
of an EObject. A proposed implementation is in this message:
http://dev.eclipse.org/newslists/news.eclipse.modeling.m2t/m sg00837.html
But when I look at the message on-line, the source is all in a single
line, so I'm pasting it in at the end of this message.
With these funcions available
<c:iterate select="/contents[position() > 1]" var="st">
<c:setVariable var="element"
select="$st/base_Class" />
Stereotype <c:get select="eClass($st)/@name"/> applies to <c:get
select="eClass($element)/@name"/> with qualified name <c:get
select="$element/@qualifiedName"/>
</c:iterate>
Finally, the upcoming version of JET (which won't make it into RSARTE for
some time) defines implementations of eClass() and of stereotype() - it
calls them 'emf.eClass' and 'uml2.stereotype', respectively. Don't use
those names, and on some sunny day in the future, you can throw away your
custom versions.
Paul
---- class EClassFunction contents ----
package org.eclipse.jet.examples.functions;
import java.util.List;
import org.eclipse.emf.ecore.EObject;
import org.eclipse.jet.xpath.NodeSet;
import org.eclipse.jet.xpath.XPathFunction;
/**
* Implement an XPath function that returns the EClass of an object (if it
is an EObject).
*
*/
public class EClassFunction implements XPathFunction {
/* (non-Javadoc)
* @see org.eclipse.jet.xpath.XPathFunction#evaluate(java.util.List)
*/
public Object evaluate(List args) {
Object object = null;
final Object objectArg = args.get(0);
if(objectArg instanceof NodeSet) {
NodeSet nodeSet = (NodeSet) objectArg;
object = nodeSet.size() > 0 ? nodeSet.iterator().next() : null;
} else {
object = objectArg;
}
return object instanceof EObject ?
((EObject)object).eClass() : null;
}
}
|
|
| |
Goto Forum:
Current Time: Thu Apr 18 23:52:09 GMT 2024
Powered by FUDForum. Page generated in 0.02372 seconds |
] 
Search
Help
Register
Login
Home
