Register new Xsd Visitors about xsdparser HOT 5 CLOSED

Hi,

Each existing xsd type has its own visitor already defined at the moment.

1. If what you want is to "replace" a visitor for a xsd element that is already defined in this library you may have to register a diferent type for that tag. For example:

• The type XsdUnion is already defined, with a visitor of type of XsdUnionVisitor and registered in type DefaultParserConfig as the type responsible for parsing the xsd:union tags, which is done by this line:

parseMappers.put(XsdUnion.XSD_TAG, XsdUnion::parse);

• You may implement your own version of a XsdUnion with a diferent implementation of the XsdAbstractElementVisitor interface and register it instead of the current type.

2. If you want to add a new type with the respective implementation of a Visitor to include logic for a new tag you just have to define an implementation of XsdAbstractElement and XsdAbstractElementVisitor and register it in your own ParserConfig as explained above.

Sorry for the long response, it was an interesting question that I didn't even considered while developing the library a long time ago.

Hope it helped!

from xsdparser.

Hi,

thank you for the response! This can work for me, but I thought more on something like this:

For each Xsd node type I can register a visitor without providing a new implementation for the respective Xsd node type. In the example above, I want to extend the XsdUnionVisitor class and give it as a visitor implementation to the XsdUnion instead of XsdUnionVisitor.

For example, JavaCC gives such a freedom and using Visitors one can apply, for instance, type checking oder code generation by traversing the abstract syntax tree (AST). The use of the XsdParser can be extended to be used, for example, in this way:

XsdParser xsdParser = new XsdParser(Config.XSD_SOURCE_PATH.concat(fileName));
xsdParser.registerVisitor(myVisitor);
List xsdSchemas = xsdParser.getResultXsdSchemas().collect(Collectors.toList());
myVisitor.getAllReplacedRefElements()
....

However, the proposed solution is helpful and I can work with it. But it will be nice if one can add functionality just via the API using the visitor pattern without changing the code in the library.

Best regards,
Ivo

from xsdparser.

Hello,

I've made some changes to the way that element classes are attached to visitors. Now each element receives a function to create their own XsdAbstractElementVisitor which can be configured by implementing the interface ParserConfig. The parser currently provides a default implementation of the Config but you can make your own.

I'll deploy this new version later today.

Edit: The new version with these changes is available: 1.0.26.

from xsdparser.

Thank you very much!

I will look at it and will give you a feedback in the course of the day.

from xsdparser.

I can work with the extension.

Thank you!

from xsdparser.