On Thu, 2005-02-17 at 18:31, Paul Lee wrote: > Hi, I have some question about the philosohy of using merge files for plain > old java code generation. > > I started asking about this here in the Xdoclet In Action forum: > http://www.manning-sandbox.com/thread.jspa?threadID=11401&tstart=0 > > Basically I sold the idea of xdoclet to management. I still need to get > buy-in from Java programmers though.
Interesting, normally I'd think it would be the other way round. > And knowing some of them, I know I need > to make the transition as easy as possible, otherwise my xdoclet proposal will > die. Just point them here http://www.theserverside.com/cartoons/EJBHammer/EJBHammer.html and then tell them how much more money they can earn when they can list industry standard Open Source tools on their CVs ;-) > One area I am struggling with is with specific methods for generated classes. > Consider the following scenario: > > (1) programmer writes foo.xdt and foo.java to generate fooFinal.java > (2) The foo.xdt reads the tags in foo.java and creates the skeleton in > fooFinal.java > (3) we now need to implement a method bar() in fooFinal.java Bad mpve. All your carefully written code in the bar() implementation goes up in smoke when you run the build script again and fooFinal.java is overwritten by a newly generated one... Do like the EJB modules do, namely (1) programmer writes foo.java containing the tags and the implementation of bar(). (2) programmer writes foo.xdt to generate fooFinal.java which extends foo.java; the generated code includes a bar() method which calls super.bar(), so your implementation code gets run. > >From what I understand the programmer needs to create a 3rd merge file, > probably foo.merge, in the merge directory. Not necessarily. You're writing the template, just make sure it includes everything you need. Remember that @tag values can use ${values} (automatically substituted with the corresponding Ant properties at build time) for any environment-specific bits you want to vary when building for development, testing & production etc., and you can probably manage without any merge files. > That's 3 files to maintain as > opposed to 1 the old-fashioned way! The programmers I know will not like > that! We're back down to two, the template itself and the java source file. The template shouldn't need changing much once you've got it working, and is shared by many source files (if not, then why bother with code generation in the first place?) So that's only one file to maintain, which won't need to contain any boring repetitive "boilerplate" code that developers hate to maintain anyway (copy & paste, copy & paste, copy & paste, oops there's a typo slipped in that won't get discovered till after the system goes live and the bug reports come flying in...) > I am wondering why can't we make use of the foo.java file. Instead of just > tags, the programmer can also put bar() implementation into foo.java. The xdt > file can then just use something (psudo for now) like: > > <XDtMethod:forAllMethods> > <XDtMethod:currentMethodContent /> > </XDtMethod:forAllMethods> > > to merge the bar() method into the final result that is fooFinal.java. See, you almost had it :-) Only problem is that method bodies aren't available to the templates, at least not without big performance-sapping changes to the parser (it's called "xjavadoc" for reasons you can probably guess) and new template tag handlers to make use of them. So instead of trying to copy the code into your generated class just call it in its original location. You've got to watch the scoping & visibility, especially if the generated class isn't in the same package, but that's not too difficult. So, in reply to the subject "Why use merge files for plain old Java code generation?", I'd say the answer is "Because you need to. If you don't need to, then don't bother." Does that answer all your questions? Andrew. > This way, programmers will only have to deal with foo.java most of the time > (foo.xdt should be relatively unchanging anyway), and since foo.java is > already in compilable Java class syntax, it is much more natural and > IDE-friendly than a seperate merge file. > > I think this fits more with xdoclet's "all information generated from 1 place" > philosophy, at least for the plain old Java files. > > So after a long-winded post, my questions: > - am I off? And if it's a bad idea, why? > - what are the best practices to deal with specific methods like bar()? Is > merge file the way? > - if I were to create a tag like the <XDtMethod:currentMethodContent/>, is it > possible? > > Thanks in advance! > > Paul -- ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ xdoclet-user mailing list xdoclet-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xdoclet-user
