No no and No (or maybe I don't read this mail correctly ?) VO are constrcuted by the "aggregator" or the "compositor" entity bean by asking for the VO in "aggregated" or "composed" entity beans. It do all that because if you need the VO it means you need all data inside so why wait before giving it. If the client do not need some data, create another VO. Floyd (TSS) says that many big projects have hundreds of VO, Xdoclet facilitates their creation in the simplest way (I think) where the responsibility is : in the entity bean. Because they are many of them, what they do should really be brainless : javabeans and no more. Does this make sense ? Vincent
> Oops, I missed the point here. You were talking about value objects > whereas I was diggin' into CMP. No offense. > > > tom > > > Thomas Quas wrote: > > > > Just a few thoughts... > > > > Hicks, James wrote: > > > >> "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. > > > > > > Wouldn't that be the job of a good application server? As far as I > > understand this technology, the EJB container could do a > much better job > > handling the lazy initialization for releations than a code > > generator--not meant in a negative way here--ever will. > > > >> > >> 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. > > > > > > I can see that with incorporating more such features in the near > > future > > XDoclet--and more important: my Bean source code--becomes > more difficult > > to manage than the app server itself. That would be the > point where a > > great tool becomes useless. > > > > > > Just my $0.02, tom > > > > > > _______________________________________________ > > 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 > > _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
