Closed GoogleCodeExporter closed 9 years ago
Oh wait, I guess Visitor pattern won't work. "Objective-C implements
polymorphism of
method names, but not argument or operator overloading." Fail.
Original comment by br...@snapdatnetworks.com
on 15 Jun 2008 at 5:01
Hmm. Honestly, I never expected anyone to find this this early! The reason
there are
no wiki articles about the architectural plans for the project is because,
right now,
there aren't any. It's still very much in the "try stuff out and don't be
afraid to
rip everything up if it's stupid" stage. Still, the stated goal of the project
is to
be better than WSMakeStubs. This is such a stunningly low bar that (as far as
I'm
concerned) the project has already succeeded. :) We would definitely appreciate
any
help along the way to making it actually useful, though!
I'll try to find some time this week to look into writing some stuff up. I'm
not sure
about a discussion board; there doesn't seem to be anything in Google Code and
I'm
hesitant to split the project up into multiple websites at this point.
Thanks for your interest!
(Note: I've assigned this bug to willia4 (me) so I can make the effort to
communicate
better)
Original comment by will...@gmail.com
on 16 Jun 2008 at 1:02
Yah, I figured that to be the case. Would love to help!
Here's some suggestions. I've done a lot of this kind of code generation in my
time,
but mostly in Java (a project called Dentaku if you want to look it up). This
is how
I did things there.
If you can create an object graph that mirrors the semantic richness of the
language
you are trying to render, you can parse the input and never be in a situation
where
you didn't scan something in. This object graph is important because you want
to
avoid writing an event-driven parser because they are too specific and
difficult to
expand and reuse. Memory usage is a downside, but let's ignore that for now.
This
object graph is called an "Abstract Syntax Tree" or AST for short.
The trick then is to generate an AST that has all the semantic richness of your
source material. It turns out you already have a fine model to work with in
the form
of XSD, but going through the generic XML parser routines is a ball-and-chain
around
your ankle when you are trying to get things done. My first line of attack then
would be to create or steal an API wrapper for the deserialized XSD, for
instance
something that very generically understood that a sequence has a list of
elements
(and possibly more). Make sense so far?
With these Objective C classes, it becomes VERY easy to parse the XML that
makes up a
WSDL, right? If you have a symbol table that references classes by name, then
in
XML, you simply map the QName to the class, instantiate the class, fill in the
fields, and store it as a child of the parent it belongs to. Boom, you have a
perfect in-memory representation of the input. This is your AST.
With the AST, you can now create modules that understand how to create output
against
the AST. Each of these fully contained modules does a different thing. One
might
give you a pretty HTML report, another might generate Objective C classes that
can
act as client stubs, another module might generate Objective C classes that are
server skeletons. A bug in one module is self-contained from the others,
because
they all query the AST for instructions. I think you guys are doing this
already to
some degree, just with an internal AST that you are growing organically.
Now, when you generate code, the best way to generate against the AST is to use
a
template engine. Check out http://en.wikipedia.org/wiki/Template_processor.
Velocity is an awesome one, but it's Java. In any event, what you do so create
a
template, then let the template query the AST for what it needs to generate the
code.
In this manner, for five routines that need to be in a class, you have a template
for the file with the file headers, start the implementation section, then
iterate
all five of the routines that are in the AST. If there's a bug in the code, you
don't putz around with shuffling printfs, you work at the level of a template
to get
it right. It's kind of like the difference between FastCGI coding and coding
in PHP.
Way easier to do the latter.
Lastly, something you haven't thought of yet. All these objects in the AST
look like
they might be challenging to write, correct? They can be. Worse, because they
are
representative of XML namespaces in the WSDL, they might change as the
technologies
evolve. So don't write the classes that make up the AST. Generate them! You
are
already going to be writing code generators with template engines, so as a
bootstrap
to compiling your code, have the build scan the relevant XSD (such as
http://schemas.xmlsoap.org/wsdl), generate objects which compose the AST of the
scanned WSDL, then when you write the deserializer, you are working with a full
plate
of objects to go against. If you run into a new schema, no problem, just add
them to
the build preprocessor and your AST is instantly updated. Future proofed!
Ok, I better run, hit me up with Q's.
Original comment by br...@snapdatnetworks.com
on 16 Jun 2008 at 3:25
Original comment by madcow...@gmail.com
on 11 Sep 2008 at 5:17
Original issue reported on code.google.com by
br...@snapdatnetworks.com
on 15 Jun 2008 at 4:49