Lance and others, I'm CC'ing the XDoclet and Castor mailing lists and risking "get-lost-you-lame-crossposter" flamage in the hopes that some kind Castor/XDoclet expert might be interested in taking a brief look at the Roller architecture and giving us some hints on a better persistence layer. Maybe by reading over what we are doing you will see some blantant mistake we are making and can make a comment or two that might send us in the right direction.
Roller uses XDoclet to generate just about everything: the data objects that are returned by the persistence layer, the Castor mappings, the Struts form beans, etc. Roller could be a great example of integrated XDoclet/Castor/Struts/Velocity usage but it's design is somewhat limited by the small brain of the original designer (me). Read the Roller article and the below comments if you would like to take a stab at this. The article is here: http://www.onjava.com/lpt/a/onjava/2002/04/17/wblogosj2ee.html Now, on to Lance's questions: Lance Lavandowska wrote: >Is there any current reason why the Castor beans implement EntityBean? > Background: the Castor bean classes are the the "abstract bean classes" mentioned in the article - the are used as the basis for the #1 code generation pass. You can see the sources for those classes here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/roller/roller/src/org/roller/business/beans/ Those beans.* classes are the basis for almost all of the Roller code generation. The data object classes are generated from those beans. I've stuck with this design because it means that I do not have to write and maintain the *Data object classes, they are totally generated. The reason that the beans.* classes implement EntityBean is to please XDoclet and to trick it into generating those *Data object classes. If we wanted to get rid of the wacky EntityBean trick, there are (at least) two different ways we could go: 1) we could decide that we are no longer going to generate the *Data object classes. That would mean that we would would have to write those *Data object classes by hand (we could use the existing generated ones as starting points for this) and then we would add the XDoclet @castor tags to the *Data object classes so that we'd still get our auto-generated Castor mapping file and add the @struts tags so that we'd still get our Struts form classes. - OR - 2) we could write the Castor mapping file first and then use the Castor code generator to generate our *Data objects. But then, how would we generate our Struts form classes? And, we still have the problem that the *Data object classes are generated and it may not be easy to add methods to them. Of course, if the Castor code generation is good enough we may not have to add anything to those classes. >I've been thinking of another way to structure the beans: >-code org.roller.castor.beans.* as current, except that they extend >ValueObject >-in xdoclet specify each *Data object to extend its *Bean rather than >ValueObject > I'm not sure I understand how this would work. Now that I have explained the EntityBean kludge, do you still think this would work? >-then I can add the addCollection(Object) methods I've needed >-add the "depends" attribute can be used for the class mappings >-we'd need to eliminate direct updates to the dependant objects (I think, >still not clear on this) > I would really like to understand how Castor is supposed to work in this area. It would be nice to have a good Castor example to look at. The examples that come with Castor do not seem to be really complete in this area. Please correct me if I am wrong about this. >-this would mean a lot of work redoing the *Manager classes and the Action >classes > That is true. It would be nice if we could do this in a series of steps. The first step being to fix the persistence backend and get everything working again. And the second step being to start using addCollection() type calls in the presentation frontend. - Dave ------------------------------------------------------- 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
