You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by ch...@wipro.com on 2014/01/08 12:37:46 UTC
Bulk update of selected set of Domian objects from the list page
Like bulk delete, we have one use case to bulk update the set of JDO entity(of type OmSite).
>From the list of OmSite, some set of OmSite could be selected and click on update button which should take to one page where in selected sites should be seen and some new fields. These new fields are used to update the some attributes of OmSite. So that I can update the attributes of all selected sites in a single shot.
So for this, what I have done is:
1. Created a OmSiteGroup domain object(which is not mapped to any table) with attributes name, Set<OmSite>, some fields which are used to update the selected OmSite(s)
2. In OmSite JDO entity, added a method update with @Bulk annotation and declared OmSiteGroup instance variable(not-persistent)
3. OmSite.update method
(a)creates OmSiteGroup instance and add/update name attribute with selected OmSite(s) Id
(b)adds current OmSite in OmSiteGroup and returns the OmSiteGroup object so that this OmSiteGroup-page get rendered with list of selected sites and group name
So with this coding, I have got update button in OmSite List page and also in OmSite edit page.
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?
BR
Ranganath Varma
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
RE: Bulk update of selected set of Domian objects from the list page
Posted by ch...@wipro.com.
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:dan@haywood-associates.co.uk]
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, <ch...@wipro.com> 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
Re: Bulk update of selected set of Domian objects from the list page
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Bad news and good news.
The bad news is that there isn't really any way to support this right now.
You could create a view model to manage the process, but it'd be a lot of
very non-obvious boilerplate, so I can't recommend going that way.
The good news is that this is a feature that we need for the Estatio app,
and so there's a good chance I'll be implementing the feature in the next
month or two.
Right now my thoughts are that the programming conventions will be extended
so that a Collection<T> can be specified as an action parameter, eg:
public class OmSiteGroup {
private Set<OmSite> _sites = ...
public Set<OmSite> getSites() { ... }
public OmSiteGroup add(Collection<OmSite> sites) {
_sites.add(sites);
}
}
My intention is then to use Select2Multichoice from [1] (I use
Select2Choice for the current drop-down).
Dan
[1] https://github.com/ivaynberg/wicket-select2
On 17 January 2014 12:07, <ch...@wipro.com> wrote:
> To elaborate more on it:
>
> In OmSiteGroup(now this domain is persistent type as well), I have
> @PublishedAction annotate method as below:
>
> @PublishedAction
> public OmSiteGroup add(final @Named("Site Name")String name, final
> OmSite site) {
> this.getSites().add(site);
> return this;
> }
>
>
> So, I have Add button in OmSiteGroup page and when I click on Add button I
> have two fields and Ok button
>
> Name <text-field>
> OmSite <drop-down list>
>
> OK <button>
>
> In OmSiteGroup class I have choices1Add method for OmSite parameter which
> will use name field to filter and get the sites and populate the above
> drop-down list.
> Here I can select only one site.
>
> So, In ISIS :
> Is it possible to have multiple-select type drop-down list
> OR
> Is it possible to display the sites in the table with checkboxes to select
> multiple sites ( I think this is possible only with @Bulk action, but I
> cannot use it here in this context since this page gets rendered through
> @PublishedAction but not through OmSite)
> OR
> can you please guide me to extend the framework to have the above features.
>
> Please suggest.
>
>
> BR
> Ranganath Varma
>
>
> -----Original Message-----
> From: Chittari Ranganath varma (WF04 - Wipro EcoEnergy)
> Sent: Friday, January 17, 2014 4:16 PM
> To: users
> Cc: dev
> Subject: RE: Bulk update of selected set of Domian objects from the list
> page
>
> 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:dan@haywood-associates.co.uk]
> 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, <ch...@wipro.com> 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
>
RE: Bulk update of selected set of Domian objects from the list page
Posted by ch...@wipro.com.
To elaborate more on it:
In OmSiteGroup(now this domain is persistent type as well), I have @PublishedAction annotate method as below:
@PublishedAction
public OmSiteGroup add(final @Named("Site Name")String name, final OmSite site) {
this.getSites().add(site);
return this;
}
So, I have Add button in OmSiteGroup page and when I click on Add button I have two fields and Ok button
Name <text-field>
OmSite <drop-down list>
OK <button>
In OmSiteGroup class I have choices1Add method for OmSite parameter which will use name field to filter and get the sites and populate the above drop-down list.
Here I can select only one site.
So, In ISIS :
Is it possible to have multiple-select type drop-down list
OR
Is it possible to display the sites in the table with checkboxes to select multiple sites ( I think this is possible only with @Bulk action, but I cannot use it here in this context since this page gets rendered through @PublishedAction but not through OmSite)
OR
can you please guide me to extend the framework to have the above features.
Please suggest.
BR
Ranganath Varma
-----Original Message-----
From: Chittari Ranganath varma (WF04 - Wipro EcoEnergy)
Sent: Friday, January 17, 2014 4:16 PM
To: users
Cc: dev
Subject: RE: Bulk update of selected set of Domian objects from the list page
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:dan@haywood-associates.co.uk]
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, <ch...@wipro.com> 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
RE: Bulk update of selected set of Domian objects from the list page
Posted by ch...@wipro.com.
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:dan@haywood-associates.co.uk]
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, <ch...@wipro.com> 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
RE: Bulk update of selected set of Domian objects from the list page
Posted by ch...@wipro.com.
To elaborate more on it:
In OmSiteGroup(now this domain is persistent type as well), I have @PublishedAction annotate method as below:
@PublishedAction
public OmSiteGroup add(final @Named("Site Name")String name, final OmSite site) {
this.getSites().add(site);
return this;
}
So, I have Add button in OmSiteGroup page and when I click on Add button I have two fields and Ok button
Name <text-field>
OmSite <drop-down list>
OK <button>
In OmSiteGroup class I have choices1Add method for OmSite parameter which will use name field to filter and get the sites and populate the above drop-down list.
Here I can select only one site.
So, In ISIS :
Is it possible to have multiple-select type drop-down list
OR
Is it possible to display the sites in the table with checkboxes to select multiple sites ( I think this is possible only with @Bulk action, but I cannot use it here in this context since this page gets rendered through @PublishedAction but not through OmSite)
OR
can you please guide me to extend the framework to have the above features.
Please suggest.
BR
Ranganath Varma
-----Original Message-----
From: Chittari Ranganath varma (WF04 - Wipro EcoEnergy)
Sent: Friday, January 17, 2014 4:16 PM
To: users
Cc: dev
Subject: RE: Bulk update of selected set of Domian objects from the list page
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:dan@haywood-associates.co.uk]
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, <ch...@wipro.com> 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
Re: Bulk update of selected set of Domian objects from the list page
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 8 January 2014 11:37, <ch...@wipro.com> 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
Re: Bulk update of selected set of Domian objects from the list page
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 8 January 2014 11:37, <ch...@wipro.com> 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