That's an interesting idea, Oscar.
The issue arises from the fact that there are potentially two different
callers of the Order#createItem method:
a) the Isis framework itself - in which case, as we all know, the signature
of the methdo is used to determine presentation/navigation
b) other domain objects, ie programmatic interaction. In some cases the
caller might want the aggregate root (Order), at other times the aggregated
(OrderItem).
Actually, being strict about (b), under DDD the aggregate root should never
return one of its constituent parts. That would argue that even for
programmatic interactions (b) the method should only return Order, not
OrderItem.
If we relax that rule, though, then one solution is to split out the method
according to its two different callers, and have one method delegate to the
other; eg:
public class Order {
public Order createItem( ... ) {
doCreateItem(...);
return this;
}
@Programmatic
pubilc OrderItem doCreateItem( .... ) {
OrderItem item = ...
...
return item;
}
}
I suspect the above pattern/idiom is sufficient in many cases.
But if that seems like too much boilerplate, and we really did want to have
a single method (such that Isis renders the Order even though an OrderItem
is returned) then I think I'd prefer to simply annotate which of our
entities are aggregate roots, ie
@AggregateRoot
public class Order { ... }
Then, the rule would be that if the returned object does not have the
AggregateRootFacet, then we instead navigate to the target aggregate root.
Thoughts?
Dan
On 3 December 2013 10:01, GESCONSULTOR - Óscar Bou
<[email protected]>wrote:
>
> Really well-looking, Jeroen.
>
> Regarding navigability through actions, I think that perhaps there are 2
> distinct use cases that should be treated differently as such:
>
> 1. The user creates an Aggregate Root (such as an Order). As such,
> normally want to navigate to the newly created one.
> 2. The user creates an Entity that is part of an Aggregate (such as an
> Order Line / Item). In this case, normally the user wants to stay on the
> Order by default. If not, he/she can always navigate by clicking on the
> item collections link to the newly created item.
>
> Implementing that desired default behavior by Isis could be easily done
> with an annotation that can be associated with an action, such as
> @NotNavigate (sure there are better names :-).
>
> By default, the Isis framework viewers open the action's returned entity
> (such as when invoking Orders.createOrder(...) ), but that behavior could
> be overridden annotating with @NotNavigate the ( Order.createItem(...) )
> action:
>
> public class Order {
>
> ...
>
> @NotNavigate
> public OrderItem createItem(...) {
> ...
> }
>
> }
>
>
> Currently, we are forced to choose to return void or return an object, as
> that mandates the Isis viewer behavior. With that annotation, the value
> returned does not always imposes the navigation behavior.
>
> Perhaps there are better solutions or some pitfalls on this proposal.
>
> HTH,
>
> Oscar
>
>
>
> El 02/12/2013, a las 22:57, Jeroen van der Wal <[email protected]>
> escribió:
>
> > Thanks for reminding Dan, screenshot now as link [1]
> >
> > [1]
> >
> https://dl.dropboxusercontent.com/u/1930710/Attachments/Screen%20Shot%202013-12-02%20at%2010.03.35%20PM.png
> >
> >
> > On Mon, Dec 2, 2013 at 10:23 PM, Dan Haywood
> > <[email protected]>wrote:
> >
> >> Hi Jeroen,
> >> Screenshots get stripped from the mailing list, so you'll need to post
> it
> >> somewhere online. How about updating the screenshots on Estatio's
> README?
> >>
> >> By the way, I have a further commit... discovered that default values
> for
> >> parameters are not honoured second time around (ie bring up an action
> >> prompt, then cancel, then bring it up again).
> >>
> >> Cheers
> >> Dan
> >>
> >>
> >>
> >> On 2 December 2013 21:17, Jeroen van der Wal <[email protected]>
> wrote:
> >>
> >>> The modal dialog really improves the usability, thanks Dan. I've
> attached
> >>> attached a screenshot which tells more then thousand words.
> >>>
> >>> I just recently learned that you can use java.lang.Object as the return
> >>> type of an action and return whatever domain object or collection you
> >>> programmatically decide. So your action basically is the controller.
> >> Nice!
> >>> Sounds familiar to what Oscar is doing.
> >>>
> >>> Cheers,
> >>>
> >>> Jeroen
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Dec 2, 2013 at 7:37 PM, GESCONSULTOR - Óscar Bou <
> >>> [email protected]> wrote:
> >>>
> >>>>
> >>>>
> >>>> Good done.
> >>>>
> >>>> We also use modal dialogs on our custom viewer to avoid context
> >>>> switching. The same dialog redirects to a Domain Object if that's the
> >>>> result of the action invocation, or currently shows a Collection in a
> >> grid
> >>>> on the same dialog if that's the result of the action. The user can
> then
> >>>> navigate to any of the objects in the collection.
> >>>>
> >>>>
> >>>>
> >>>> El 02/12/2013, a las 17:54, Dan Haywood <[email protected]
> >
> >>>> escribió:
> >>>>
> >>>>> Hi folks,
> >>>>>
> >>>>> just an fyi that I've committed and pushed ISIS-486 [1], to render
> the
> >>>>> Wicket viewer's action prompts in modal dialogs. This should make
> >> for
> >>>> a
> >>>>> better overall user experience.
> >>>>>
> >>>>> To use, you'll need to build from source, as per [2].
> >>>>>
> >>>>> In case there are issues, the old behaviour (action prompts on their
> >> own
> >>>>> page) can be enabled by adding the following property:
> >>>>>
> >>>>> isis.viewer.wicket.disableModalDialogs=true
> >>>>>
> >>>>> into WEB-INF/viewer_wicket.properties (or isis.properties if you
> >>>> prefer).
> >>>>> I'll probably remove this original behaviour before pushing out a
> >> final
> >>>>> release, though.
> >>>>>
> >>>>> Cheers
> >>>>> Dan
> >>>>>
> >>>>>
> >>>>> [1] https://issues.apache.org/jira/browse/ISIS-486
> >>>>> [2] http://isis.apache.org/contributors/building-isis.html
> >>>>
> >>>>
> >>>
> >>
>
>
