No no and No :( Value Objects are not meant to that in no case If we do that we open a too big door. No offense I hope ;) Vincent
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf > Of Hicks, James > Sent: vendredi 19 avril 2002 0:33 > To: [EMAIL PROTECTED] > Subject: RE: [Xdoclet-user] attributes in data object > > > "What I am trying to do is allow lazy-loading of related > objects from data object. So it contains some finder-related > methods, which go and fetch the data." > > I like this idea: lazy loading Aggregated/Composed > ValueObjects from ValueObject. Maybe have the ValueObject > use the aggregated/composed beans util object to do a lookup > and retrieve the value object? Could solve the problem of > large data graphs, but at the cost of multiple network trips. > > Maybe add load-type="eager/lazy" to @ejb:value-object method > tag. The value object class would then have protected > methods for doing a lookup to get the data from another > entity bean. Would also need a way to tell the ValueObject > how to do the lookup: remote or local. The get method in the > entity bean would only load the aggregated/composed value > objects if the load-type is eager. > > Vincent, could this be implemented fairly easily? > > James Hicks > C.A.D.G. - Application Developer > BERRYDirect > Email: [EMAIL PROTECTED] > Phone: 936.462.4655 > Fax: 936.462.4655 > Pager: 936.568.4296 > I-Pager: [EMAIL PROTECTED] > > > -----Original Message----- > From: Michael Elizarov [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 18, 2002 4:25 PM > To: [EMAIL PROTECTED] > Subject: [Xdoclet-user] attributes in data object > > > I write bean classes, which have a hierarchy. All classes in > hierarchy > are abstract, and not used for actual CMP bean generation, except for > leaf nodes. I also use XDoclet to create data object. Quite > naturally, > data objects follow hierarchy parallel to one of the beans. > XDoclet puts > all attributes of parent classes in child classes and marks them as > protected. Can't agree that this does work, but this is not right.... > Any workaround? > > Also, I have an option of generating my data object myself. > If I do that > and exclude dataobject subtask (but keep all > dataobject-related tasks in > the Bean class), CMP generated will be different. It misses getData > method, which I like so much and do not want to write myself. Can > anything be done to about that? I like getData... > > The other problem with data object is that I want to emit > custom code in > this objects, and I can't describe the code using dataobject-custom.j > thing. What I am trying to do is allow lazy-loading of > related objects > from data object. So it contains some finder-related methods, > which go > and fetch the data. Body and names of the methods are not directly > related to attributes and methods of the data object class. > To "include" > my code in data objects I create intermediate classes, which have my > methods, and use them as parent classes for data objects. This solves > the problem, but is there a more elegant solution? > > Final (I did not want to write so much...) minor thing is > that for each > method or attribute declared as public, and for each > attribute defined > static or final in public interface jikes in pedantic mode says: > Warning: The use of the "final" (or "public", or "static" -- me) > modifier in this context is redundant and strongly discouraged as a > matter of style. It's annoying... > > Turns to be longer than expected... > > Thanks for all help and a nice tool. > Michael Elizarov > > > _______________________________________________ > Xdoclet-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > "The information transmitted is intended only for the person > or entity to which it is addressed and may contain > confidential, proprietary, and/or privileged material. Any > review, retransmission, dissemination, or other use of, or > taking of, any action in reliance upon this information by > persons or entities other than the intended recipient is > prohibited. If you received this in error, please contact the > sender and delete the material from all computers." > > _______________________________________________ > Xdoclet-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
