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 <[email protected]> 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:[email protected]] > 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 <[email protected]> > 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" <[email protected]> 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 > >
