But even uml tools generate the getter/setter for you, at least TogetherJ does that (Just add a property).
Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:xdoclet-user- > [EMAIL PROTECTED]] On Behalf Of tek1 > Sent: Thursday, June 27, 2002 5:26 PM > To: [EMAIL PROTECTED] > Subject: Re: [Xdoclet-user] castormapping subtask > > true, but in starting a new project, we are using a uml tool to design the > classes before touching the ide. in starting with the uml tool, it would > be nice to only define: > > -the class name > -the class fields > -castor-specific tags (associate with the fields, not getter > methods) > -any non-setter/getter business logic methods > > based on this, the "core" .java file would be generated from the uml tool. > then, a xdoc template could be used to generate the "final" .java file, > which would contain default getter/setter methods for each field (if so > specified, using xdoc/castor tags), as getter/setter methods are pretty > cut > and dry. then, another template could be used, functionality-wise similar > to "castor doclet" (http://www.geocities.com/bansi_73/), to generate the > create table(s) and drop table(s) sql. > > you're right that an ide can auto-gen the getters/setters, but working > with > a uml tool and the current castormapping subtask, it would require the > following steps: > > (uml tool) > -define: > -class name > -class fields > -export class(es) > > (ide) > -auto-gen setters/getters > > (uml tool) > -import (re-engineer) from .java file having setters/getters > -add @castor tags to getter methods > -export class(es) > > (ide/ant) > -execute the castormapping subtask > > > basically what i am imagining is: > > (uml tool) > -define: > -class name > -class fields > -castor-specific tags (associate with the fields) > -any non-setter/getter business logic methods > > -export class(es) > > (ide/ant) > -execute new castor(mapping) subtask > -> generates castor mapping.xml > -> generates new .java files (uml-created .java file + > setters/getters) > -> generates create.sql and drop.sql > > > what do you think? > > i tried d/ling xdoc source from the cvs just now and tried executing the > "core" target in the build.xml file of the "xdoclet" module. however, i > got the following error: > > xjavadoc/build.xml [98] D:\dev\cvs\xdoclet\xjavadoc\${ant.home}\lib not > found. > > do you have any idea why it's going into the xjavadoc module's build.xml > file? > > > thanks. > > > At 11:43 02/06/26 +1000, you wrote: > > > -why are the @castor:field tags associated with methods and not the > actual > > > fields in the java class? is it possible to have them associated with > the > > > fields instead? reason being, when i first started using the tag, it > was > > > unclear whether the castor:field tag should be put before the > getField() > > > method or the setField() method. seems like associating the tag with > the > > > field might be easier...? > > > >there's no reason why this _couldn't_ be done, but it doesn't really add > >anything - as Ara pointed out, most decent IDE's will do this for you. > >Convention is that you put the xdoclet comments on the getter. > > > > > -is anyone working on a template to generate the create_tables.sql > (and > > > drop_tables.sql)? > > > >not that I know of. > > > > > -related to the above suggestion/question of associating @castor:field > >tags > > > with the java class' fields, is anyone working on a template/mechanism > > > whereby another key=value could be added to the @castor:field tag like > > > "createGetter=no" (default would be "yes") and "createSetter=no" > (again, > > > default would be "yes"), so that in one's original .java file, one > would > > > really only have to specify the class name, the fields (and its > associated > > > @castor:field tags), and any necessary *business* methods? in other > >words, > > > eliminate the need for writing the setters and getters altogether, and > >then > > > have the subtask automatically generate new .java files with the > > > automatically-generated (default) setters and getters... > > > >see above - isn't this the role of the IDE? > > > >cheers > >dim > > > > ------------------------------------------------------- > Sponsored by: > ThinkGeek at http://www.ThinkGeek.com/ > _______________________________________________ > Xdoclet-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-user ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
