> 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. ..The templates are a great idea..for example I create String accessors/mutators for all my non-String attributes. I wouldn't want to have to duplicate these methods in my UML diagram, but half a dozen or so lines in a template (which I can switch on or off at will) do the job perfectly. I guess this functionality could be added to UML2EJB but as someone once said (Ara I think) it is a wasted add functionality if it already exists elsewhere.....and XDoclet works fine. I am also happy about the fact that my project can use many separate modules, and should I become dissatisified with one of them then I can easily pull it out and plug another one in....e.g. start with Middlegen --> XDoclet-aware code should my database pre-exist or start with UML --> XMI --> XDoclet-aware code if the database doesn't exist. I guess (dare I say it) that UML2EJB could also have a template to create EJBGen-aware code, if that was your preferred route. To me, all these modules seem conceptually to form part of an XDoclet family (just to contradict myself slighty!). As long as the input and output to/from each module is the same then this concept works damn fine. > 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. ..so at least 3 of us (I wonder how many more?) are doing exactly the same thing....I wonder if someone will start a project on this too maybe 6 months down the line. I think it's an interesting discussion, I would like to know how others are doing it, and what they think of my efforts, but I'm also worried that XDoclet mailing list might not be the right place for such a discussion...except for the fact that the target audience is probably correct.... Regards Chris -=-=-= Any e-mail message from the European Central Bank (ECB) is sent in good faith but shall neither be binding nor construed as constituting a commitment by the ECB except where provided for in a written agreement. This e-mail is intended only for the use of the recipient(s) named above. Any unauthorised disclosure, use or dissemination, either in whole or in part, is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and delete this e-mail from your system. ------------------------------------------------------- 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
