Richard,
I see what you are saying about the comments in generated classes.
Regarding the naming convention for missing role names, here is a
snippet from my VSL:
#set ($targetrolename = $adata.target.roleName)
#if ($targetrolename == "The$adata.target.type.name")
#set ($targetrolename = $adata.target.type.name)
#end
#set ($sourcerolename = $adata.source.roleName)
#if ($sourcerolename == "The$adata.source.type.name")
#set ($sourcerolename = $adata.source.type.name)
#end
I know it is making a big assumption, but I think it's reasonable. On
the rare occasion that a class name starts with "The", you could set the
role name. Probably the best way though is to change the java code (it
isn't done in the XMI.) I haven't found where it is done yet.
Regards,
David Wann.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
SourceForge.net
Sent: Thursday, 26 June 2003 7:59 PM
To: [EMAIL PROTECTED]
Subject: [Andromda-devel] [ andromda-Patches-748970 ] Improved EJB
cartridge
Patches item #748970, was opened at 2003-06-04 16:17
Message generated for change (Comment added) made by rkunze
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=536547&aid=748970&grou
p_id=73047
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Kunze (rkunze)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improved EJB cartridge
Initial Comment:
Attached is an improved EJB cartridge that provides the following
features above the current EJB cartridge:
- Support for inheritance: If an <<Entity>> or <<Service>> class
extends another class, this is reflected in the generated EJB. If the
super class itself is an <<Entity>> or <<Service>>, the generated
*Bean extends the *BeanInmpl of the super class. In all other
cases, the generated *Bean extends the given super class.
- Support for arbitrary primary key types: If a <<Entity>> class or
any of its super classes has a dependency that is stereotyped as
<<PrimaryKey>>, the provider of that dependency is used as the
primary key type. If no such dependency exists but the class (or a
super class) has a field stereotyped as <<PrimaryKey>>, the type
of this field is used as primary key type. If neither a PK dependency
nor a PK field is found, the primary key type defaults to
"java.lang.String"
- Support for "abstract EJBs": If an <<Entity>> or <<Service>> is
declared abstract in the model, the "@ejb.bean generate" attribute
is set to "false" in the *Bean class. This means that XDoclet will
generate home and component interfaces for this class, but no
deployment descriptor entries.
- Improved support for attributes:
- For attributes that are marked readonly, the setter method is
not exposed to the component interface.
- Non-public attributes are not exposed to the component
interface.
- Attributes marked as both static and read-only are treated as
constants. For each constant, a getter method is created that
returns the initial value of the attribute as defined in the model.
If the constant is public, the getter is exposed on both the
home and component interfaces (i.e. the getter is marked as
"@ejb.interface-method", and an additional ejbHomeGet*()
method is generated). If the constant is stereotyped as
<<EnvEntry>>, an corresponding "@ejb.env-entry" tag is
generated and the getter returns the value of this entry
- Improved support for relations:
- Relation names are constructed based on the model
- Relations of an abstract <<Entity>> are "inherited" by
all derived <<Entity>> classes: For every such relation, a
corresponding get* method and "@ejb.relation" tag is generated
in the derived *Bean class. The only restriction is that the
navigable target of a relation must not be abstract. If it is
abstract, the generator stops with an exception.
- Improved support for operations:
- Non-public operations methods are not exposed on the
interfaces
- Operations declared as both public and static are interpreted as
home methods, i.e. the method name of the generated method is
prefixed with "ejbHome", and the method is marked as
"@ejb.home-method" instead of "@ejb.interface-method"
----------------------------------------------------------------------
>Comment By: Richard Kunze (rkunze)
Date: 2003-06-26 09:59
Message:
Logged In: YES
user_id=785616
Hi nobody :-)
thanks for evaluating my EJB package and for your comments - I think
they are quite valuable. I'd appreciate taking the discussion to one of
the
mailing lists, though (preferably andromda-devel, because the patch
messages are sent to this list), because the mailing lists are way more
comfortable for discussions than the web interfaces of the bugtracking
system.
Anyway, here are a few reasons for why I implemented some the things
the way I did.
> the class comments are confusing. I think they should be
> output as they are appear the model
The problem with that is IMO that there are far mor classes in the
generated code than in the model, and all of these classes are
documented
by e.g. Javadoc. I think it is confusing to have identical comments on
all of
these classes, with no indication of what class is fulfilling what role
in the
implementation. This is especially true for the *Bean/*BeanImpl pair,
which
doesn't make much sense if you don't know that the *Bean is regenerated
from the model and the *BeanImpl holds manual changes.
Of course, the comment style is very much to my personal taste, and I'm
well aware that others may or may not like it. I think the best solution
is
some system that allows users of the cartridge to easily override parts
of
a template (e.g. the comments :-) without changing the template itself.
I'm not quite sure how to do this best in velocity, though.
> It would be good to configure the separator used in building
> the table name. Even better, it would be good to base on a
> configurable template. e.g. "T_${class.name}"
Good idea, and this goes along the same lines as I have been thinking
about for overriding parts of the template. The problem with this
approach
is, you risk ending up with thousands of little template snippets that
are
difficult to understand. Some of the XDoclet modules are a prime example
for this - you can customize pretty much everything, but it's difficult
to
find out which template snippet is supposed to override what :-)
But I'll probably end up with something like a set of class specific
templates that override parts of the main template.
> In my template, when there is no role name, I've made the
> CMR fields named the same as the class at the other end
> (with the first letter lower case of course), rather
> than "the<classname>". I think this is a reasonable
> default.
Yes, I think so as well. The problem is, the default names with with
"the"
come directly from the model (if you look at EntityBean.vsl, you'll see
that
I simply take the target role name here), and I'm not sure what puts
them
there. If I could be certain that default relation role names are always
"The<targetname>", I could change the default to be something else. But
as I said, I have no idea where the default is assigned, and I'm
reluctant to
change the names based on a guess.
> There are some other issues with my particular model,
> including the fact that I let XDoclet generate value objects
> and include @ejb.value-object tags in the template. I'll think
> about this a bit more before I comment.
Include it as a tagged value on the class in the UML model - all tagged
values that are not handled specifically by the template are copied
through
to the java sources.
> I guess these global parameters should belong as tags on the
> model.
Sounds like a good idea to me.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2003-06-26 07:43
Message:
Logged In: NO
I have run this cartridge against my model and have the
following comments:
* the class comments are confusing. I think they should be
output as they are appear the model
* It would be good to configure the separator used in building
the table name. Even better, it would be good to base on a
configurable template. e.g. "T_${class.name}"
* In my template, when there is no role name, I've made the
CMR fields named the same as the class at the other end
(with the first letter lower case of course), rather
than "the<classname>". I think this is a reasonable default.
Once again, it would be ideal if the naming convention could
be defined as a pattern.
* Naming convention for foriegn keys: same as above.
* Naming convention for JNDI: same deal.
There are some other issues with my particular model,
including the fact that I let XDoclet generate value objects
and include @ejb.value-object tags in the template. I'll think
about this a bit more before I comment.
I guess these global parameters should belong as tags on the
model.
In general, I think the changes are great.
----------------------------------------------------------------------
Comment By: Richard Kunze (rkunze)
Date: 2003-06-25 09:43
Message:
Logged In: YES
user_id=785616
New version for the improved EJB cartridge. Still very much work in
progress.
Changes to the previous version:
- Tons of bug fixes
- Support for arbitrary super interfaces for the bean component
interface:
The bean's component interface extends all interfaces that are realized
by
the corresponding <<Entity>> or <<Service>> class in UML.
- Generate home and component interfaces directly because XDoclet gets
confused by the *Bean/*BeanImpl pairs and generates the wrong
inheritance hierarchy, doesn't support multiple super interfaces for a
component interface and cannot properly handle accessors for CMR
relations that are defined on an abstract entity.
- Add support for <<ResourceRef>> dependencies. For every
<<ResourceRef>> class dependency, an "@ejb.resource-ref" class tag is
generated. The name of the referenced resource is the name of the
dependency if given or the unqualified class name of the supplier if the
dependency has no name. Along with the resource-ref tag, a matching
getter to access the dependency is generated.
- Support for the tagged value "@andromda.ejb.generateCMR" on
relations. If this tagged value is set to "false", no CMR xdoclet tags
will be
generated for this relation. get/set-Methods are still generated though
-
they have to be implemented in the *BeanImpl class.
- Preliminary support for generating SQL scripts to create/drop the
database structure. This is a quick hack to support my current project
and
will probably be dropped again in the future because I think Xdoclet is
better at generating that kind of stuff.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=536547&aid=748970&grou
p_id=73047
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Andromda-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/andromda-devel
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Andromda-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/andromda-devel
