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.
> > > > >
> > > >
> > >
> >
>
