Hi Oscar, I've added some notes to your ticket. I've quoted them here for your convenience, but if you have any remarks probably best to update the ticket rather than continue this thread.
Thx Dan ____________ my additions to the ticket: *I'd like to refine the concept of wrapping while implementing this ticket.* *The idea of wrapping was originally to allow the UI to be simulated within integration tests. The intent of this ticket is to formalize the idea of the same set of validations being done automatically between programmatic interactions from one service/entity to another service/entity. * *So, the more general concept (common to both UI/domain interactions and domain-to-domain programmatic interactions) is one of _trust boundaries_. If there is no trust from the calling client to the supplying service/entity, then that interaction should be wrapped.* *However, the wrapping model as it currently stands is a little bit too UI/domain oriented, in that it has both hidden AND disabled as well as validate phases. From the perspective of a programmatic domain-to-domain interaction there's no meaningful distinction between the hidden and disabled constraints: they both mean: "that object isn't in a state to be called". In other words its a pre constraint that is not satisfied.* *The other aspect here is that I can imagine that there are actions that we would like to allow to be made programmatically (ie through a wrapper) but which shouldn't be part of the UI. In other words these actions form part of the programmatic API of a module, just not part of its UI.* *Putting all this together, I propose that we slightly change the meaning of wrapping (though we'll keep the current implementation too for backwards compatibility), namely that by default wrapped object will check the disable and validate phases only, ie it will _not_ check the hidden phase. This allows such actions to be indicated as hidden (probably using @ActionLayout or .layout.xml or security) but still able to be called programmatically. The disable phase = pre check.* *We could define the following terminology:* *- "default" wrapping : as described above, checks only disable and validate, not hidden* *- "strict" wrapping - for backward compatibility, also checks hidden first* *We could define a configuration property:* *isis.runtime.wrapping=default | strict | none* *with "default" wrapping being the default if not specified.* *In terms of the programming API, the WrapperFactory#wrap(...) will obviously be less important than it was, because by default objects will be wrapped. For backward compatibilty, I think this should continue to create strict wrappers* *The wrap(...) method is also overloaded, with wrap(ExecutionMode). We can extend this enum:* *- EXECUTE - (existing) returns a strict wrapper* *- SKIP_RULES - (existing) skips applying the hidden/disable/validate rules* *- NO_EXECUTE - (existing) applies hidden/disabled/validate, but does not execute* *- DEFAULT - (new) returns a "default" wrapper, applies only disable/validate but not hidden* *(new:) if the object passed in is already wrapped, then it should be replaced with a wrapper with the specified mode. Prevoiusly this was a no-op, I think.* *The unwrap(...) method is unchanged.* On Fri, 5 Jan 2018 at 13:36 Dan Haywood <[email protected]> wrote: > Thanks for this, Oscar. > > On Fri, 5 Jan 2018 at 13:09 Óscar Bou - GOVERTIS <[email protected]> > wrote: > >> >> >> Just created [1]. >> >> Please, comment on this. >> >> Thanks, >> >> Oscar >> >> >> >> [1] https://issues.apache.org/jira/browse/ISIS-1807 >> >> >> El 5 ene 2018, a las 14:01, Dan Haywood <[email protected]> >> escribió: >> >> Yes, please, Oscar. You've the most experience here with this so you >> know exactly what you're after. >> >> Thx >> Dan >> >> >> On Fri, 5 Jan 2018 at 12:58 Óscar Bou - GOVERTIS <[email protected]> >> wrote: >> >>> >>> >>> Hi Dan. >>> >>> Just search for all tickets containing “wrap” and didn’t find one >>> related to this proposal … >>> >>> Can create one. >>> >>> >>> >>> >>> El 5 ene 2018, a las 13:47, Dan Haywood <[email protected]> >>> escribió: >>> >>> Thanks, Oscar. >>> >>> Yes, I forgot that, but you are right, we did say at the mini-conf back >>> in >>> Jun that this would be in scope for 2.0.0. It probably should be >>> configurable so it can be disabled if nec, but by default be enabled. >>> >>> Is there a ticket for it, do you happen to know? >>> >>> Thx >>> Dan >>> >>> On Fri, 5 Jan 2018 at 12:44 Óscar Bou <[email protected]> wrote: >>> >>> >>> Hi Dan, >>> >>> I would also considered the “always wrapped” theme, as a way to ensure >>> Domain Entities always are conformant to their hide/disable/validate >>> constraints (and other forced through actions). >>> >>> To me that was a very compelling feature at the very beginning (despite >>> of >>> the current cost of invoking always wrapped). >>> Sure it has avoided many, many bugs in production and have ease testing a >>> lot. >>> >>> >>> I would propose this the default behaviour, but perhaps others think >>> different. >>> Probably it might be disabled (i.e., optional). >>> >>> Regards, >>> >>> Oscar >>> >>> >>> El 5 ene 2018, a las 13:38, Dan Haywood <[email protected]> >>> >>> escribió: >>> >>> >>> Folks, >>> >>> as you saw, I cut a 1.16.0-RC1 release yesterday. If this passes the >>> >>> vote, >>> >>> I propose this to be the last release in the 1.x codeline. >>> >>> For 2.0.0 we have several themes: >>> - move to JDK8 >>> - upgrade to DN 5.1 >>> - compatibility with JEE 7 >>> - meta-annotations >>> - remove deprecations >>> >>> Quite a bit of work has been done in these areas already, but to reduce >>> >>> the >>> >>> risk I propose that we have a number of milestone releases. The Apache >>> Wicket project does this for the major releases, as do others I'm sure, >>> >>> and >>> >>> I think it's a good practice to follow. >>> >>> For 2.0.0-M1, I propose: >>> - move to JDK8 >>> - remove deprecations >>> - meta-annotations >>> >>> For 2.0.0-M2, I propose >>> - upgrade to DN 5.1 >>> - compatibility with JEE 7 >>> >>> You'll see that I've created releases in Isis for this (see our kanban >>> board [1]). In git there's also two branches: >>> - dev/2.0.0-M1 >>> - dev/2.0.0-M2 >>> >>> When 1.16.0 is released, I'll merge into dev/2.0.0-M1. >>> >>> I suggest that new tickets are done as feature branches of either of >>> these. This will then make it easy to (later on) rebase all of >>> dev/2.0.0-M2 onto dev/2.0.0-M1 (and similarly for any -M3, -M4 branches >>> >>> we >>> >>> might decide to have). >>> >>> Let me know if you have any thoughts/refinements/concerns relating to the >>> above >>> >>> Thx >>> Dan >>> >>> >>> [1] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=87 >>> >>> >>> >>> >>> >>> Óscar Bou Bou >>> Socio - IT & GRC Management Services Director >>> m: +34 620 267 520 <+34%20620%2026%2075%2020> >>> s: <http://www.govertis.com/>www.govertis.com e: [email protected] >>> >>> LinkedIn: 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 >>> <https://maps.google.com/?q=Avda+Cortes+Valencianas,+58+%E2%80%93+8%C2%BA+-+6%C2%AA.+46015+-+Valencia&entry=gmail&source=g>, >>> y Paseo de la Castellana, 153, 28045 - MADRID >>> <https://maps.google.com/?q=Paseo+de+la+Castellana,+153,+28045+-+MADRID&entry=gmail&source=g>. >>> Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos >>> adjuntos no contengan virus informáticos, y en caso que los tuvieran >>> eliminarlos. >>> >>> >> >> Óscar Bou Bou >> Socio - IT & GRC Management Services Director >> m: +34 620 267 520 <+34%20620%2026%2075%2020> >> s: <http://www.govertis.com>www.govertis.com e: [email protected] >> >> LinkedIn: 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 >> <https://maps.google.com/?q=Avda+Cortes+Valencianas,+58+%E2%80%93+8%C2%BA+-+6%C2%AA.+46015+-+Valencia&entry=gmail&source=g>, >> y Paseo de la Castellana, 153, 28045 - MADRID >> <https://maps.google.com/?q=Paseo+de+la+Castellana,+153,+28045+-+MADRID&entry=gmail&source=g>. >> Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos >> adjuntos no contengan virus informáticos, y en caso que los tuvieran >> eliminarlos. >> >>
