We had great fun with peter because I could understand what I was
looking for around my xml importer.
Peter has the same problem so it was fun that we can talk and see the
light.
What we learned in the process is that the pluggable behavior is nice
but limited
- type of matching
- you cannot match on children because you did not created them yet :)
So what we plan to do and started (peter publish your code :)
- have a naive visitor on XMLNode
- use it to write a transform visitor that turns such some nodes
into special "domain nodes"
- Define a builder generating visit methods for an exporterVisitor
visiting the "domain nodes"
(this phase can be really automated)
- The exporterVisitor will let the programmer to define export
rules and create Pharo Object and moose objects.
Peter if you find something useful in C# let me know.
Stef
Le 18/3/16 15:17, Peter Uhnák a écrit :
I have a XML like this
<packagedElement xmi:type="uml:Class" xmi:id="EAID_4A" name="DCEdge"
isAbstract="true">
<!-- some stuff -->
</packagedElement>
<packagedElement xmi:type="uml:Association" xmi:id="EAID_46">
<!-- some stuff -->
</packagedElement>
and I would like to generate UmlClass and UmlAssociation classes for this.
I could use XMLPluggableElementFactory, however that only allows me to
specify the target class only on the element's name, such as
doc := (XMLDOMParser on: someXML)
nodeFactory:
(XMLPluggableElementFactory new
elementClass: GenericElement;
handleElement: 'packagedElement' withClass: UmlPackagedElement)
parseDocument.
However I need better granularity, because I would like to have a
different class for 'packagedElement[xmi:type="uml:Class"]' and
different class for 'packagedElement[xmi:type="uml:Association"]'.
Of course I could use double visitors (so use the Pluggable stuff to
get UmlPackagedElement) and then make another pass on it to get the
final classes,
however I would prefer to have to wanted class directly without the
need to go through intermediate representation.
Is there a way to do this?
Thanks,
Peter