Hi all, Nice to have support for Value Objects directly on Apache Isis.
On [1] there’s a description about how do they work on DataNucleus. We can “infer” from DN annotations the existence of the ValueObject (as we do with the @Column annotation, etc.) that could be recorded on the Apache Isis Metamodel and be used afterwards by the viewers etc. There could be also a @ValueObject annotation for Isis extending the programming model, not depending only on JDO annotations (despite on JDO projects the Isis one would not be required unless there are annotation properties that cannot be directly inferred from the JDO annotation - as currently happens with the @DomainObject, that is sometimes useful despite having the class annotated with @PersistenceCapable). Not sure what info. would be needed by Isis, in addition to that provided by the JDO annotation … HTH, Oscar [1] http://www.datanucleus.org/products/accessplatform_4_0/jdo/orm/embedded.html <http://www.datanucleus.org/products/accessplatform_4_0/jdo/orm/embedded.html> > El 16 ago 2017, a las 19:39, Kevin Meyer <[email protected]> escribió: > > 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 <[email protected]> > 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 <[email protected]> >> 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. Óscar Bou Bou Socio - IT & GRC Management Services Director m: +34 620 267 520 s: <http://www.govertis.com/>www.govertis.com <http://www.govertis.com/> e: [email protected] <mailto:[email protected]> LinkedIn: https://www.linkedin.com/in/oscarbou <https://www.linkedin.com/in/oscarbou> Twitter: @oscarbou <https://twitter.com/oscarbou> Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de GOVERTIS ADVISORY SERVICES, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: GOVERTIS ADVISORY SERVICES, S.L. Avda Cortes Valencianas, 58 – 8º - 6ª. 46015 - Valencia, y Paseo de la Castellana, 153, 28045 - MADRID. Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
