Dan, I think your proposal is quite good to have a configurable "default" behavior, and having the option to return whatever the developer wants is quite useful as well. Probably this could evolve to some kind of wizard (I saw a work in progress in Isis add-ons), or even some integration with some BPM tool. Just thinking loud here, it's christmas :) .
Cesar. -----Original Message----- From: Dan Haywood [mailto:[email protected]] Sent: Tuesday, December 22, 2015 6:02 AM To: users Subject: Re: How should we handle void and null results There was a related discussion a while back [1], revolving around whether the Wicket viewer should always render the returned object, or some other object (eg the owning object/aggregate root). I raised a ticket ISIS-666 [2] for this, and have also now referenced this thread [3]. To pick up on a couple of points made: * should the object returned by the action determine the next object rendered (ie do domain object actions act as "controllers")? Yu Ri says no, whereas in the previous conversation (Oscar, Jeroen, Dan) I think we were always saying its ok, but to provide the ability for this to be modified (eg to the aggregate root rather than leaf). We didn't discuss the case of returning void, though. * Martin was wondering about whether Person#delete() even makes sense. I think it does though; at least an end-user would want to press a button called "delete" on a domain object. Behind the covers that might be a contributed action or mixin or double-dispatch back to a repository service. But that's an implementation detail: the core responsibility is for a domain object to know how to get itself deleted * Steve suggests that where there is no obvious answer to "which object should be shown next", then the home page might be a reasonable default. I agree, and think we should provide such a capability. * Cesar illustrates how to return a parent object, eg for both delete and also for add. To me it seems that it's unlikely to be a single policy that will support all use cases. So I propose a new optional SPI service that, if present, the viewer will consult to determine which object to show next. I see this a quite low-level service and we might use it as a building block to some higher-level strategy (eg based on new annotations) at a later date. The SPI I suggest is: public interface RoutingService { public Object route(Object original); } A default implementation could be something like: public class RoutingServiceDefault { public Object route(Object original) { return original != null? original: homePage(); } private Object homePage() { ... code to find the @HomePage object if any ... } } This behaviour could be overridden eg to support the aggregate object idea as discussed in [1]. So, that's my proposal. Cheers Dan [1] http://markmail.org/message/xhmeq62ywr2vqvje . [2] https://issues.apache.org/jira/browse/ISIS-666 On 21 December 2015 at 14:46, Cesar Lugo <[email protected]> wrote: > Hello. I am just another Isis user like you, but I thought this might help: > > Wicket viewer shows what you "return" in your action method, so, > because you are returning void, Wicket is showing "no results" > message. Usually, you return the thing you create or update, but you > can return the parent if that's what you want, or anything else you > need, just get it in your code and return it. For example, I have a > method that adds a Deliverer that belongs to a BusinessLocation, and > after created shows the parent BusinessLocation entity object instead > of showing the Deliverer object just created (in my case, when showing > the BusinessLocation parent, the Deliverer just created shows in the > collection section, which is what I wanted, because Business have that > collection). If you adapt this code to your deletePerson method I think it > can work. > > My sample code is: > > @Action( > domainEvent = CreateDomainEvent.class > ) > @MemberOrder(name = "deliverers",sequence = "24") > public BusinessLocation addDeliverer( > final @ParameterLayout(named="Business Location") > BusinessLocation businessLocation, > final @ParameterLayout(named="Deliverer Id") String > delivererId, > final @ParameterLayout(named="First Name") String firstName, > final @ParameterLayout(named="Middle Name") > @Parameter(optionality = Optionality.OPTIONAL)String middleName, > final @ParameterLayout(named="Last Name") String lastName, > final @ParameterLayout(named="Last Name 2") > @Parameter(optionality = Optionality.OPTIONAL)String lastName2, > final @ParameterLayout(named="Contact Phone") > @Parameter(optionality = Optionality.OPTIONAL)Long contactPhone, > final @ParameterLayout(named="Delivery Phone") > @Parameter(optionality = Optionality.OPTIONAL)Long deliveryPhone, > final @ParameterLayout(named="Deliverer Picture") > @Parameter(optionality = Optionality.OPTIONAL) Blob delivererPicture > ) > { > final Deliverer obj = > container.newTransientInstance(Deliverer.class); > obj.setBusinessLocation(businessLocation); > obj.setDelivererId(delivererId); > obj.setFirstName(firstName); > obj.setMiddleName(middleName); > obj.setLastName(lastName); > obj.setLastName2(lastName2); > obj.setContactPhone(contactPhone); > obj.setDeliveryPhone(deliveryPhone); > obj.setDelivererPicture(delivererPicture); > obj.setCreationTime(clockService.nowAsDateTime()); > container.persistIfNotAlready(obj); > return obj.getBusinessLocation(); > } > > If you choose to return the parent of the Person object being deleted, > make sure you get the parent before you Delete the person. Have fun! > > Cesar. > > -----Original Message----- > From: Y.R Tan [mailto:[email protected]] > Sent: Saturday, December 19, 2015 5:44 AM > To: users > Subject: How should we handle void and null results > > Hi everyone, > > When using a void action, let’s say a remove action, the user is > redirected to a page "no results". When clicking the back button in > the browser the user sees "Object not found" (since you’ve just > deleted this object). > > Example: > > public class Person { > .... > public void remove() { > ... > } > } > > You can return a list for example to prevent the user from being > redirect to a "No results" page, but I think it’s not the > responsibility of the controllers in the domain model. A solution > could be that wicket viewer goes back one page when encountering a > deleted object. And refresh the current page when receiving a null response > or invoking a void action. > > What do you guys think that is the best solution? Or do you have > another view on this situation? > > Looking forward hearing from you. > > Regards, > > Yu Ri Tan > > > --- > 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
