Hi Dan, Thanks for the response. I have actually tried this grouping (of Sites) in different way: Create a Group with domain object OmSiteGroup by grouping the sites OmSite using @PublishedAction method and filter criteria. I have used ToDoItem's add dependencies approach. But in this approach site by site can only be added since drop-down list makes user to select only one site. And also @PublishedAction method doesn't allow to take Collection type.
So what I need now is select multiple sites based on filter criteria. I can get List of sites in drop-down list by filtering. But not something like List from which multiple sites can be selected. Any idea to get something like list page with checkboxes to select multiple items? BR Ranganath Varma -----Original Message----- From: Dan Haywood [mailto:[email protected]] Sent: Friday, January 10, 2014 8:10 PM To: users Cc: dev Subject: Re: Bulk update of selected set of Domian objects from the list page On 8 January 2014 11:37, <[email protected]> wrote: > > And issues are: > > 1. After selecting some OmSite(s) I click on Update button from list > page. But it doesn't go to OmSiteGroup-page. Instead it refreshes the > OmSite list page again > > 2. I click on update button in OmSite edit page, OmSiteGroup-page is > displayed with only name field but OmSite is not seen in the list. > > Can anyone please suggest if bulk update is possible in ISIS? > > > Bulk update does have some limitations, the most significant being that action parameters for bulk update are not currently supported. What you've done thus far is pretty ingenious, though, so well done. Right now I don't think that Isis can do what you want, but I have a proposal (that I've just spiked locally) that would be a simple enough refinement that could do the job. Let me step back a second and summarize the current behaviour: - any no-arg action can be annotated as @Bulk. - any such action can be invoked either as a bulk action (on a collection) or as a regular action on the entity - if invoked as a bulk action, the returned value is ignored. Instead, we just show the list of objects again. So the change I'm considering for Isis would the rule that, rather than always return the original list, it would instead show the returned value of the last object interacted with. (Or if a null is returned, then the current behaviour is retained). With this change, you could then code your bulk action OmSite#bulkAction() to return your non-persisted view model, ie OmSiteGroup. Each OmSite could attach itself to this view model, and the last OmSite would return this OmSiteGroup. As a refinement, rather than use an instance variable for OmSiteGroup, we could extend Bulk.InteractionContext and use it to pass the current OmSiteGroup from one OmSite to the next. In other words: public class OmSite { @Bulk public Object bulkAction() { Bulk.InteractionContext ctxt = Bulk.InteractionContext.current(); if(ctxt == null) { container.warnUser("Only invoke as a bulk action"); return; } // create an OmSiteGroup for this interaction, if required OmSiteGroup group = (OmSiteGroup)ctxt.getIserData("group"); if(group == null) { group = container.newViewModelInstance(OmSiteGroup.class, new UUID().toString()); ctxt.setUserData("group", group); } // add this site to the group, so it can be updated later via the group view model group.addSiteToBeUpdated(this); // this gets picked up by Isis and returned when the object called is the last one return group; } } and: public class OmSiteGroup extends AbstractViewModel { @Programmatic public void addSiteToBeUpdate(OmSite site) { _sites.add(site); } private List<OmSite> _sites = ...; public List<OmSite> getSitesToBeUpdated() { return _sites; } } Since OmSiteGroup is a view model, it would need to serialize the _sites field somehow. The BookmarkServiceDefault (serialize each object to its oid string) and the ViewModelSupportDefault class (serialize a bunch of strings to a single string) should allow you to do this. ~~~ One snag in the above is that invoking the bulk action as a regular entity action would still result in the OmSiteGroup being returned. One solution - as sketched above - is to check that a Bulk.InteractionContext is not null. An alternative might be to enhance @Bulk so that it can indicate whether it applies only as a bulk action (ie not as a regular entity). I think that's also probably a worthwhile enhancement. If anyone is still with me, any thoughts on the above? Cheers Dan The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
