isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Cameron <steve.cameron...@gmail.com>
Subject Re: How to display value object
Date Thu, 17 Aug 2017 05:50:45 GMT
Sorry, essentially the new ValueObject class is:

@DomainObject()
public class ValueObject {

    public ValueObject(final String name, final String notes) {
        setName(name);
        setNotes(notes);
    }

    @javax.jdo.annotations.Column(allowsNull = "false", length = 40)
    @Getter @Setter(AccessLevel.PRIVATE)
    @Title(prepend = "Object: ")
    private String name;

    @javax.jdo.annotations.Column(allowsNull = "true", length = 4000)
    @Getter @Setter(AccessLevel.PRIVATE)
    private String notes;

But that its immutable (private setters) is not that important in the end
as its managed from a SimpleObject action and cannot be displayed via a
link. You might just guess its URL I suppose.



On Thu, Aug 17, 2017 at 2:56 PM, Stephen Cameron <steve.cameron.62@gmail.com
> wrote:

> Hi,
>
> In my hurried initial response to this question I suggested to create a
> value object with only getters. Isis will display such properties as read
> only, which is essentially what you are looking for. However, this won't
> work with DataNucleus if you are to persist it, but you can have public
> getters and private setters, which still works with DataNucleus.
>
> Trying this out with the simpleapp archetype, I created a second class
> 'ValueObject' (as a copy of the 'SimpleObject' class). This worked, but
> going one step further I made both getter and setter private and added a
> derived property so that the ValueObject will be displayed not as a link
> but as a String.
>
> So this was all that was needed in SimpleObject:
>
>     @javax.jdo.annotations.Column(allowsNull = "true")
>     @Getter(value=AccessLevel.PRIVATE) @Setter(value=AccessLevel.PRIVATE)
>     private ValueObject valueObject;
>
>     @javax.jdo.annotations.NotPersistent()
>     public String getValueObjectAsString(){
>         return getValueObject() != null ? getValueObject().toString() :
> null;
>     }
>
>     public SimpleObject updateValueObject(@ParameterLayout(named="Name")
> String name, @Parameter(optionality=Optionality.OPTIONAL)
> @ParameterLayout(named="Notes", multiLine=5) String notes){
>         if(getValueObject() != null){
>             ValueObject obj = getValueObject();
>             setValueObject(null);
>             SimpleObjectRepositoryService.deleteValueObject(obj);
>         }
>         setValueObject(SimpleObjectRepositoryService.createValueObject(name,
> notes));
>         return this;
>     }
>
> and:
>
>     @javax.inject.Inject
>     SimpleObjectRepository SimpleObjectRepositoryService;
>
> I also changed the SimpleObjectRepository to control the creation and
> deletion of both the SimpleObject and the ValueObject classes.
>
> Then in the SimpleObject.layout.xml I added:
>
>                                 <c:property id="valueObjectAsString">
>                                     <c:named>Value Object</c:named>
>                                     <c:action id="updateValueObject">
>                                         <c:describedAs>Sets the Value
> Object</c:describedAs>
>                                     </c:action>
>                                 </c:property>
>
> This all works very nicely to my mind, including the new inline updating
> of the ValueObject in Wicket Viewer in 1.15.0.
>
> I think this illustrates the gist of Kevin's reply. Regarding the need for
> distinct annotations for value objects, there may be arguments for not
> having a separate table for the persisting value object instances, but I'd
> be surprised if there is great benefits from that. DataNucleus does an
> outer join to find a SimpleObject and its ValueObject (if present), so that
> is quite efficient.
>
> So to me the main question is that raised by Kevin regarding shared (1-n)
> value objects and the need to manage these, adding a
> 'findOrCreateValueObject' method instead of the createValueObject would
> seem to be a simple answer for this. If the find part is effective then
> there is no need to delete any values ever.
>
> In terms of real world examples of the value of value objects, having a
> list of suburb and postcode value objects solved a range of data quality
> issues for me, preventing people from mis-spelling suburb names and getting
> many postcodes wrong. In that case though users browse the List of Suburb
> value objects and then the name and postcode of the chosen one are copied
> into the suburb and postcode properties of the address, meaning other
> systems looking at the address table see those values and don't have to do
> a join.
>
> Steve
>
>
>
> On Tue, Aug 15, 2017 at 7:55 PM, Kevin Meyer <kevin@kmz.co.za> wrote:
>
>> Hi Ekko,
>>
>> I believe Dan has answered the question that you asked. However I think it
>> is worth mentioning that (as I see it), Apache Isis does not treat the
>> different objects in the way that I think you are considering them.
>>
>> While DDD may make the distinction between "value" and "entity" e.g. [1],
>> in Apache Isis, all annotated objects are entities and persisted to the
>> database.
>>
>> By annotating a "value" object e.g. in [2] with @PrimaryKey (and @Column),
>> you are declaring that that are to be persisted - that they are entities.
>>
>> In your case "CustomerContactInfomation" is an entity. You just want to
>> subordinate maintenance and viewing to the Customer entity.
>>
>> True DDD "value" objects (which are also immutable) would not be persisted
>> in their own table - there is no need and you'd fill up a table with old
>> entries that are no longer needed (the Location in the example [1]).
>> To me, the "immutable" aspect of a value object means that *if* you did
>> persist it to a table, you'd want to delete the old entry as soon as the
>> value changes or the reference count drops to zero.
>>
>> In Apache Isis you would make them properties of the parent. It was once
>> possible to write ValueAdapters that could serialise a value class into
>> (one or more) columns of the table used to persist the "parent" entity and
>> the framework would maintain (serialise/deserialise) these "value" object
>> properties for you.
>> However these ValueAdapters are no longer supported (the behaviour is now
>> achieved in other ways).
>>
>> In short - in Apache Isis all "database" annotated objects are entities.
>> But you can tweak the presentation of data from these entities with the
>> use of annotations and actions (on the "parent") to enforce the
>> subordination expected of a "value" object.
>>
>> Cheers,
>> Kevin
>>
>> [1] http://culttt.com/2014/04/30/difference-entities-value-objects/
>> [2] https://stackoverflow.com/a/45662839/56880
>>
>> > Hi support,
>> >
>> >
>> > I'm building project with Apache Isis,but I have some confusion.
>> >
>> >
>> > In DDD,I know there have two objects,entity & value object.
>> >
>> >
>> > When I plan a DomainObject,eg. Customer, a entity object. I think one
>> > Customer may be have many value objects,for example contact information
>> > or other value objects.
>> >
>> > So I plan a value object called CustomerContactInformation,may be have
>> > other value objects.
>> >
>> > For the database,a entity object and its value objects may be persist to
>> > diff tables.
>> >
>> > I think CustomerContactInformation just a value object,it can not have
>> > any actions and should be maintained by Customer.
>> >
>> > In fact,Customer-CustomerContactInfomation definitely is 1-1.
>> >
>> >
>> > Now,how should I display CustomerContactInformation in Customer's layout
>> > and be able to edit CustomerContactInformation?
>> >
>> > Any ideas?
>> >
>> >
>> > Ekko
>> >
>> >
>> >
>>
>>
>> --
>> Kevin Meyer
>> Ljubljana, Slovenia
>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message