Hi,
I am trying to work out what the best approach to add support for
anonymous types to the idltowsdl tool is.
After giving it some thought, it seems to me that a good deal of
refactoring is neded in order to enable the idltowsdl tool to support
the full range of IDL constructs.
Before I start working, though, I would very much appreciate some
feedback on the changes I intend to make to idltowsdl and a reassurance
that I am on the right track :-)
I'll try to keep this as short as I can.
I think that the main problems I am facing stem from the fact that
original idea was to create Visitor classes that encapsulated what is
needed to create XmlSchema or Wsdl types.
However, because the original Visitor classes focus on the resulting
XmlSchema or Wsdl types, they cause quite a lot of code duplication. I
believe our visitor classes should instead focus on visiting IDL grammar
constructs.
An example will hopefully makes this clear: let's take the
MessagePartVisitor.
Its task is to visit the parameters of a IDL operation and generate the
corresponding corba:param and wsdl:part elements.
I think its real focus should be to visit the IDL grammar construct
(CORBA spec, chapter 3):
<parameter_dcls> ::= "(" <param_dcl> { "," <param_dcl> }* ")"
<param_dcl> ::= <param_attribute> <param_type_spec> <simple_declarator>
<param_attribute> ::= "in"
| "out"
| "inout"
<param_type_spec> ::= <base_type_spec>
| <string_type>
| <wstring_type>
| <scoped_name>
However, because its focus is to generate wsdl message parts, it has to
visit the return parameter too, which is a different IDL grammar rule
<op_type_spec>. This creates a special case that needs to be handle with
care and does not fit in with the model.
A cleaner solution would be to have a ParameterDclsVisitor which visits
a <parameter_dcls> IDL grammar rule (i.e. the AST nodes created for that
rule), which in turn invokes other visitors to visit other IDL grammar
rules.
For example, when it gets to visiting <string_type> in
<param_type_spec>, the StringTypeVisitor should be invoked.
Effectively, what I propose is to partition the IDL grammar rules in
sets and have a Visitor class take care of a rule set.
This is already what we have in the idltowsdl tool, but the problem is
that some Visitors visit overlapping rules, hence code duplication.
For example, the TypesVisitor class contains switch statements to visit
IDL const and IDL exception types. The same code is in the WSDLVisitor.
I think that a clean solution to this kind of problems would be to have
WSDLVisitor to visit the IDL grammar rule:
<definition> ::= <type_dlc> ";"
| <const_dcl> ";"
| <except_dcl> ";"
| <interface_dcl> ";"
| <module_dcl> ";"
and have TypesVisitor visit <type_dlc> instead of visiting <type_spec>
and <const_dcl> and <except_dcl> as it currently does.
But perhaps the most important advantage in taking an "IDL grammar rule"
approach is that it makes it easy to support correct IDL in general (and
anon types in particular).
I can't think of another way to support the anon types, but to mirror
the IDL grammar rules within the visitor classes.
Provided a visitor can visit all the possible productions of the set of
rules it implements, then we are guaranteed that it will produce the
right XmlSchema and WSDL.
To give a better idea of the kind of changes I'd like to make, I'll
describe the changes I started working on.
I modified the WSDLVisitor to implement the <definition> rule, so now it
will invoke the TypesVisitor to visit <type_dlc>, ConstVisitor to visit
<const_dcl>, ExceptionVisitor to visit <except_dcl>, PortTypeVisitor to
visit <interface_dcl>, and I am considering adding a ModuleVisitor to
visit <module_dcl> (which would handle nested modules and building the
a.b.c.interface dotted scoped names).
The next step would be to slightly modify the TypesVisitor to implement
the <type_declarator> rule and all its children.
Then create a TypeDclVisitor that
So, what are your thoughts on all this?
Cheers,
- Matteo
