On Fri, Sep 20, 2002 at 12:08:04PM -0400, David Ward wrote: > Andreas Leitner wrote: > >On Thu, Sep 19, 2002 at 10:12:09AM -0400, David Ward wrote: > > > > > >>Let me know what you end up doing, as I'm interested in better and > >>better designs. Sorry about the typos - it wasn't a copy/paste so it > >>was bound to be imperfect. > > > > > >I will! > > > >Btw, I have one more question regarding trees. Now I have implemented the > >tree as you suggested, > >with the finder to tell about the children. > > > >Is it somehow possible to send the complete hirachy over to the user (in > >form of the top level value object)? > >Because with the current design, I can give the user the top level node, > >for the children he has to contact the server again (invoking indirectly > >the finder method). For the client to put the tree ie into a swing tree > >view, he needs to convert the data once again - something which he > >shouldn't have to do - that's what the value objects are there for (IMO). > > > >any ideas, > >Andreas > > -- > > Yeah, in my mind that's the biggest downfall of the > parent-only-relation/finder-for-children design. I haven't addressed it > in my project yet - but I do have a plan. I'm probably going to > sub-class the xdoclet-generated VO's with one that simply adds the > children heirarchy. I will populate it in the stateless session bean so > the client only has to make one call for all of it to the server. The > thing that still stinks about it is it will still end up being several > database calls. At least it will be done in the scope of a single > Transaction, though. > > *Please* let me know if you figure out something better.
Well, looking at it from a distance, I really don't see how using a finder instead of a bi-directional relation is better, except for the reason that for the bi-directional version the value objects are generated incorectly. Sooooo, let's fix it instead of doing it the wrong way (correct me if I am wrong). Currently I have a bidirectional relation in place that hasn't got the 'local reference mentioned in value object' problem anymore. Now the problem occures only at runtime, where when I ask a entity which has a (non null) parent to get a value object it goes into a infinite recursion: 1) I ask entity for value object 2) entity asks parent for value object 3) entity asks children (and thus the original entity) for value objects 4) repeat at step 2 (with exact same state -> infinite recursion) What I would consider (for my constrains) a reasonable and scalable solution is a bidirectional mapping that does not have this infitine recursion. But there is one more problem with that approach: A tree could be a quite large, so in some cases it might be overkill to fetch the complete tree from the server - let me sidestep to what I would also like to see for regular finders of non-tree like entities: I'd issue a home.findBySomeCriteria (...criteria..., pageSize); Now, what I would get would be some sort of Object, that implements at least the 'List' interface. It would transfere all rows that are met by '...criteria...', but at maximum 'pageSize' rows. If the client tries to read more than 'pageSize' rows the List-like object would automatically fetch the next 'pageSize' rows from the server - but this would be completly transparent for the client. Same would go for the tree, except that here we would not deal with a 'pageSize' (a line, that marks several rows), but rather an elipse, that marks a closed region in the tree. The elipse would have two parameters, 'depth' and 'width'. 'depth' would specify how many items to prefetch down and up the hirachy, while 'widht' would specify how far to reach for siblings (left and right). Does that sound reasonable? Any ideas? Andreas PS: Unfortunatly time does not allow us to experiemnt/implement (witch) such a strategy right now, but we would like to keep it an option for later on. Nevertheless I am sending this mail - maybe some interested party has more time available. ------------------------------------------------------- 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
