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" <joerg.r...@kuehne-nagel.com> 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:ahu...@apache.org] > Gesendet: Sonntag, 22. September 2019 10:01 > An: users@isis.apache.org > 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. >
