> on the other side of the coin... you would prefer that it was off by > default, and that people who wanted it had to put something in every > bean, > then that kinda makes a lot more work for everyone else... hence the > smart > defaults :) I'm more than willing to hear options/arguments here... and > acknowledge that it does make obvious the bind between subtask and task, > but the bind is already there, just hidden a bit...
I'd rather separate this into 2 issues, so as things don't get confused. First is whether or not data objects are enabled by default. Since the momentum already exists around data objects, I'm in no position to recommend more work for people. (I just hope I can get the behavior to work defining the "@ejb:data-object container=false" in a base class and all the subclass entities listen to that.) I'll go to the work of turning it off in all my code, and it won't affect my endorsement of xdoclet to my team. No biggie. The second issue, and really the bigger design issue to me, is using the ant subtasks to control application design. If your app uses data objects, you're going to have dependencies all over your code. Removing <dataobject> as an ant subtask will totally mess up your app design, since your remotes won't have the set/get data methods. Putting those methods in the remote/local interfaces should be a decision derived from looking at the bean java, not on the structure of your build.xml. By my preferences, whether data objects are on or off means that the people outside the default have a lot of bean changes to make. The current implementation of xdoclet makes this a one line change to build.xml, which seems like an efficiency win. However, I think it damages the elegant premise of xdoclet. But I do concede that what I interpret as the premise of xdoclet may not match that of the people coding it. ;) I appreciate the thoughtful (and rapid) feedback! -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
