Hi Dan,
Would it make any difference if BasketItem was a specific type rather than
an Object?
@Named("Basket Item") final Object obj)
Is it the anonymous type or the fact that the object is nested that is the
problem?
Regards,
Ged
On 28 March 2014 07:18, Dan Haywood <[email protected]> wrote:
> On 27 March 2014 22:49, Tomoloju, Ola <[email protected]> wrote:
>
> >
> > The getBasket () action method does the following:
> >
> > 1. Checks if there exists a basket for the a product (BasketItem)
> >
> > 2. If there is no basket, it creates one and adds the product
> >
> > 3. If there is an existing basket it, it adds the product to the
> > basket
> >
> >
> >
> > So, I am not sure if your earlier statement apply "RO only supports the
> > idea of passing a reference to an existing persistent object" , Sorry if
> I
> > was not clear enough.
> >
> > The method name might be misleading, but getBasket (adds BasketItem to
> the
> > basket) and returns the basket.
> >
> >
> The existing persistent object would be the BasketItem.
>
> Looking at the sample data, though, I think your domain is a bit confused.
>
> What exactly are the items being added? It looks like a van rental system.
> Does the customer rent a specific van, or is that they rent the
> specification for a van? In fact, it seems even more involved, that
> there's a start and end destination.
>
> It's like the difference between a book and a title: a book is a tangible
> thing ("you can stub your toe on t"), whereas a title is an ISBN entry in a
> catalog. A book references its title. In a library system you would
> reserve a title ("Harry Potter"), but borrow a book ("our third copy of
> Harry Potter with a torn page").
>
> Going back to your domain, you need to first create the vanRental, then
> call getBasket to lazily create the basket and add the vanRental into it.
> You are right that the action is misnamed; I think that putItemIntoBasket
> (with IDEMPOTENT semantics) would be a better name.
>
> Why not sketch up a little UML diagram (in yuml.me) to verify all this,
> before continuing coding. One of the major benefits of Isis is that it
> really forces you - early on - to clarify your domain. If you don't have
> it right, it's not really possible to ignore it with the other layers of
> your app.
>
> Dan
>
> >
> >
>
