You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Andi Huber <ah...@apache.org> on 2019/09/22 08:00:41 UTC
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
Re: Extending the Programming Model with @Support?
Posted by Jayesh Prajapati <ja...@gmail.com>.
Anything which saves time in troubleshooting such issue is more than
welcome 😊
Thanks,
Jayesh
On Sun, Sep 22, 2019, 13:30 Andi Huber <ah...@apache.org> wrote:
> 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
>
Re: AW: Extending the Programming Model with @Support?
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
v2 has the concept of "extensions", so what Andi and I decided (off-line)
is for the @Model annotation to be moved into an optional extension.
That'll make it easy for those who like the idea to include it in their
code, but not to be part of the formal programming model.
Thanks
Dan
On Tue, 24 Sep 2019 at 09:18, Andi Huber <ah...@apache.org> wrote:
> Let me give a short summary of findings so far:
>
> 1. Currently the (core) framework's full introspection validation covers
> you (will emit a validation failure) in case you use one of the reserved
> prefixes for a public method (hide, validate, ...) and you got something
> wrong with it.
>
> 2. If your intent is to write a supporting-method, but you use the wrong
> prefix like ('verify' instead of correct 'validate') or declare it other
> than 'public', the framework will simply ignore your intent.
>
> 3. While not yet implemented, we could in principle allow reserved
> prefixes to be used with Actions/Properties/Collections, as long as
> these are explicitly annotated with @Action/@Property/@Collection.
>
> // should be a valid action name, even though 'disable' is reserved
> @Action public void disableUser(User user) {
> ..
> }
>
> 4. Lets assume we introduce a new annotation @Model (name still open for
> discussion), we then could use this as the semantic counterpart to
> @Programmatic and provide a means to solve (2).
>
> - @Programmatic ... to be ignored by the framework
> - @Model ... NOT to be ignored by the framework
>
> 5. In order to have features like (4) just as an option, without
> changing the framework's default behavior, we could provide these as
> extensions to the framework. So everybody is free to choose whether to
> use them.
>
> 6. The framework has a configuration option to either enforce use of
> annotation @Action or not. The recommended setting is to turn this
> enforcement on, because it allows to get rid of having to use
> @Programmatic on other (public) methods, one wants to be ignored by the
> framework. There is a consistency concern, in case we introduce a
> @Model annotation: Would we also want to provide an option to enforce
> it?
>
> I want to leave the discussion open some more days, and I also would
> like to encourage you to take the opportunity and tell us your personal
> pain-points with the framework in general. Maybe we can address these
> and take your feedback to improve the next release!
>
> Cheers, Andi
>
> On 2019/09/24 05:22:53, Brian K <ha...@gmail.com> wrote:
> > That is what I liked about the original version (Naked Objects). It was
> > very easy to start using. I don't recall any scaffolding needed in the
> > object classes. All method name conventions were interpreted the way
> > you'd expect. Maybe an improvement would be to implement defaults so a
> new
> > user doesn't have to copy from an example to get the annotations right.
> >
> > Annotations have the IDE advantage over name conventions, though. If we
> > implemented the support methods with an annotation `ActionModel` then I'd
> > expect that typing in `@ActionModel(` in Eclipse would give me all the
> > types of support options available to me.
> >
> > -Brian
> >
> > On Mon, Sep 23, 2019, 5:18 AM Johan Doornenbal <jd...@incode.org>
> > wrote:
> >
> > > 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 <ah...@apache.org>:
> > >
> > > > 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 <ah...@apache.org> 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 <da...@haywood-associates.co.uk>
> > > > 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, <ha...@gmail.com>
> > > 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 <ah...@apache.org>
> > > > 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"
> > > > > > > > <Jo...@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:ahuber@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.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> > On Mon, Sep 23, 2019, 5:18 AM Johan Doornenbal <jd...@incode.org>
> > wrote:
> >
> > > 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 <ah...@apache.org>:
> > >
> > > > 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 <ah...@apache.org> 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 <da...@haywood-associates.co.uk>
> > > > 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, <ha...@gmail.com>
> > > 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 <ah...@apache.org>
> > > > 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"
> > > > > > > > <Jo...@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:ahuber@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.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: AW: Extending the Programming Model with @Support?
Posted by Andi Huber <ah...@apache.org>.
Let me give a short summary of findings so far:
1. Currently the (core) framework's full introspection validation covers
you (will emit a validation failure) in case you use one of the reserved
prefixes for a public method (hide, validate, ...) and you got something
wrong with it.
2. If your intent is to write a supporting-method, but you use the wrong
prefix like ('verify' instead of correct 'validate') or declare it other
than 'public', the framework will simply ignore your intent.
3. While not yet implemented, we could in principle allow reserved
prefixes to be used with Actions/Properties/Collections, as long as
these are explicitly annotated with @Action/@Property/@Collection.
// should be a valid action name, even though 'disable' is reserved
@Action public void disableUser(User user) {
..
}
4. Lets assume we introduce a new annotation @Model (name still open for
discussion), we then could use this as the semantic counterpart to
@Programmatic and provide a means to solve (2).
- @Programmatic ... to be ignored by the framework
- @Model ... NOT to be ignored by the framework
5. In order to have features like (4) just as an option, without
changing the framework's default behavior, we could provide these as
extensions to the framework. So everybody is free to choose whether to
use them.
6. The framework has a configuration option to either enforce use of
annotation @Action or not. The recommended setting is to turn this
enforcement on, because it allows to get rid of having to use
@Programmatic on other (public) methods, one wants to be ignored by the
framework. There is a consistency concern, in case we introduce a
@Model annotation: Would we also want to provide an option to enforce
it?
I want to leave the discussion open some more days, and I also would
like to encourage you to take the opportunity and tell us your personal
pain-points with the framework in general. Maybe we can address these
and take your feedback to improve the next release!
Cheers, Andi
On 2019/09/24 05:22:53, Brian K <ha...@gmail.com> wrote:
> That is what I liked about the original version (Naked Objects). It was
> very easy to start using. I don't recall any scaffolding needed in the
> object classes. All method name conventions were interpreted the way
> you'd expect. Maybe an improvement would be to implement defaults so a new
> user doesn't have to copy from an example to get the annotations right.
>
> Annotations have the IDE advantage over name conventions, though. If we
> implemented the support methods with an annotation `ActionModel` then I'd
> expect that typing in `@ActionModel(` in Eclipse would give me all the
> types of support options available to me.
>
> -Brian
>
> On Mon, Sep 23, 2019, 5:18 AM Johan Doornenbal <jd...@incode.org>
> wrote:
>
> > 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 <ah...@apache.org>:
> >
> > > 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 <ah...@apache.org> 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 <da...@haywood-associates.co.uk>
> > > 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, <ha...@gmail.com>
> > 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 <ah...@apache.org>
> > > 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"
> > > > > > > <Jo...@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:ahuber@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.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> On Mon, Sep 23, 2019, 5:18 AM Johan Doornenbal <jd...@incode.org>
> wrote:
>
> > 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 <ah...@apache.org>:
> >
> > > 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 <ah...@apache.org> 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 <da...@haywood-associates.co.uk>
> > > 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, <ha...@gmail.com>
> > 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 <ah...@apache.org>
> > > 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"
> > > > > > > <Jo...@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:ahuber@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.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: AW: Extending the Programming Model with @Support?
Posted by Brian K <ha...@gmail.com>.
That is what I liked about the original version (Naked Objects). It was
very easy to start using. I don't recall any scaffolding needed in the
object classes. All method name conventions were interpreted the way
you'd expect. Maybe an improvement would be to implement defaults so a new
user doesn't have to copy from an example to get the annotations right.
Annotations have the IDE advantage over name conventions, though. If we
implemented the support methods with an annotation `ActionModel` then I'd
expect that typing in `@ActionModel(` in Eclipse would give me all the
types of support options available to me.
-Brian
On Mon, Sep 23, 2019, 5:18 AM Johan Doornenbal <jd...@incode.org>
wrote:
> 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 <ah...@apache.org>:
>
> > 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 <ah...@apache.org> 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 <da...@haywood-associates.co.uk>
> > 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, <ha...@gmail.com>
> 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 <ah...@apache.org>
> > 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"
> > > > > > <Jo...@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:ahuber@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.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
On Mon, Sep 23, 2019, 5:18 AM Johan Doornenbal <jd...@incode.org>
wrote:
> 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 <ah...@apache.org>:
>
> > 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 <ah...@apache.org> 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 <da...@haywood-associates.co.uk>
> > 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, <ha...@gmail.com>
> 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 <ah...@apache.org>
> > 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"
> > > > > > <Jo...@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:ahuber@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.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: AW: Extending the Programming Model with @Support?
Posted by Johan Doornenbal <jd...@incode.org>.
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 <ah...@apache.org>:
> 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 <ah...@apache.org> 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 <da...@haywood-associates.co.uk>
> 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, <ha...@gmail.com> 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 <ah...@apache.org>
> 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"
> > > > > <Jo...@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:ahuber@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.
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: AW: Extending the Programming Model with @Support?
Posted by Andi Huber <ah...@apache.org>.
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 <ah...@apache.org> 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 <da...@haywood-associates.co.uk> 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, <ha...@gmail.com> 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 <ah...@apache.org> 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"
> > > > <Jo...@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:ahuber@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.
> > > > >
> > > >
> > >
> >
>
Re: Extending the Programming Model with @Support?
Posted by Patrick Pliessnig <p....@gmail.com>.
Am 23.09.2019 um 13:26 schrieb Andi Huber:
> I do also prefer @Model. Only inconvenience is that there's already a
> @Model defined [1] with JEE.
>
> Your proposed @Collection(rules={addTo, removeFrom}) would do the
> trick as well, but when typing that, your IDE will not provide any
> auto-completion, which might be a little cumbersome.
>
> Thanks for the feedback though!
>
> [1]
> https://docs.oracle.com/javaee/7/api/javax/enterprise/inject/Model.html
>
> On 23.09.2019 10:14, Patrick Pliessnig wrote:
>> I think it's about model validation, not support validation.
>> Therefore I prefer @Model to @Support
>>
>> In my opinion the term 'support' is somewhat fuzzy. Supporting
>> methods are business rules that helps model actions, properties,
>> collections. Thus it could make sense to 'declare' those rules in one
>> place together with other properties to document the intent.
>>
>> eg:
>> you have a collection myCollection and you want rules that specifies
>> how to add and remove a child. Then you could annotate myCollection
>> with @Collection(rules={addTo, removeFrom}). The model validator
>> could then fail fast if it does not find supporting methods with the
>> required prefix. No cluttering.
>>
>> Patrick
>>
>>
>> Am 23.09.2019 um 07:54 schrieb Andi Huber:
>>> 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 <da...@haywood-associates.co.uk>
>>> 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, <ha...@gmail.com> 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 <ah...@apache.org> 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"
>>>>>> <Jo...@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:ahuber@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.
>>
Re: AW: Extending the Programming Model with @Support?
Posted by Andi Huber <ah...@apache.org>.
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 <da...@haywood-associates.co.uk> 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, <ha...@gmail.com> 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 <ah...@apache.org> 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"
> > > <Jo...@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:ahuber@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.
> > > >
> > >
> >
>
Re: AW: Extending the Programming Model with @Support?
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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, <ha...@gmail.com> 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 <ah...@apache.org> 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"
> > <Jo...@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:ahuber@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.
> > >
> >
>
Re: AW: Extending the Programming Model with @Support?
Posted by Brian K <ha...@gmail.com>.
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 <ah...@apache.org> 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"
> <Jo...@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:ahuber@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.
> >
>
Re: AW: Extending the Programming Model with @Support?
Posted by Andi Huber <ah...@apache.org>.
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" <Jo...@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:ahuber@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.
>
AW: Extending the Programming Model with @Support?
Posted by "Rade, Joerg / Kuehne + Nagel / HAM GI-DP" <Jo...@Kuehne-Nagel.com>.
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:ahuber@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.