> Today I can understand XDoclet and this is not a problem to me. But if > we are generating files why not create all of them ? To the final user > this does not make any difference. In fact is better because the user > shoud not need to install XDoclet. On my first version I had some very > simple code geration routines. In fact they are just println > statements. For the next version I am planning something better.
The important thing here is that xdoclet acts like a middleware here. No matter if you use Danilo's tool, or Matthias's or whomever, anyway the familiar and flexible and imho easier to understand xdocleted code is generated. It's easier to understand because of the "attribute oriented programming" paradigm. I really like the way attributes (@tags) describe my code. > I am creating values objects to my entitys too. > On another e-mail Chris Shaw talk about use reflection to make a > persistence layer which can work on small non-complicated projects. This > is another thing I am already doing. I'm also doing it. Some @tags in my code define the mapping from fields to columns. Then I read the xml file xdoclet generates, create the statements and use reflection to implement a persistence engine. Ara. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
