On 22 December 2015 at 15:19, Óscar Bou - GOVERTIS <o....@govertis.com>
wrote:
>
> Hi all.
>
> I find the SPI Service really useful for advanced use cases.
>
> But in order to have the desired behavior clearly specified on the same
> class definition, shouldn't be helpful to also have an annotation
> indicating the desired behavior (like returning this instance)?
>
>
Seems better to provide a lower level SPI service that can work in all use
cases, and then use that as a building block for higher level abstractions
that might include annotations (or more likely, a new attribute of the
@Action annotation).
But to start that conversation, we could have a new "strategy" attribute,
eg:
@Action(
routeUsing=MyRouter.class // implements some sort of "Router"
interface, similar to our Specification interface
)
public void whatever(...) { ... }
Cheers
Dan
> Christmas here also :))
>
> HTH,
>
> Oscar
>
> > El 22 dic 2015, a las 15:54, Cesar Lugo <cesar.l...@sisorg.com.mx>
> escribió:
> >
> > 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:d...@haywood-associates.co.uk]
> > 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 <cesar.l...@sisorg.com.mx>
> 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:m...@yuritan.nl]
> >> 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
> >
>
