I've just been trying this out with XDoclet 1.2 beta 1 and I have a couple of questions :
1. Is the "members-name" attribute being used ? The code that is generated doesn't seem to use this attribute at all - instead the name of method used to get the value object representation from the bean is based on the value object name (the example below works because the name of the value object "ReceipientValue" is the same as the name of the method "RecipientValue"_ - in my case I always use "getValueObject" as the full method name, and this can't be specified using the current implementation. 2. Why do the generated value objects have methods that use typed arrays for CMRs represnting "many" relationships ? Would it be possible for the generated value object to code to use Collections instead of arrays (even as a choice that can be configured, rather than the default) ? I ask this because I have a utility that generates value object trees dynamically based on a description of the branches to be included - rather than using multiple static value object classes definied using @ejb:value-object, just one value object class is defined that is used in all use cases - only the amount of data that is included in the tree changes. I've used this previously with Weblogic/EJBGen - in that configuration, EJBGen uses Collections (rather than arrays) in the CMR methods created on the Value object classes - which makes the implementation of the tree builder more straightforward... Cheers, Gavin. -----Original Message----- From: Marcus Brito [mailto:[EMAIL PROTECTED]] Sent: Saturday, 14 September 2002 2:59 AM To: Niclas Olofsson Cc: [EMAIL PROTECTED] Subject: Re: [Xdoclet-user] CMR and VO's Niclas Olofsson wrote: Here we go: > * @ejb.value-object > * compose="com.ismobile.dispatcher.ejb.recipient.RecipientValue" > * compose-name="Group" > * match="Group" > * members="com.ismobile.dispatcher.ejb.recipient.RecipientLocal" > * members-name="RecipientValue" > * relation="external" > * type="java.util.Collection" > */ > public abstract Collection getRecipients(); compose: the type of the composed value. (It's OK in your code) compose-name: the property name (in the singular) for the composed values. It's wrong in your tags. You should use compose-name="Recipient" on something like this, so you end with a getRecepients() method on your GroupValue class. members: the type of the composed entity. It's the type of the objects that should be in the Collection return by the EJB property you're tagging (It's OK in your code). members-name: the name of the property that should be used to get the value object from the Collection members (It's OK in your code). relation: use "external" if this relationship can be modified outside the scope if this getter. You should *always* use relation="external" for CMR relationships. It's OK in your code. type: the type of the collection returned by the EJB property you're tagging. It's OK in your code. > - aggregate/compose I've explained compose above. The difference between aggregate and compose is the following: compose objects are completly dependent objects. The composed object cannot exist without the parent. Aggregate objects does not has this strong dependency between then. What it means for value objects? It means that if you use composition, the generated VO setter will *create* and *remove* objects. So, in your code, if you use GroupValue.addRecipient(someRecipient) and latter use GroupEJB.setGroupValue(group), this setter wil call RecipientEJB.create(someRecipient) and then call GroupEJB.getRecipients().add() to add the returned object to the relationship. For aggregation, the generated VO setter will just add and remove objects from the relationship, but not create or remove the objects proper. So, in you code, if you've used aggregate instead of compose, if you use GroupValue.addRecipient(someRecipient) and latter use GroupEJB.setGroupValue(group), this setter will call RecipientEJB.findByPrimaryKey(someRecipient.getPrimaryKey()) and then call GroupEJB.getRecipients.add() to add the returned object to the relationship. Try for yourself. Change compose="xxx" for aggregate="xxx" and compose-name="xxx" for aggregate-name="xxx" and look at the generated code. Well, I know this is not the better explanation I could give away. I'll be working on value objects documentation before we release 1.2. -- Pazu <[EMAIL PROTECTED]> ------------------------------------------------------- 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 ------------------------------------------------------- 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
