Engineering is about tradeoffs: you lose some control by using xdoclet, but you get rid of writing some boring code. I know that in some cases xdoclet does more than code generation: it suggests the use of some patterns. CMP1.1/2.0 coversion pattern, util objects, and many other things. But really only the user is to blame here, we've tried to provide enough options. For example I'm writing my own value objects, not using xdoclet. Why? Because I want a value object which has attributes from objects of an object graphs, the basic one EJB -> one value object generation wasn't interesting for me. So analyze your architecture and don't use code generation if it isn't appropriate for the case at hand. But anyway it is very clever to write code which writes code for you :-)
Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:xdoclet-user- > [EMAIL PROTECTED]] On Behalf Of Ryan Marsh > Sent: Wednesday, July 17, 2002 4:08 AM > To: Aslak Helles�y > Cc: [EMAIL PROTECTED] > Subject: RE: [Xdoclet-user] UML modeling frontend for XDoclet > > On Tue, 2002-07-16 at 18:32, Aslak Helles�y wrote: > > > I think he has a great point here. I am deep into developing my > > > application and I have a scary dependence upon Xdoclet in such a way > > > that it has negatively influenced the overall design of my > application. > > > It is way to late to go back now. I assume that the next version of > > > > Could you elaborate a bit more on the negative sides? That's something > we > > hear too little about! > > My problems are nothing that couldn't be solved by creating new > templates and tag handlers. I don't belive they are a result of some > kind of fundamental constraint to Xdoclet's architecture, they're just > an issue of feature-completeness. Something I will have to address > before my project is finished. You'll hear more on this as I find time > to write the code. > > I am also eagerly awaiting more documentation and a new version of > Xdoclet. > > > > Xdoclet will solve most of my problems but the point still remains: If > > > you are generating code, why not generate exactly what you want, > exactly > > > the way you want it without the extra layer of translation? I belive > we > > > all understand the inherent lossyness, and possibly even artifacting, > > > that can result when translating from one model to another through a > > > constrained (and let's be honest here Xdoclet does not represent 100% > of > > > possible configuration permutations) medium. > > > > Not even if you write your own templates and tag handlers? > > Like I said, Xdoclet (at the moment) isn't capable of expressing 100% of > the configuration permutations expressable if EJB development were done > manually. But it's not anything that couldn't be solved by a little > elbow grease. > > -ryan > -- > Humans are the unfortunate result of a local maximum in the > fitness landscape. > > www.ryanmarsh.com > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber - The world's fastest growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > _______________________________________________ > Xdoclet-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-user ------------------------------------------------------- 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
