You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by Adam Howard <ho...@gmail.com> on 2013/02/13 10:37:40 UTC

"Embedded" objects

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

Re: "Embedded" objects

Posted by Adam Howard <ho...@gmail.com>.
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
<da...@haywood-associates.co.uk>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 <ho...@gmail.com> 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
> >
>

Re: "Embedded" objects

Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <ho...@gmail.com> 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
>