>> And now for the suggestion. I'm really positive about using xdoclet >> for >> an upcoming rewrite of our app, and I'm doing a bunch of groundwork to >> establish conventions and techniques. I would like to see xdoclet take >> a strategy of least-invasiveness in its generation. For instance, the >> package substitution (moving interfaces into .interfaces if the bean >> was >> defined in .ejb) was on by default, forcing people to add tons of tags >> to their code if their conventions differed from this builtin behavior. >> (It's now off, which is a good thing.) I believe this should be >> extended across the utility, where the ant subtasks avoids nonstandard >> things, unless explicitly enabled. > > what do you mean by nonstandard things? the ejb and interfaces > packages, > and dataobjects? XDoclet started as EJBDoclet, by Rickard Oberg, who > basically put what he saw as appropriate usage patterns in as > defaults. I > for one think they are good defaults, but am happy to hear suggestions > for > ehat you would see as alternative defaults... do you mean by this that > you dont use dataobjects?
In evaluating this as a tool, I tend to differentiate between standard (stuff in the EJB spec or other APIs (weblogic, struts, etc)) and conventional (common patterns, best practices, etc). I would like to see the standard stuff enabled as the default, and the conventional requiring explicit enabling. Data objects fall in the conventional category. No, we don't use them, instead relying on stateless facades and hashmaps. Since the facade methods generally interact with more than one entity type, data objects aren't sufficient. I'm not saying the conventional stuff isn't useful. Many conventions are tedious to implement, and xdoclet can fill those gaps very nicely. For people who use data objects, xdoclet is a godsend. The trouble is that having certain conventions on by default moves closer to a corollary of "one man's trash is another man's treasure." My suggestion remains to have the default behavior to not introduce anything (even the static final members of the Home interface) other than producing the corresponding declarations in standard interfaces and deployment files. Even the CMP subclass of the Bean should be unnecessary. Andrew suggested just leaving out the subtask from the ant script, but that doesn't work - I'll address that separately. Thanks, -benJ _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
