Hi all, I have been following the conversation and I tend to agree with Dan. To limit the amount of annotations (and notions / conventions of the framework) in my opinion is more important then the convenience that this might give. I never experienced the need for this feature the last 4 years I have used the framework extensively for Estatio.
Grtz from Johan Op ma 23 sep. 2019 om 14:14 schreef Andi Huber <[email protected]>: > It seems @Model is more popular than @Support, only inconvenience is a > naming clash with [1]. > > I'll bring another aspect to the table, that is prefixes like 'hide', > 'disable', ... could/should be allowed for Actions. We can discuss how > following domain-object examples should get interpreted by the framework. > (Comments according to what I think makes most sense) ... > > public class Object1 { > > @Property @Getter @Setter > private String myProperty; > > // proper supporting-method naming, will get picked up by the > framework and added > // to the metamodel (no annotation required) > public boolean hideMyProperty() { > return false; > } > > } > > public class Object2 { > > @Property @Getter @Setter > private String myProperty; > > // allowed, nothing wrong with that, might either be picked up as an > action > // or gets ignored, depending on the framework's configuration, > // whether the @Action annotation is mandatory or not; > // however, this is no supporting-method! > public boolean hideWhatever() { > return false; > } > > } > > public class Object3 { > > @Property @Getter @Setter > private String myProperty; > > // will fail, because this method is clearly orphaned > @Model > public boolean hideWhatever() { > return false; > } > > } > > [1] > https://docs.oracle.com/javaee/7/api/javax/enterprise/inject/Model.html > > On 2019/09/23 05:54:52, Andi Huber <[email protected]> wrote: > > Yes, there are lots of cases already covered, but not those, when you > get the intended supporting-method's prefix wrong. > > > > Typically, when writing new domain-code I'd start with some properties > and actions and then eventually add supporting-methods. At the time of > writing these, I have a clear intent, that I want these to be added to the > model no matter what, and I want to be warned when I get something wrong. > This annotation (@Support or @Model) should allow me to express this > intent. (However you don't have to, its optional.) > > > > @Brian: You brought the 'addChild(Child ...)' example, where your intent > is to have this as an Action? If so, the framework should be able to > undersand this intent, when the addChild method is annotated with @Action. > Otherwise we have a bug. > > > > Cheers, Andi > > > > On 2019/09/23 03:58:28, Dan Haywood <[email protected]> > wrote: > > > I'm afraid that I don't understand the idea. > > > > > > There are already config properties that enable fail-fast validation > that > > > detect orphaned supporting methods (and other checks besides). Why do > we > > > need an annotation to ask for this to be done? It just adds clutter in > my > > > view? > > > > > > D. > > > > > > On Sun, 22 Sep 2019, 21:07 Brian K, <[email protected]> wrote: > > > > > > > I like the @Support annotation, not @Action, because validate is not > an > > > > action. > > > > > > > > Most of my frustration on this front has been inadvertently creating > a > > > > supporting function. like: > > > > addChild(Child child){...} > > > > > > > > Can these patterns be optional when the annotations are active? > Maybe a > > > > isis.properties switch? > > > > > > > > Thanks! > > > > Brian > > > > > > > > On Sun, Sep 22, 2019 at 3:19 AM Andi Huber <[email protected]> > wrote: > > > > > > > > > If we would not have the freedom of introducing a new annotation, > > > > > @Action(type=Supporting) > > > > > would be a good choice as well, but we also have supporting > methods for > > > > > Properties and Collections! > > > > > > > > > > But since we have @Action, @Property and @Collection all with good > > > > > justification to stand and represent their own kind, we might as > well > > > > > introduce a new one here!? > > > > > > > > > > I was also thinking about @Model, which is a bit more generic and > may > > > > > allow for more flexible use later on. > > > > > > > > > > On 2019/09/22 08:47:20, "Rade, Joerg / Kuehne + Nagel / HAM GI-DP" > > > > > <[email protected]> wrote: > > > > > > Hi Andi, > > > > > > > > > > > > I like the idea of using an annotation, because it makes the > > > > programming > > > > > model more consistent. > > > > > > > > > > > > Maybe @Action(type=Supporting) ? > > > > > > > > > > > > -j > > > > > > -----Ursprüngliche Nachricht----- > > > > > > Von: Andi Huber [mailto:[email protected]] > > > > > > Gesendet: Sonntag, 22. September 2019 10:01 > > > > > > An: [email protected] > > > > > > Betreff: Extending the Programming Model with @Support? > > > > > > > > > > > > Hi folks, > > > > > > > > > > > > we are still making progress towards Apache Isis Version 2. > While most > > > > > of the work goes into technical topics that stay under the hood, > like > > > > > decoupling from JDO, there are also some changes to the programming > > > > model, > > > > > that will affect you and require migration of your domain-code. > > > > > > > > > > > > We have no concrete release plan yet, we thought maybe October > for a > > > > > preview, we'll see. > > > > > > > > > > > > Anyway I do have a questions regarding the programming model: > > > > > > > > > > > > Have you ever run into the issue of misspelling a > supporting-method > > > > > within your domain-code > > > > > > eg. verifyMyAction(...) instead of correct validateMyAction(...) > then > > > > > spending some time to troubleshot this? What an inconvenience! > > > > > > > > > > > > My proposed solution to this is to introduce a new annotation to > make a > > > > > contract with the domain-model (meta-model) : > > > > > > > > > > > > @Action > > > > > > public void myAction() { > > > > > > > > > > > > } > > > > > > > > > > > > @Support // <-- to enforce a contract with the domain-model > > > > > > public boolean hideMyAction() { > > > > > > ... > > > > > > } > > > > > > > > > > > > * The 'hideMyAction' method is termed 'supporting-method'. We > have lots > > > > > of variants of these. (validateX, disableX, ...) > > > > > > * This contract allows for a check whether the intended > > > > > supporting-method gets picked up by the framework and is not > ignored. > > > > That > > > > > way we can emit a validation failure, if a support-method is > misspelled > > > > or > > > > > does have any other deficiencies. > > > > > > * The @Support annotation is optional, does not require you to > migrate > > > > > your domain-code. > > > > > > > > > > > > Do you like the concept? Should we use a better name for the > > > > annotation? > > > > > Can we reuse/repurpose any existing annotation? > > > > > > > > > > > > Any thoughts? > > > > > > > > > > > > Cheers, Andi > > > > > > > > > > > > Kühne + Nagel (AG & Co.) KG > > > > > > Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: > DE > > > > > 812773878. > > > > > > Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Holger Ketz (Vors. > ), > > > > > Martin Brinkmann, Lars-Olof Grün, Matthias Knicky, Nicholas Minde, > > > > Johannes > > > > > Trimborn, Lars Wedel, Matthias Weiner. > > > > > > Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., > Rechtsform: > > > > > Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, > > > > > Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt. > > > > > > Geschäftsleitung Region Europa: Dr. Hansjörg Rodi (Vors.), Mart > Ambur, > > > > > Tom Ban, Dominic Edmonds, Thierry Held, Uwe Hött, Richard Huhn, > > > > Jan-Hendrik > > > > > Köstergarten, Heiko Schuhmacher. > > > > > > > > > > > > Wir arbeiten ausschließlich auf Grundlage der Allgemeinen > Deutschen > > > > > Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 > weichen in > > > > > Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden > (§ 431 > > > > > HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen > Transporten > > > > > unter Einschluss einer Seebeförderung und bei unbekanntem > Schadenort auf > > > > 2 > > > > > SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg zusätzlich > auf > > > > 1,25 > > > > > Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je > > > > Schadenereignis, > > > > > mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf unserer > Webseite > > > > > als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch > gerne > > > > zu. > > > > > > > > > > > > > > > > > > > > >
