Arash,

Well, I have learned a little more about this.. that has simplified it for me. And, obviously, it is what the ejbdoclet designers intended. It just isn't all documented, yet. And, I probably have a knack for doing things the hard way as I try to hammer through the good old learning curve. But, anyway, I have had good success using the xxxxCMP classes that contain the generated get/set methods for the value objects (when CMR is used) when writing my own session facade. Still haven't really figured out how the generated facade works with value objects, though.

Before I figured this out, the mistake I was making was that I was writing my own set value object method in my beans. Instead, I declared my set value object method as abstract in my bean like this: "public abstract void setMyDataValue( MyDataValue vo)". (MyData is "declared" in the @ejb.value-object class level tag for the bean.) I tagged the abstract method setMyDataValue as an @ejb.interface-method, and the generated xxxxCMP bean contained everything needed to handle the getting/setting of value objects that contain CMR fields. Before, I was doing a lot of the "setting" myself because I was making the mistake of not declaring setMyDataValue at all, or not tagging it as an interface method, or just writing it myself and not declaring it as abstract. But, along the way, I stumbled into understanding how the ejbdoclet does it for you. Just part of the learning curve, I guess.

Tommy


At 09:40 AM 10/2/03 +0330, you wrote:
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



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