Too complicated for me!And I shouldn't call it easily for sure. What if add a 
method to oneside ejb to call the getManySide() and return a collection of 
manySideVO?
And I wonder why facade is using data object? Isn't it deprecaterd?

On Wednesday 01 October 2003 15:59, Tommy Cox wrote:
> "easily" is relative. as a new user of 1.2 b3, here is how I do it.
> (this assumes that you are not going to use the @ejb.facade tag)
>
> Assuming you have setup the aggregrate/compose attributes with the
> method tags as described in
> http://xdoclet.sourceforge.net/valueobjects.html, You will have to add a
> getValueObject method to the local EJB on the one side that converts the
> collection of EJB references to the many side to a collection of value
> objects that is stored in the one side's value object (whew!).
>
> public OneSideValue getOneSideValueObject() {
>     OneSideValue oneSideValueObj = new OneSideValue();
>     // You are already getting a collection like this one that is a list
> of EJB references to the many side.
>     Collection listofEJBReferencesOnTheManySide =
> myOneSideEJBWithCMR.getListOfEJBReferences();
>     // All you have to do is traverse the many side list of references
> and execute your getValueObject
>     // method and store it in the auto genenerated value obj for the
> one-side.
>     Iterator it = listofEJBReferencesOnTheManySide.iterator();
>     while (it.hasNext()) {
>        ManySideLocalRef  eachRef = (ManySideLocalRef) it.next();
>        oneSideValueObj.add(eachRef.getValueObject());
>     }
>     // Clear the list of "added" value objects so you can tell whether
> the client adds more.
>     // This won't clear the list of value objects you just added, only
> the list of "added" items.
>     // See the getAddedXXXXX() function in your generatedvalue object.
>     oneSideValueObj.getAddedXXXX().clear();
>
>     return valueObj
> }
>
> I would suggest first getting everything to compile and deploy using
> value object attributes aggregate or compose. Then, start building the
> getvalueobject method for the One Side EJB. You will run into lots of
> glitches. It isn't "easy", but if you are doing a lot of beans it will
> reduce redundant coding. Also you will find that the auto-naming of the
> functions adds an "s" where it isn't logically needed. There is a bit of
> a learning curve in setting up your ejbdoclet tags for the CMR.
>
> Also, read the docs and try @ejb.facade and the <entityfacade> ant task.
> It does a lot of this for you. However, from just looking at the docs
> and the autogenerated code, it appears that right now in version 1.2 b3
> is that it uses data objects - not value objects.
>
> On Wed, 2003-10-01 at 03:46, Arash Bijanzadeh wrote:
> > Hi,
> > When I am using  CMR to get a many-side collection of related object;
> > what I get in client side is a collection of Local interface. Is there
> > any way to easily get the valueobjects from this collection?
> >
> > Thanks in advance
> >
> >
> > -------------------------------------------------------
> > 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


-------------------------------------------------------
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

Reply via email to