[JBoss-user] Re: [Xdoclet-user] CMR and value objects

[Emerson Cargnin - SICREDI Serviços]

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...
> 
> 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
>>>
>>>
>>
>>
> 
> 


-- 
Emerson Cargnin - MSA
SICREDI - Tel : 3358-4860



-------------------------------------------------------
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