Re: [JBoss-user] Re: [Xdoclet-user] CMR and value objects
Dain Sundstrom wrote: I think this is a cool idea. I have seen a similar setup in ADO.NET. They pass an xml spec to the server that tells the server how deep to load the data. The other cool part of the MS implementation is it then allowed an xml diff to be sent back to update the object, which saves on wire time. Anyway, I think another piece to make this really efficient will be to auto set the load groups in the jbosscmp-jdbc.xml file. -dain the problems is to couple the load-groups (business tier, i think) with the presentantion tier. --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Re: [Xdoclet-user] CMR and value objects
Emerson Cargnin - SICREDI Serviços wrote: Dain Sundstrom wrote: I think this is a cool idea. I have seen a similar setup in ADO.NET. They pass an xml spec to the server that tells the server how deep to load the data. The other cool part of the MS implementation is it then allowed an xml diff to be sent back to update the object, which saves on wire time. Anyway, I think another piece to make this really efficient will be to auto set the load groups in the jbosscmp-jdbc.xml file. -dain the problems is to couple the load-groups (business tier, i think) with the presentantion tier. I have some ideas on how to restructure load-groups to make this easier, but it won't make it in until 4.0. -dain --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Re: [Xdoclet-user] CMR and value objects
I think this is a cool idea. I have seen a similar setup in ADO.NET. They pass an xml spec to the server that tells the server how deep to load the data. The other cool part of the MS implementation is it then allowed an xml diff to be sent back to update the object, which saves on wire time. Anyway, I think another piece to make this really efficient will be to auto set the load groups in the jbosscmp-jdbc.xml file. -dain 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 -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- 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
[JBoss-user] RE: [Xdoclet-user] CMR and value objects
Be very careful about autogenerating valueobject/dataobject. Let me summarize a pattern I came up with: - use one vo for one entity bean in ejb 1.1. xdoclet can generate everything for you. - in ejb2, 1-vo-1-ejb is not that useful, use local interfaces and start a UserTransaction in your base Action class in web tier. - Now if you are going to transfer some data for display/etc to a remote client (say a swing client) or you want to display some data in a web page and you don't want to do sophisticated traverses in ejbs or pass a huge graph of vo instances around then create a XyzListingRow class which is a simple flat class which only contains whatever the caller needs in the display. The attributes of this listing class are grabbed from a graph of entity objects. It's a one listing class - n ejbs mapping. Sure you should code it yourself and code generation doesn't help here, though it's possible but at least xdoclet doesn't provide it yet. An alternative approach is going to the db directly and filling the listing class without loading ejbs. It's useful for sophisticated queries. I tend to use this strategy for search operations that return tens of listing objects, but in some cases it's even useful for single object editing scenarios too. So even if valueobject//dataobject/ subtasks are provided by xdoclet but they are only for a one to one mapping of vo-ejbs. Don't let xdoclet dictate the architecture! Use code generation wisely :-) Ara. -Original Message- From: [EMAIL PROTECTED] [mailto:xdoclet-user- [EMAIL PROTECTED]] On Behalf Of Emerson Cargnin - SICREDI Serviços Sent: Thursday, July 25, 2002 12:31 AM To: David Ward Cc: Roland; [EMAIL PROTECTED]; jboss- [EMAIL PROTECTED] Subject: Re: [Xdoclet-user] CMR and value objects 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
[JBoss-user] Re: [Xdoclet-user] CMR and value objects
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
[JBoss-user] Re: [Xdoclet-user] CMR and value objects
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.
[JBoss-user] Re: [Xdoclet-user] CMR and value objects
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
