Re: Extending the Programming Model with @Support?

[Patrick Pliessnig]

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 <d...@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, <harvestmoon...@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 <ahu...@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"
<joerg.r...@kuehne-nagel.com> wrote:

Hi Andi,

I like the idea of using an annotation, because it makes the

programming

model more consistent.

Maybe @Action(type=Supporting) ?

-j
-----Ursprüngliche Nachricht-----
Von: Andi Huber [mailto:ahu...@apache.org]
Gesendet: Sonntag, 22. September 2019 10:01
An: users@isis.apache.org
Betreff: Extending the Programming Model with @Support?

Hi folks,

we are still making progress towards Apache Isis Version 2. While most

of the work goes into technical topics that stay under the hood, like

decoupling from JDO, there are also some changes to the programming

model,

that will affect you and require migration of your domain-code.

We have no concrete release plan yet, we thought maybe October for a

preview, we'll see.

Anyway I do have a questions regarding the programming model:

Have you ever run into the issue of misspelling a supporting-method

within your domain-code

eg. verifyMyAction(...) instead of correct validateMyAction(...) then

spending some time to troubleshot this? What an inconvenience!

My proposed solution to this is to introduce a new annotation to make a

contract with the domain-model (meta-model) :

@Action
public void myAction() {

}

@Support // <-- to enforce a contract with the domain-model
public boolean hideMyAction() {
     ...
}

* The 'hideMyAction' method is termed 'supporting-method'. We have lots

of variants of these. (validateX, disableX, ...)

* This contract allows for a check whether the intended

supporting-method gets picked up by the framework and is not ignored.

That

way we can emit a validation failure, if a support-method is misspelled

or

does have any other deficiencies.

* The @Support annotation is optional, does not require you to migrate

your domain-code.

Do you like the concept? Should we use a better name for the

annotation?

Can we reuse/repurpose any existing annotation?

Any thoughts?

Cheers, Andi

Kühne + Nagel (AG & Co.) KG
Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE

812773878.

Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Holger Ketz (Vors. ),

Martin Brinkmann, Lars-Olof Grün, Matthias Knicky, Nicholas Minde,

Johannes

Trimborn, Lars Wedel, Matthias Weiner.

Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform:

Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745,
Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.

Geschäftsleitung Region Europa: Dr. Hansjörg Rodi (Vors.), Mart Ambur,

Tom Ban, Dominic Edmonds, Thierry Held, Uwe Hött, Richard Huhn,

Jan-Hendrik

Köstergarten, Heiko Schuhmacher.

Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen

Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen in Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden (§ 431 HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen Transporten unter Einschluss einer Seebeförderung und bei unbekanntem Schadenort auf

2

SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg zusätzlich auf

1,25

Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je

Schadenereignis,

mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf unserer Webseite als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne

zu.