arishanapalli / wsdl2objc

Automatically exported from code.google.com/p/wsdl2objc
MIT License
0 stars 0 forks source link

There seems to be no way to interact with this project #7

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Hey rock stars!  :-D

Good stuff.  I'm able to parse one of my WSDLs that are generated from
Apache CXF.  It's a pretty simple one with a single message that takes a
complex type, but it works.  

Since I was about to start on something like this, I'd be interested in
helping if I could.  To do that without being a nuisance, there should be
some more entries in the wiki about what the architectural plans for the
project are.  It appears to me that your parser is building an AST for the
types, that makes using a Visitor pattern the perfect renderer.  

I'm currently more of a Java guy, but this is the kind of project that
would be a great way to get some skill in O-C.  

Anyway, short of creating an issue, there seems to be no way of getting
messages to the two of you guys.  Is there a way to turn on a discussion board?

Brian

Original issue reported on code.google.com by br...@snapdatnetworks.com on 15 Jun 2008 at 4:49

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by madcow...@gmail.com on 11 Sep 2008 at 5:17