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

[David W. <dav...@do...>]

That's an interesting idea; I have to think about it some more.  Your=20
GenericVO sounds cool, but it sounds like I lose type.

XDoclet supports creating multiple valueobjects per bean, you just=20
define what you want included in which valueobject (like Normal, Light,=20
Full).  The problem there that I guess exists but I personally haven't=20
explored is once you specify you want a relation included in your VO,=20
how far does it traverse?  Default is all (which is serious overkill).=20
Modifying valueobject.xdt to take an int on a relationship representing=20
levels to traverse seems hacky, and it doesn't take into consideration=20
how deep should the possible second relationship be loaded.  Also, what=20
if the child has two different rels and you want to load 1 level deep on=20
one rel and 2 levels deep on the other?  How can a client pass in=20
something that differentiates what it wants?

You're definately right.  It is the worst problem with vo's.  Some day=20
soon I'm going to have to buckle down and think of a slick way to do=20
this.  In the mean time, does anyone have any success stories on how=20
they tackled this problem?  I've heard lots of people complain about it...

David

--

Emerson Cargnin - SICREDI Servi=E7os wrote:
> I think the worst problem when defining the approaches to vo's is what=20
> how deep you go in the relations. I mean, if i need just the main data=20
> of an entity or if I need the description of related entities in the=20
> same request, you have to find the trade-off to get the middle point of=
=20
> how many data will be sent for a request.
>=20
> We are creating a bank system that will run through satellite lines,=20
> about a 1 second delay between central (JBoss) and bank offices (700=20
> with jboss/tomcat). That said, we had to create a way to avoid=20
> transmiting data that would not be used, and not having to make a lot o=
f=20
>  remote call to get all data to populate the view (struts too).
>=20
> We made a framework that works over a xml defining the data necessary=20
> for each remote call, so that in the server the framework navigates=20
> through the bean and generates an object of GenericVO class (basically =
a=20
> HashMap), then the client creates a concrete vo collection using this=20
> GenericVO.
>=20
> The business delegate will be used passing it a screen name and it=20
> specific parameters.
>=20
> example of the view xml :
>=20
> <screenConfiguration>
>   <screen name=3D"SCR001">
>     <command name=3D"getPraca">
>       <fields>
>         <field name=3D"oid" source=3D"Oid"/>
>         <field name=3D"uf" source=3D"Municipio.Uf.Oid"/>
>         <field name=3D"municipio" source=3D"Municipio.Oid"/>
>         <field name=3D"endereco" source=3D"Endereco"/>
>         <field name=3D"cepInicial" source=3D"CepInicial"/>
>         <field name=3D"cepFinal" source=3D"CepFinal"/>
>         <field name=3D"situacao" source=3D"Situacao"/>
>       </fields>
>     </command>
>   </screen>
> </screenConfiguration>
>=20
> in this example the method getPraca will bring some PracaEJB fields, an=
d=20
> some related fields, as Municipio.Uf.Oid that gets the MunicipioEJB=20
> relation from PracEJB, UFEJB relation from MunicipioEJB and at last Oid=
=20
> field from UFEJB.
>=20
> What you all think about this approach??? any sugestion, want more=20
> details of the solution ??
>=20
> obs: sorry sending for jboss-user list, but i thought this subject=20
> coul'd be wanted there too.
>=20
> David Ward wrote:
>=20
>> I suggest using xdoclet from cvs, then use @value-object tags in your=20
>> ejb on the persistent fields and relationship fields you want included.
>> Then, in your build.xml, use the <valueobject/> and <entitycmp/> tags.=
=20
>> The valueobject tag will generate valueobjects for you that also=20
>> handle aggregations/compositions of other valueobjects, with helpful=20
>> add,remove,update methods.  Then, the entitycmp tag will create an=20
>> abstract subclass of your ejb that has similar helpful methods to=20
>> persist your valueobject data (including traversing relationships).=20
>> Just make sure to make abstract methods with @ejb:interface-method on=20
>> them in your ejb so you can make use of them from your session facade.
>>
>> Hope this helps,
>> David
>>
>> --=20
>>
>> Roland wrote:
>>
>>> Hello,
>>>
>>> Is there a best practice/pattern for creating value objects for entit=
ies
>>> 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 wit=
h
>>> 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=E7ade 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
>> Xdo...@li...
>> https://lists.sourceforge.net/lists/listinfo/xdoclet-user
>>
>>
>=20
>=20


--=20

---------------------
David Ward
dav...@do...
http://www.dotech.com