Thanks Dan. I was just writing this response in the other thread.

Yes, you've answered my questions. I'm making a list of the changes I've
had to make as I port the dddsample that I want to address after it's up
and running. I'll add this to the list.


On Wed, Feb 13, 2013 at 4:34 AM, Dan Haywood
<[email protected]>wrote:

> Hi Adam,
> so I think these are pretty much the same questions as you asked in the
> earlier thread (and they are good ones).
>
> What we could do, perhaps, is enhance the Wicket viewer so that any
> @Aggregated entity is rendered in the way you describe, effectively
> "inlined".  this would happen either as a property, or as a parameter.
>
> We already the @Aggregated annotation, and its intended semantic is exactly
> this.
>
> Go ahead and raise a JIRA if you wish.
>
> Cheers
> Dan
>
>
> On 13 February 2013 09:37, Adam Howard <[email protected]> wrote:
>
> > Hi All,
> >
> > These are questions that came up while working on the dddsample port[1]
> > that I thought I would move to their own thread since they are general in
> > nature.
> >
> > I'm trying to do something similar to what is described in Dan's book in
> > section 9.2. It describes factoring out a class to hold several
> properties
> > that are related.
> >
> > public class Customer {
> >   private String firstName;
> >   private String lastName;
> >   ...
> > }
> >
> > becomes
> >
> > public class Name {
> >   private String firstName;
> >   private String lastName;
> >   ...
> > }
> > public class Customer {
> >   private Name name;
> >   ...
> > }
> >
> > In a non-Naked Objects application, I would map this in the database
> myself
> > as Customer having name_first_name and name_last_name columns. In a
> sense,
> > embedding the state of the Name object into the Customer record rather
> than
> > creating a Name table and giving Customer a name_id. In fact, JPA has an
> > @Embeddable annotation for this (which is also described in section
> 16.2.)
> >
> > While in the example above Name refers only to "primitive" types (String)
> > which are easy to embed, I want my factored out classes to refer to other
> > entities.
> >
> > Two examples are Itinerary[2] which holds a List<Leg> and
> > RouteSpecification[3] which hold two Locations and a Date. Leg and
> Location
> > are both persisted entities. Itinerary and RouteSpecification are not
> > entities but are meant to be embedded in a Cargo[4] and also passed
> around
> > to methods. Both of these classes serve a purpose greater than keeping
> > multiple fields together by including "helper" methods related to their
> > properties.
> >
> > Here are my questions:
> >
> > 1. How can I tell Isis (both up into the viewer and down into the
> > persistor) that the fields that make up RouteSpecification should be
> > embedded when displaying or storing a Cargo?
> >
> > 2. How can I create a factory method for creating a Cargo the takes a
> > RouteSpecification as a parameter that will display the three fields that
> > make up a RouteSpecification as inputs? See bookNewCargo[5] and original
> > screenshot[6].
> >
> > Thanks.
> > --
> > Adam
> >
> > [1] https://github.com/adamhoward/onaboat
> > [2]
> >
> >
> https://github.com/adamhoward/onaboat/blob/master/dom/src/main/java/onaboat/domain/model/cargo/Itinerary.java
> > [3]
> >
> >
> https://github.com/adamhoward/onaboat/blob/master/dom/src/main/java/onaboat/domain/model/cargo/RouteSpecification.java
> > [4]
> >
> >
> https://github.com/adamhoward/onaboat/blob/master/dom/src/main/java/onaboat/domain/model/cargo/Cargo.java
> > [5]
> >
> >
> https://github.com/adamhoward/onaboat/blob/master/dom/src/main/java/onaboat/domain/model/cargo/CargoRepository.java
> > [6] https://www.dropbox.com/s/dqbzm6prgvfdiqv/book-new-cargo.png
> >
>

Reply via email to