Re: Compuond objects
On 9 November 2015 at 19:11, Cesar Lugo wrote: > Dan, this statement you made cached my attention, s/cached/caught > as it might help reduce foreign keys and make the application more > maintainable: > It doesn't reduce them, but it does move them out of the "child" table and into the join table. > > "I prefer to use a join table for unidirectional, but FK for > bidirectional; that way the database tables model the domain classes quite > nicely (in particular, with a unidirectional and a join table the child > table doesn't "know" about its parent)." > > How can I implement this with Isis / Datanucleous? > > http://www.datanucleus.org/products/accessplatform/jdo/orm/one_to_many_collection.html > Cesar. > > -Original Message- > From: Dan Haywood [mailto:d...@haywood-associates.co.uk] > Sent: Friday, November 6, 2015 2:03 AM > To: users; David Tildesley > Subject: Re: Compuond objects > > Hi David, > thanks for chipping in on this thread. To answer your last question, I > think I agree very broadly with your analysis. More detail within... > > > On 5 November 2015 at 20:08, David Tildesley wrote: > > > Hi Cesar, > > I think you are saying you currently have : > > > > Business - --> 1..* BusinessLocation Where one way navigation. > > Whereas in the first use case you want two way navigation so it looks > > like > > this: > > Business 1 <> 1..* BusinessLocation > > > > > > > > So if you have a BusinessLocation "in focus" then it is associated to > > single Business. This two way navigation between objects has always > > been an "expensive thing" to build - hence it is normally avoided > > unless the tradeoff suggests it should be done - but maybe ISIS makes > this easier. > > > > With JDO/DataNucleus, bidirectional relationships are no more difficult > than unidirectional. With both bidirectional and undirectional, DN > supports either using a join table to hold the tuples between parent/child, > or alternatively a more traditional FK in the child. I prefer to use a > join table for unidirectional, but FK for bidirectional; that way the > database tables model the domain classes quite nicely (in particular, with > a unidirectional and a join table the child table doesn't "know" about its > parent). > > > > > But it sounds like you want a view which consolidates the information > > from one graph instance of the above into a single "form". So I > > believe the correct answer is yes: that is what the View Model is for. > > In terms of update behaviour - you need to add the operation on the > > View Model that explicitly sets the values on the domain object graph > > and persists them - I would suggest a single operation on Business for > > that purpose because Business should know about it's BusinessLocations > > - you pass the user values in including the BusinessLocation.id > > because Business has to know which BusinessLocation to update. > > Put all your View models in a separate package - they are not part of > > the domain. Make sure all the domain behaviour belongs to the domain > > objects and doesn't leak out into View objects. Never reference a View > > Model from the Domain Model the dependency should be View --> Domain > > and never the other way around. Domain is stable, View is volatile. > > Just create as many View Models as you need for the UI - after all that > is what they are for. > > > What you are saying is true in this case, but you'll remember a long > thread from about a year ago when we enumerated various different "types" > of view model. We came to the conclusion that the view model > implementation is also appropriate for what are really domain entities that > just happen to be persisted externally, eg over a SOAP service. > > We express this using the @DomainObject(nature=...) attribute [1] > > > > > In fact your application may not need to expose any domain objects as > > naked objects - but then again, there may some user experience > > downside to that (e.g. having to explicit operation for update). > > Folk - correct me if I am wrong - I need to catch up with where ISIS > > is currently at and so having folk correct me is very welcome for my > education. > > > > As per. If you're just catching up, check out: > > - changes to Isis itself in the release notes [2] ; 1.10.0 is imminent. > - (non ASF) Isis addons, [3] - for reusable cross-cutting concerns > - (non ASF) incode catalog, [4] - for reusable busi
Re: Compuond objects
We frequently use a viewmodel to import and export data to excel. The viewmodel is the intermediate between excel and the domain objects. You can find multiple examples in Estatio's app/services package [1], start with exploring turnover rent upload [2]. Notice that it's not in the dom project eg. not part of the domain. [1] https://github.com/estatio/estatio/tree/master/estatioapp/app/src/main/java/org/estatio/app/services [2] https://github.com/estatio/estatio/tree/master/estatioapp/app/src/main/java/org/estatio/app/services/lease/turnoverrent On 9 November 2015 at 20:04, Cesar Lugo wrote: > Hello Jerome. Thank you for providing this sample, it will be useful for > some purposes. In this case, because I want the view model to be updatable, > I don't want to move that logic to the database, but keep it in the Java > methods. Is there by any chance any sample you might think of where there > is a ViewModel that is not linked to a database view, and combines some of > the objects in the app? > > Cesar. > > -Original Message- > From: Jeroen van der Wal [mailto:jer...@stromboli.it] > Sent: Thursday, November 5, 2015 11:20 AM > To: users > Subject: Re: Compuond objects > > Here's an example where a viewmodel uses a database view: > > > https://github.com/estatio/estatio/blob/master/estatioapp/dom/src/main/java/org/estatio/dom/invoice/viewmodel/InvoiceSummaryForInvoiceRun.java > > On 5 November 2015 at 17:42, Dan Haywood > wrote: > > > It is possible to map java domain classes to views instead of tables. > > > > Estatio has a couple of examples... perhaps Jeroen could dig out a > > link for you (I'm typing this on my phone). > > > > Alternatively, yes, you could use view models. These then > > programmatically combine the data. > > > > On your particular use case I would inject the repositories for the > > "backing entities". > > > > One point to beat in mind is that Isis will handle view models with > > collections, it only serializes the state of the view model's > > properties (the determine the url of the view model). The workaround > > is to make the collection derived, using > > @Collection(notPersisted=true), and return is results by requerying the > appropriate repository. > > > > Again, Estatio has some examples, I think > > > > Hth > > Dan. > > On 5 Nov 2015 15:16, "Cesar Lugo" wrote: > > > > > Hello. I have the need to create some objects that are compound from > > > some other domain objects (similar to a "view" in a relational > > > database, updatable views). Let's say I have Business with > > > businessId and name properties, 1:n to another entity named > > > BusinessLocation with properties businessLocationId and name and > > > address properties (to keep things simple for now). So, for example, > > > I need to create a new object that is BuisinessLocationView, which > > > contains BuinessLocation.id, BusinessLocation.name, Business.id and > > > Buiness.name . Then, in some > > cases, > > > I > > > want to use such views like BusinessLocationView as a collection > > > within Business, and as a standalone collection, and also have the > > > ability to update its fields so the corresponding entities are > > > updated with the changes (Business and BusinessLocation), and in > > > some cases even add a new view > > like > > > BusinessLocationView so it adds a new BusinessLocation. > > > > > > > > > > > > Is there a way to do this? Is that what @ViewModel is for? > > > > > > > > > > > > I would appreciate If you could point me to any sample that might help. > > > > > > > > > > > > Cesar. > > > > > > > > > > > > > > > > > > > > > > > > --- > > > This email has been checked for viruses by Avast antivirus software. > > > https://www.avast.com/antivirus > > > > > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > >
RE: Compuond objects
Dan, this statement you made cached my attention, as it might help reduce foreign keys and make the application more maintainable: "I prefer to use a join table for unidirectional, but FK for bidirectional; that way the database tables model the domain classes quite nicely (in particular, with a unidirectional and a join table the child table doesn't "know" about its parent)." How can I implement this with Isis / Datanucleous? Cesar. -Original Message- From: Dan Haywood [mailto:d...@haywood-associates.co.uk] Sent: Friday, November 6, 2015 2:03 AM To: users; David Tildesley Subject: Re: Compuond objects Hi David, thanks for chipping in on this thread. To answer your last question, I think I agree very broadly with your analysis. More detail within... On 5 November 2015 at 20:08, David Tildesley wrote: > Hi Cesar, > I think you are saying you currently have : > > Business - --> 1..* BusinessLocation Where one way navigation. > Whereas in the first use case you want two way navigation so it looks > like > this: > Business 1 <> 1..* BusinessLocation > > So if you have a BusinessLocation "in focus" then it is associated to > single Business. This two way navigation between objects has always > been an "expensive thing" to build - hence it is normally avoided > unless the tradeoff suggests it should be done - but maybe ISIS makes this > easier. > With JDO/DataNucleus, bidirectional relationships are no more difficult than unidirectional. With both bidirectional and undirectional, DN supports either using a join table to hold the tuples between parent/child, or alternatively a more traditional FK in the child. I prefer to use a join table for unidirectional, but FK for bidirectional; that way the database tables model the domain classes quite nicely (in particular, with a unidirectional and a join table the child table doesn't "know" about its parent). > But it sounds like you want a view which consolidates the information > from one graph instance of the above into a single "form". So I > believe the correct answer is yes: that is what the View Model is for. > In terms of update behaviour - you need to add the operation on the > View Model that explicitly sets the values on the domain object graph > and persists them - I would suggest a single operation on Business for > that purpose because Business should know about it's BusinessLocations > - you pass the user values in including the BusinessLocation.id > because Business has to know which BusinessLocation to update. > Put all your View models in a separate package - they are not part of > the domain. Make sure all the domain behaviour belongs to the domain > objects and doesn't leak out into View objects. Never reference a View > Model from the Domain Model the dependency should be View --> Domain > and never the other way around. Domain is stable, View is volatile. > Just create as many View Models as you need for the UI - after all that is > what they are for. What you are saying is true in this case, but you'll remember a long thread from about a year ago when we enumerated various different "types" of view model. We came to the conclusion that the view model implementation is also appropriate for what are really domain entities that just happen to be persisted externally, eg over a SOAP service. We express this using the @DomainObject(nature=...) attribute [1] > In fact your application may not need to expose any domain objects as > naked objects - but then again, there may some user experience > downside to that (e.g. having to explicit operation for update). > Folk - correct me if I am wrong - I need to catch up with where ISIS > is currently at and so having folk correct me is very welcome for my > education. > As per. If you're just catching up, check out: - changes to Isis itself in the release notes [2] ; 1.10.0 is imminent. - (non ASF) Isis addons, [3] - for reusable cross-cutting concerns - (non ASF) incode catalog, [4] - for reusable business functionality > Regards,David. > > > Thx Dan [1] http://isis.apache.org/guides/rg.html#_rg_annotations_manpage-DomainObject_nature [2] http://isis.apache.org/release-notes.html [3] http://www.isisaddons.org/ [4] http://catalog.incode.org/ > > > > On Friday, 6 November 2015 4:16 AM, Cesar Lugo < > cesar.l...@sisorg.com.mx> wrote: > > > Hello. I have the need to create some objects that are compound from > some other domain objects (similar to a "view" in a relational > database, updatable views). Let's say I have Business with businessId > and name properties, 1:n to another entity named BusinessLocation with > properties businessL
RE: Compuond objects
Hello Jerome. Thank you for providing this sample, it will be useful for some purposes. In this case, because I want the view model to be updatable, I don't want to move that logic to the database, but keep it in the Java methods. Is there by any chance any sample you might think of where there is a ViewModel that is not linked to a database view, and combines some of the objects in the app? Cesar. -Original Message- From: Jeroen van der Wal [mailto:jer...@stromboli.it] Sent: Thursday, November 5, 2015 11:20 AM To: users Subject: Re: Compuond objects Here's an example where a viewmodel uses a database view: https://github.com/estatio/estatio/blob/master/estatioapp/dom/src/main/java/org/estatio/dom/invoice/viewmodel/InvoiceSummaryForInvoiceRun.java On 5 November 2015 at 17:42, Dan Haywood wrote: > It is possible to map java domain classes to views instead of tables. > > Estatio has a couple of examples... perhaps Jeroen could dig out a > link for you (I'm typing this on my phone). > > Alternatively, yes, you could use view models. These then > programmatically combine the data. > > On your particular use case I would inject the repositories for the > "backing entities". > > One point to beat in mind is that Isis will handle view models with > collections, it only serializes the state of the view model's > properties (the determine the url of the view model). The workaround > is to make the collection derived, using > @Collection(notPersisted=true), and return is results by requerying the > appropriate repository. > > Again, Estatio has some examples, I think > > Hth > Dan. > On 5 Nov 2015 15:16, "Cesar Lugo" wrote: > > > Hello. I have the need to create some objects that are compound from > > some other domain objects (similar to a "view" in a relational > > database, updatable views). Let's say I have Business with > > businessId and name properties, 1:n to another entity named > > BusinessLocation with properties businessLocationId and name and > > address properties (to keep things simple for now). So, for example, > > I need to create a new object that is BuisinessLocationView, which > > contains BuinessLocation.id, BusinessLocation.name, Business.id and > > Buiness.name . Then, in some > cases, > > I > > want to use such views like BusinessLocationView as a collection > > within Business, and as a standalone collection, and also have the > > ability to update its fields so the corresponding entities are > > updated with the changes (Business and BusinessLocation), and in > > some cases even add a new view > like > > BusinessLocationView so it adds a new BusinessLocation. > > > > > > > > Is there a way to do this? Is that what @ViewModel is for? > > > > > > > > I would appreciate If you could point me to any sample that might help. > > > > > > > > Cesar. > > > > > > > > > > > > > > > > --- > > This email has been checked for viruses by Avast antivirus software. > > https://www.avast.com/antivirus > > > --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Compuond objects
Thanks Dan. I'm very impressed at the velocity of adding new features and improvements. Kind Regards,David. On Friday, 6 November 2015 9:03 PM, Dan Haywood wrote: Hi David, thanks for chipping in on this thread. To answer your last question, I think I agree very broadly with your analysis. More detail within... On 5 November 2015 at 20:08, David Tildesley wrote: > Hi Cesar, > I think you are saying you currently have : > > Business - --> 1..* BusinessLocation > Where one way navigation. > Whereas in the first use case you want two way navigation so it looks like > this: > Business 1 <> 1..* BusinessLocation > > So if you have a BusinessLocation "in focus" then it is associated to > single Business. This two way navigation between objects has always been an > "expensive thing" to build - hence it is normally avoided unless the > tradeoff suggests it should be done - but maybe ISIS makes this easier. > With JDO/DataNucleus, bidirectional relationships are no more difficult than unidirectional. With both bidirectional and undirectional, DN supports either using a join table to hold the tuples between parent/child, or alternatively a more traditional FK in the child. I prefer to use a join table for unidirectional, but FK for bidirectional; that way the database tables model the domain classes quite nicely (in particular, with a unidirectional and a join table the child table doesn't "know" about its parent). > But it sounds like you want a view which consolidates the information from > one graph instance of the above into a single "form". So I believe the > correct answer is yes: that is what the View Model is for. In terms of > update behaviour - you need to add the operation on the View Model that > explicitly sets the values on the domain object graph and persists them - I > would suggest a single operation on Business for that purpose because > Business should know about it's BusinessLocations - you pass the user > values in including the BusinessLocation.id because Business has to know > which BusinessLocation to update. > Put all your View models in a separate package - they are not part of the > domain. Make sure all the domain behaviour belongs to the domain objects > and doesn't leak out into View objects. Never reference a View Model from > the Domain Model the dependency should be View --> Domain and never the > other way around. Domain is stable, View is volatile. Just create as many > View Models as you need for the UI - after all that is what they are for. What you are saying is true in this case, but you'll remember a long thread from about a year ago when we enumerated various different "types" of view model. We came to the conclusion that the view model implementation is also appropriate for what are really domain entities that just happen to be persisted externally, eg over a SOAP service. We express this using the @DomainObject(nature=...) attribute [1] > In fact your application may not need to expose any domain objects as > naked objects - but then again, there may some user experience downside to > that (e.g. having to explicit operation for update). > Folk - correct me if I am wrong - I need to catch up with where ISIS is > currently at and so having folk correct me is very welcome for my education. > As per. If you're just catching up, check out: - changes to Isis itself in the release notes [2] ; 1.10.0 is imminent. - (non ASF) Isis addons, [3] - for reusable cross-cutting concerns - (non ASF) incode catalog, [4] - for reusable business functionality > Regards,David. > > > Thx Dan [1] http://isis.apache.org/guides/rg.html#_rg_annotations_manpage-DomainObject_nature [2] http://isis.apache.org/release-notes.html [3] http://www.isisaddons.org/ [4] http://catalog.incode.org/ > > > > On Friday, 6 November 2015 4:16 AM, Cesar Lugo < > cesar.l...@sisorg.com.mx> wrote: > > > Hello. I have the need to create some objects that are compound from some > other domain objects (similar to a "view" in a relational database, > updatable views). Let's say I have Business with businessId and name > properties, 1:n to another entity named BusinessLocation with properties > businessLocationId and name and address properties (to keep things simple > for now). So, for example, I need to create a new object that is > BuisinessLocationView, which contains BuinessLocation.id, > BusinessLocation.name, Business.id and Buiness.name . Then, in some cases, > I > want to use such views like BusinessLocationView as a collection within > Business, and as a standalone collection, and also have the ability to > update its fields so the corresponding entities are updated with the > changes > (Business and BusinessLocation), and in some cases even add a new view like > BusinessLocationView so it adds a new BusinessLocation. > > > > Is there a way to do this? Is that what @ViewModel is for? > > > > I would appreciate If you could point me to any sam
Re: Compuond objects
Hi David, thanks for chipping in on this thread. To answer your last question, I think I agree very broadly with your analysis. More detail within... On 5 November 2015 at 20:08, David Tildesley wrote: > Hi Cesar, > I think you are saying you currently have : > > Business - --> 1..* BusinessLocation > Where one way navigation. > Whereas in the first use case you want two way navigation so it looks like > this: > Business 1 <> 1..* BusinessLocation > > So if you have a BusinessLocation "in focus" then it is associated to > single Business. This two way navigation between objects has always been an > "expensive thing" to build - hence it is normally avoided unless the > tradeoff suggests it should be done - but maybe ISIS makes this easier. > With JDO/DataNucleus, bidirectional relationships are no more difficult than unidirectional. With both bidirectional and undirectional, DN supports either using a join table to hold the tuples between parent/child, or alternatively a more traditional FK in the child. I prefer to use a join table for unidirectional, but FK for bidirectional; that way the database tables model the domain classes quite nicely (in particular, with a unidirectional and a join table the child table doesn't "know" about its parent). > But it sounds like you want a view which consolidates the information from > one graph instance of the above into a single "form". So I believe the > correct answer is yes: that is what the View Model is for. In terms of > update behaviour - you need to add the operation on the View Model that > explicitly sets the values on the domain object graph and persists them - I > would suggest a single operation on Business for that purpose because > Business should know about it's BusinessLocations - you pass the user > values in including the BusinessLocation.id because Business has to know > which BusinessLocation to update. > Put all your View models in a separate package - they are not part of the > domain. Make sure all the domain behaviour belongs to the domain objects > and doesn't leak out into View objects. Never reference a View Model from > the Domain Model the dependency should be View --> Domain and never the > other way around. Domain is stable, View is volatile. Just create as many > View Models as you need for the UI - after all that is what they are for. What you are saying is true in this case, but you'll remember a long thread from about a year ago when we enumerated various different "types" of view model. We came to the conclusion that the view model implementation is also appropriate for what are really domain entities that just happen to be persisted externally, eg over a SOAP service. We express this using the @DomainObject(nature=...) attribute [1] > In fact your application may not need to expose any domain objects as > naked objects - but then again, there may some user experience downside to > that (e.g. having to explicit operation for update). > Folk - correct me if I am wrong - I need to catch up with where ISIS is > currently at and so having folk correct me is very welcome for my education. > As per. If you're just catching up, check out: - changes to Isis itself in the release notes [2] ; 1.10.0 is imminent. - (non ASF) Isis addons, [3] - for reusable cross-cutting concerns - (non ASF) incode catalog, [4] - for reusable business functionality > Regards,David. > > > Thx Dan [1] http://isis.apache.org/guides/rg.html#_rg_annotations_manpage-DomainObject_nature [2] http://isis.apache.org/release-notes.html [3] http://www.isisaddons.org/ [4] http://catalog.incode.org/ > > > > On Friday, 6 November 2015 4:16 AM, Cesar Lugo < > cesar.l...@sisorg.com.mx> wrote: > > > Hello. I have the need to create some objects that are compound from some > other domain objects (similar to a "view" in a relational database, > updatable views). Let's say I have Business with businessId and name > properties, 1:n to another entity named BusinessLocation with properties > businessLocationId and name and address properties (to keep things simple > for now). So, for example, I need to create a new object that is > BuisinessLocationView, which contains BuinessLocation.id, > BusinessLocation.name, Business.id and Buiness.name . Then, in some cases, > I > want to use such views like BusinessLocationView as a collection within > Business, and as a standalone collection, and also have the ability to > update its fields so the corresponding entities are updated with the > changes > (Business and BusinessLocation), and in some cases even add a new view like > BusinessLocationView so it adds a new BusinessLocation. > > > > Is there a way to do this? Is that what @ViewModel is for? > > > > I would appreciate If you could point me to any sample that might help. > > > > Cesar. > > > > > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > > >
Re: Compuond objects
Hi Cesar, I think you are saying you currently have : Business - --> 1..* BusinessLocation Where one way navigation. Whereas in the first use case you want two way navigation so it looks like this: Business 1 <> 1..* BusinessLocation So if you have a BusinessLocation "in focus" then it is associated to single Business. This two way navigation between objects has always been an "expensive thing" to build - hence it is normally avoided unless the tradeoff suggests it should be done - but maybe ISIS makes this easier. But it sounds like you want a view which consolidates the information from one graph instance of the above into a single "form". So I believe the correct answer is yes: that is what the View Model is for. In terms of update behaviour - you need to add the operation on the View Model that explicitly sets the values on the domain object graph and persists them - I would suggest a single operation on Business for that purpose because Business should know about it's BusinessLocations - you pass the user values in including the BusinessLocation.id because Business has to know which BusinessLocation to update. Put all your View models in a separate package - they are not part of the domain. Make sure all the domain behaviour belongs to the domain objects and doesn't leak out into View objects. Never reference a View Model from the Domain Model the dependency should be View --> Domain and never the other way around. Domain is stable, View is volatile. Just create as many View Models as you need for the UI - after all that is what they are for. In fact your application may not need to expose any domain objects as naked objects - but then again, there may some user experience downside to that (e.g. having to explicit operation for update). Folk - correct me if I am wrong - I need to catch up with where ISIS is currently at and so having folk correct me is very welcome for my education. Regards,David. On Friday, 6 November 2015 4:16 AM, Cesar Lugo wrote: Hello. I have the need to create some objects that are compound from some other domain objects (similar to a "view" in a relational database, updatable views). Let's say I have Business with businessId and name properties, 1:n to another entity named BusinessLocation with properties businessLocationId and name and address properties (to keep things simple for now). So, for example, I need to create a new object that is BuisinessLocationView, which contains BuinessLocation.id, BusinessLocation.name, Business.id and Buiness.name . Then, in some cases, I want to use such views like BusinessLocationView as a collection within Business, and as a standalone collection, and also have the ability to update its fields so the corresponding entities are updated with the changes (Business and BusinessLocation), and in some cases even add a new view like BusinessLocationView so it adds a new BusinessLocation. Is there a way to do this? Is that what @ViewModel is for? I would appreciate If you could point me to any sample that might help. Cesar. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
RE: Compuond objects
In most cases I would prefer the second choice (view models), because I want all domain logic to be applied to the corresponding objects within the view if it gets updated or inserted, which won't happen if I use database views. I will try to find some example in Estatio. I don’t think I understood your last statement about view models and collections, perhaps I will when I dig a little more into this. Cesar. -Original Message- From: Dan Haywood [mailto:d...@haywood-associates.co.uk] Sent: Thursday, November 5, 2015 10:43 AM To: users Subject: Re: Compuond objects It is possible to map java domain classes to views instead of tables. Estatio has a couple of examples... perhaps Jeroen could dig out a link for you (I'm typing this on my phone). Alternatively, yes, you could use view models. These then programmatically combine the data. On your particular use case I would inject the repositories for the "backing entities". One point to beat in mind is that Isis will handle view models with collections, it only serializes the state of the view model's properties (the determine the url of the view model). The workaround is to make the collection derived, using @Collection(notPersisted=true), and return is results by requerying the appropriate repository. Again, Estatio has some examples, I think Hth Dan. On 5 Nov 2015 15:16, "Cesar Lugo" wrote: > Hello. I have the need to create some objects that are compound from > some other domain objects (similar to a "view" in a relational > database, updatable views). Let's say I have Business with businessId > and name properties, 1:n to another entity named BusinessLocation with > properties businessLocationId and name and address properties (to keep > things simple for now). So, for example, I need to create a new object > that is BuisinessLocationView, which contains BuinessLocation.id, > BusinessLocation.name, Business.id and Buiness.name . Then, in some > cases, I want to use such views like BusinessLocationView as a > collection within Business, and as a standalone collection, and also > have the ability to update its fields so the corresponding entities > are updated with the changes (Business and BusinessLocation), and in > some cases even add a new view like BusinessLocationView so it adds a > new BusinessLocation. > > > > Is there a way to do this? Is that what @ViewModel is for? > > > > I would appreciate If you could point me to any sample that might help. > > > > Cesar. > > > > > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Compuond objects
Here's an example where a viewmodel uses a database view: https://github.com/estatio/estatio/blob/master/estatioapp/dom/src/main/java/org/estatio/dom/invoice/viewmodel/InvoiceSummaryForInvoiceRun.java On 5 November 2015 at 17:42, Dan Haywood wrote: > It is possible to map java domain classes to views instead of tables. > > Estatio has a couple of examples... perhaps Jeroen could dig out a link for > you (I'm typing this on my phone). > > Alternatively, yes, you could use view models. These then programmatically > combine the data. > > On your particular use case I would inject the repositories for the > "backing entities". > > One point to beat in mind is that Isis will handle view models with > collections, it only serializes the state of the view model's properties > (the determine the url of the view model). The workaround is to make the > collection derived, using @Collection(notPersisted=true), and return is > results by requerying the appropriate repository. > > Again, Estatio has some examples, I think > > Hth > Dan. > On 5 Nov 2015 15:16, "Cesar Lugo" wrote: > > > Hello. I have the need to create some objects that are compound from some > > other domain objects (similar to a "view" in a relational database, > > updatable views). Let's say I have Business with businessId and name > > properties, 1:n to another entity named BusinessLocation with properties > > businessLocationId and name and address properties (to keep things simple > > for now). So, for example, I need to create a new object that is > > BuisinessLocationView, which contains BuinessLocation.id, > > BusinessLocation.name, Business.id and Buiness.name . Then, in some > cases, > > I > > want to use such views like BusinessLocationView as a collection within > > Business, and as a standalone collection, and also have the ability to > > update its fields so the corresponding entities are updated with the > > changes > > (Business and BusinessLocation), and in some cases even add a new view > like > > BusinessLocationView so it adds a new BusinessLocation. > > > > > > > > Is there a way to do this? Is that what @ViewModel is for? > > > > > > > > I would appreciate If you could point me to any sample that might help. > > > > > > > > Cesar. > > > > > > > > > > > > > > > > --- > > This email has been checked for viruses by Avast antivirus software. > > https://www.avast.com/antivirus > > >
Re: Compuond objects
It is possible to map java domain classes to views instead of tables. Estatio has a couple of examples... perhaps Jeroen could dig out a link for you (I'm typing this on my phone). Alternatively, yes, you could use view models. These then programmatically combine the data. On your particular use case I would inject the repositories for the "backing entities". One point to beat in mind is that Isis will handle view models with collections, it only serializes the state of the view model's properties (the determine the url of the view model). The workaround is to make the collection derived, using @Collection(notPersisted=true), and return is results by requerying the appropriate repository. Again, Estatio has some examples, I think Hth Dan. On 5 Nov 2015 15:16, "Cesar Lugo" wrote: > Hello. I have the need to create some objects that are compound from some > other domain objects (similar to a "view" in a relational database, > updatable views). Let's say I have Business with businessId and name > properties, 1:n to another entity named BusinessLocation with properties > businessLocationId and name and address properties (to keep things simple > for now). So, for example, I need to create a new object that is > BuisinessLocationView, which contains BuinessLocation.id, > BusinessLocation.name, Business.id and Buiness.name . Then, in some cases, > I > want to use such views like BusinessLocationView as a collection within > Business, and as a standalone collection, and also have the ability to > update its fields so the corresponding entities are updated with the > changes > (Business and BusinessLocation), and in some cases even add a new view like > BusinessLocationView so it adds a new BusinessLocation. > > > > Is there a way to do this? Is that what @ViewModel is for? > > > > I would appreciate If you could point me to any sample that might help. > > > > Cesar. > > > > > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus >