That's an interesting idea; I have to think about it some more. Your GenericVO sounds cool, but it sounds like I lose type.
XDoclet supports creating multiple valueobjects per bean, you just define what you want included in which valueobject (like Normal, Light, Full). The problem there that I guess exists but I personally haven't explored is once you specify you want a relation included in your VO, how far does it traverse? Default is all (which is serious overkill). Modifying valueobject.xdt to take an int on a relationship representing levels to traverse seems hacky, and it doesn't take into consideration how deep should the possible second relationship be loaded. Also, what if the child has two different rels and you want to load 1 level deep on one rel and 2 levels deep on the other? How can a client pass in something that differentiates what it wants? You're definately right. It is the worst problem with vo's. Some day soon I'm going to have to buckle down and think of a slick way to do this. In the mean time, does anyone have any success stories on how they tackled this problem? I've heard lots of people complain about it... David -- Emerson Cargnin - SICREDI Servi�os wrote: > I think the worst problem when defining the approaches to vo's is what > how deep you go in the relations. I mean, if i need just the main data > of an entity or if I need the description of related entities in the > same request, you have to find the trade-off to get the middle point of > how many data will be sent for a request. > > We are creating a bank system that will run through satellite lines, > about a 1 second delay between central (JBoss) and bank offices (700 > with jboss/tomcat). That said, we had to create a way to avoid > transmiting data that would not be used, and not having to make a lot of > remote call to get all data to populate the view (struts too). > > We made a framework that works over a xml defining the data necessary > for each remote call, so that in the server the framework navigates > through the bean and generates an object of GenericVO class (basically a > HashMap), then the client creates a concrete vo collection using this > GenericVO. > > The business delegate will be used passing it a screen name and it > specific parameters. > > example of the view xml : > > <screenConfiguration> > <screen name="SCR001"> > <command name="getPraca"> > <fields> > <field name="oid" source="Oid"/> > <field name="uf" source="Municipio.Uf.Oid"/> > <field name="municipio" source="Municipio.Oid"/> > <field name="endereco" source="Endereco"/> > <field name="cepInicial" source="CepInicial"/> > <field name="cepFinal" source="CepFinal"/> > <field name="situacao" source="Situacao"/> > </fields> > </command> > </screen> > </screenConfiguration> > > in this example the method getPraca will bring some PracaEJB fields, and > some related fields, as Municipio.Uf.Oid that gets the MunicipioEJB > relation from PracEJB, UFEJB relation from MunicipioEJB and at last Oid > field from UFEJB. > > What you all think about this approach??? any sugestion, want more > details of the solution ?? > > obs: sorry sending for jboss-user list, but i thought this subject > coul'd be wanted there too. > > David Ward wrote: > >> I suggest using xdoclet from cvs, then use @value-object tags in your >> ejb on the persistent fields and relationship fields you want included. >> Then, in your build.xml, use the <valueobject/> and <entitycmp/> tags. >> The valueobject tag will generate valueobjects for you that also >> handle aggregations/compositions of other valueobjects, with helpful >> add,remove,update methods. Then, the entitycmp tag will create an >> abstract subclass of your ejb that has similar helpful methods to >> persist your valueobject data (including traversing relationships). >> Just make sure to make abstract methods with @ejb:interface-method on >> them in your ejb so you can make use of them from your session facade. >> >> Hope this helps, >> David >> >> -- >> >> Roland wrote: >> >>> Hello, >>> >>> Is there a best practice/pattern for creating value objects for entities >>> with CMR fields/relationships?? >>> >>> I am migrating to CMP 2.0 and am having trouble deciding how to use >>> value objects. That is, previously when I used our own relationship >>> framework, we would have simple accessors for relationships. Now with >>> CMP 2.0 we have local objects (and collections of local objects) as >>> return types. >>> >>> What is the best practice for creating these value objects? Moreover, >>> we have a session fa�ade which passes the vo to a business delegate up >>> to our controller layer (Struts actions). Isn't it bad form to touch >>> your model (local objects) from the controller layer? >>> >>> Don't know if this being asked in the wrong place or not, but I'd >>> appreciate any input out there. Examples are also welcome. >>> >>> Regards, >>> RC >> >> >> >> >> >> >> ------------------------------------------------------- >> 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 >> >> > > -- --------------------- David Ward [EMAIL PROTECTED] http://www.dotech.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
