Hi Dan,
I could not find anything in the code base called ValueAdapter.java any more,
and there is nothing on our online documentation... where are they currently?
And even more frustrating, I'm sure I saw something on the DataNucleus website
about custom value types, but then I was unable to find it again! Can you point
me to the DataNucleus API please?
I think there is value (pun not intended) to have more complex values encoded
into additional columns by the underlying persistence engine, rather than
forcing users to encode their value object classes into hidden string
properties and exposed via wrapper getters+actions.
Thanks,
Kevin
On 15 August 2017 20:55:01 CEST, Dan Haywood <d...@haywood-associates.co.uk>
wrote:
>As Kevin says, the framework had (actually, still has) ValueAdapters
>which
>were originally used for several related purposes:
>1. to convert a value into a string (and back again) so it could be
>persisted in an object store (eg the XML object store we once had, or
>Prevayler)
>2. to parse a string into a value when entered in a field (used by the
>old
>drag-n-drop viewer)
>3. to support the old client/server architecture, whereby objects would
>be
>serialized and sent from backend server to front-end viewer
>
>Of these use cases:
>1. is now handled by DataNucleus. It defines its own API for
>serializing
>custom value types; we use this for JODA date/time and also for our own
>Blob, Clob, Password and Money.
>2. is now handled by Wicket's IConverter APIs (for the Wicket viewer)
>while
>in the Restful Objects viewer has its own code to parse JSON to convert
>into objects and values (eg
>ObjectActionArgHelper#parseAndValidateArguments)
>3 we got rid of the client/server architecture many years ago now.
>
>Speaking for myself, I would like to reintroduce value types as a
>first-class citizen, but without requiring the developer to have to
>write
>lots of code to teach DataNucleus, Wicket and the RO viewer about
>these. I
>don't have a general solution in mind on how to do this. However, for
>very
>simple value types that are just a type-safe wrapper around a single
>field
>(eg Password, or Money, or Temperature, or Email say), then perhaps
>there
>might be a way to support this, eg :
>
>public class Temperature implements
>org.apache.isis.valuetypes.Value<BigDecimal> { ... }
>
>or
>
>@Value(underlying=BigDecimal.class)
>public class Temperature { ... }
>
>The idea here is that the framework would treat any instance of this
>custom
>value type as if it were the underlying type (BigDecimal in the case
>above). It would also be possible to apply validations to the value
>type
>that would apply everywhere it is used as a property/parameter.
>
>I couldn't find any existing ticket for this idea, so I've created a
>one [1]
>
>HTH
>Dan
>
>[1] https://issues.apache.org/jira/browse/ISIS-1695
>
>
>On Tue, 15 Aug 2017 at 16:18 Patrick Pliessnig <p.pliess...@gmx.net>
>wrote:
>
>> Hey Kevin
>>
>> What other behaviour has replaced ValueAdapters?
>>
>> Cheers
>> Patrick
>>
>>
>> Am 15.08.2017 um 11:55 schrieb Kevin Meyer:
>> > 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
>> >>
>> >>
>> >>
>> >
>>
>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
