David Ward wrote:
> That's an interesting idea; I have to think about it some more. Your
> GenericVO sounds cool, but it sounds like I lose type.
well, when from the client view point , it just call a kind of cast
class that translate the GenericVO (HashMap) into a collection of
specific vo , like :
VOCollection lista = new VOCollection( collection , BuscaPracaVO.class);
this class uses reflection to set the fields of the concrete vo.
> 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...
> 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 :
>> <screen name="SCR001">
>> <command name="getPraca">
>> <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"/>
>> 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,
>>> Roland wrote:
>>>> Is there a best practice/pattern for creating value objects for
>>>> 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.
>>> This sf.net email is sponsored by:ThinkGeek
>>> Welcome to geek heaven.
>>> Xdoclet-user mailing list
Emerson Cargnin - MSA
SICREDI - Tel : 3358-4860