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
