You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Dan Haywood <da...@haywood-associates.co.uk> on 2019/12/04 10:43:53 UTC
Should @Action be mandatory in v2.0 ?
Hi folks,
Canvassing opinions here.
Andi and I are still hard at work on v2.0. We've been chatting offline
about the @Action annotation. Currently this is optional, but there's a
config property (isis.reflector.explicit-annotations.action) that can be
set to require it to be required.
If it's required, then it allows actions that start with a "reserved" word,
such as "clear", "disable" and "addTo" to be used as action names.
What do folks think about this? Obviously it means there's more effort to
migrate to v2.0, but is it a worthwhile trade-off.
A couple of follow-on questions.
First, if we make @Action mandatory, should we do the same for @Property
and @Collection?
Second, if we are being explicit about the "main" methods, should we also
annotate supporting methods? There was an earlier discussion about this,
where Andi had suggested a @Model annotation, the semantic opposite
of @Programmatic. I prefer the name @Supporting, but at any rate the idea
is that the developer would annotate all supporting methods, and the
framework would then be able to ensure that none had become orphaned.
So, to summarise, what do we think about:
- @Action mandatory
- @Property and @Collection also mandatory
- @Supporting as an indicator of any supporting method, to make part of the
metamodel and ensure not orphaned?
Thanks
Re: Should @Action be mandatory in v2.0 ?
Posted by Andi Huber <ah...@apache.org>.
Very interesting view point Óscar!
In principle we can have both idioms:
1. make requirement to annotate everything (@Action/@Property/@Collection) the new default in v2.0
2. we then add a configuration option to provide a list of classes or packages or regex expressions to activate v1.x behavior for a specific set of classes (making @Action/@Property/@Collection optional for just these)
True its more work for us implementing this with the framework, but if both idioms are still required, it seems worth the effort.
Thoughts?
Cheers Andi
On 2019/12/04 12:20:57, Óscar Bou Bou <o....@govertis.com> wrote:
>
>
> Dear all, simply for introducing a new perspective.
>
> A "Security by Design" and "Security by Default" [1] approach would recommend to make explicit decisions for those compromising information security.
>
> Nowadays with all the GDPR buzz, it's also taking great visibility the legally mandatory "Privacy by Design" and "Privacy by Default" [2] related approach.
>
> Taking into account that on many applications data viewed or modified through the UI can be PII (Personally Identifiable Information) they should be taken into account.
>
> An introduction of a new public property could mean the uncontrolled "exposure" through the UI of information regarding an individual (or company sensitive information).
>
> Same way, a new method implemented on a class could introduce a potentially dangerous way to alter confidentiality or integrity of critical information, or launching a background process requiring quite resources, compromising availability (or environment's capacity).
>
> Those principles must be considered by any developer and product manager working under the GDPR, California Consumer Privacy Act (CCPA) or similar legislations, or following best practices in Secure Software Development (the whole industry is moving towards it).
>
>
> Considering all these, I would recommend:
>
> 1. Security and Privacy by Design as default option for version 2 upwards (i.e., requiring explicit annotations).
> 2. Option for keeping all behavior to ease migration to version 1.x projects.
>
> HTH,
>
> Oscar
>
>
> [1] https://www.aeteurope.com/news/security-design-secure-default/
> [2] https://www.avepoint.com/blog/protect/privacy-and-security-by-design-gdpr/
>
>
>
>
>
> El 4/12/19 13:14, "Rade, Joerg / Kuehne + Nagel / HAM GI-DP" <Jo...@Kuehne-Nagel.com> escribió:
>
> Hi,
>
> I see the following aspects:
>
> 1 experienced users migrating an application
> 2 novice users
> 3 effort in implementation
>
> Maybe a final decision can be postponed with being optimized for 3 right now.
> IMO a programming environment optimized for 2 that is as simple and consistent as possible should draw in more users..
>
> -j
> -----Ursprüngliche Nachricht-----
> Von: Dan Haywood [mailto:dan@haywood-associates.co.uk]
> Gesendet: Mittwoch, 4. Dezember 2019 13:05
> An: users
> Betreff: Re: Should @Action be mandatory in v2.0 ?
>
> OK, Johan, thanks for that vote.
>
> I guess we're balancing this against the complexity within the framework,
> to be able to support both styles of programming model. So at the moment
> the framework is more complicated because it does need to support both
> modes. One plus if we do make this change is that @Programmatic goes away
> completely.
>
> A different perspective: this makes the framework more of an opt-in rather
> than an opt-out. I could argue that it also changes the "feel", to more of
> a library than a framework. That is, an Apache Isis v2 app is just a
> Spring Boot app with various domain objects, and they can be made visible
> in the UI if they are annotated.
>
> I'm about 60:40 myself for the proposal ... but that's perhaps because my
> head is in the "framework layer" at the moment rather than at the
> application layer.
>
> Anyone else?
>
>
>
>
>
>
> On Wed, 4 Dec 2019 at 11:54, Johan Doornenbal <jd...@incode.org>
> wrote:
>
> > My first reaction is please don’t. I would really like to see that the
> > amount of annotations needed on an entity or service is the absolute
> > minimum.
> >
> > In other words: sensible defaults that ‘just work’ and annotations when
> > needed.
> >
> > Reserved words can make the framework harder to grasp as well? It would me
> > nice to bring the amount of concepts to works with also down to the bare
> > minimum.
> >
> > Grtz,
> >
> > Johan
> >
> > On Wed, 4 Dec 2019 at 11:44, Dan Haywood <da...@haywood-associates.co.uk>
> > wrote:
> >
> > > Hi folks,
> > >
> > > Canvassing opinions here.
> > >
> > > Andi and I are still hard at work on v2.0. We've been chatting offline
> > > about the @Action annotation. Currently this is optional, but there's a
> > > config property (isis.reflector.explicit-annotations.action) that can be
> > > set to require it to be required.
> > >
> > > If it's required, then it allows actions that start with a "reserved"
> > word,
> > > such as "clear", "disable" and "addTo" to be used as action names.
> > >
> > > What do folks think about this? Obviously it means there's more effort
> > to
> > > migrate to v2.0, but is it a worthwhile trade-off.
> > >
> > > A couple of follow-on questions.
> > >
> > > First, if we make @Action mandatory, should we do the same for @Property
> > > and @Collection?
> > >
> > > Second, if we are being explicit about the "main" methods, should we also
> > > annotate supporting methods? There was an earlier discussion about this,
> > > where Andi had suggested a @Model annotation, the semantic opposite
> > > of @Programmatic. I prefer the name @Supporting, but at any rate the
> > idea
> > > is that the developer would annotate all supporting methods, and the
> > > framework would then be able to ensure that none had become orphaned.
> > >
> > > So, to summarise, what do we think about:
> > > - @Action mandatory
> > > - @Property and @Collection also mandatory
> > > - @Supporting as an indicator of any supporting method, to make part of
> > the
> > > metamodel and ensure not orphaned?
> > >
> > > Thanks
> > >
> >
>
> 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: Should @Action be mandatory in v2.0 ?
Posted by Óscar Bou Bou <o....@govertis.com>.
Dear all, simply for introducing a new perspective.
A "Security by Design" and "Security by Default" [1] approach would recommend to make explicit decisions for those compromising information security.
Nowadays with all the GDPR buzz, it's also taking great visibility the legally mandatory "Privacy by Design" and "Privacy by Default" [2] related approach.
Taking into account that on many applications data viewed or modified through the UI can be PII (Personally Identifiable Information) they should be taken into account.
An introduction of a new public property could mean the uncontrolled "exposure" through the UI of information regarding an individual (or company sensitive information).
Same way, a new method implemented on a class could introduce a potentially dangerous way to alter confidentiality or integrity of critical information, or launching a background process requiring quite resources, compromising availability (or environment's capacity).
Those principles must be considered by any developer and product manager working under the GDPR, California Consumer Privacy Act (CCPA) or similar legislations, or following best practices in Secure Software Development (the whole industry is moving towards it).
Considering all these, I would recommend:
1. Security and Privacy by Design as default option for version 2 upwards (i.e., requiring explicit annotations).
2. Option for keeping all behavior to ease migration to version 1.x projects.
HTH,
Oscar
[1] https://www.aeteurope.com/news/security-design-secure-default/
[2] https://www.avepoint.com/blog/protect/privacy-and-security-by-design-gdpr/
El 4/12/19 13:14, "Rade, Joerg / Kuehne + Nagel / HAM GI-DP" <Jo...@Kuehne-Nagel.com> escribió:
Hi,
I see the following aspects:
1 experienced users migrating an application
2 novice users
3 effort in implementation
Maybe a final decision can be postponed with being optimized for 3 right now.
IMO a programming environment optimized for 2 that is as simple and consistent as possible should draw in more users..
-j
-----Ursprüngliche Nachricht-----
Von: Dan Haywood [mailto:dan@haywood-associates.co.uk]
Gesendet: Mittwoch, 4. Dezember 2019 13:05
An: users
Betreff: Re: Should @Action be mandatory in v2.0 ?
OK, Johan, thanks for that vote.
I guess we're balancing this against the complexity within the framework,
to be able to support both styles of programming model. So at the moment
the framework is more complicated because it does need to support both
modes. One plus if we do make this change is that @Programmatic goes away
completely.
A different perspective: this makes the framework more of an opt-in rather
than an opt-out. I could argue that it also changes the "feel", to more of
a library than a framework. That is, an Apache Isis v2 app is just a
Spring Boot app with various domain objects, and they can be made visible
in the UI if they are annotated.
I'm about 60:40 myself for the proposal ... but that's perhaps because my
head is in the "framework layer" at the moment rather than at the
application layer.
Anyone else?
On Wed, 4 Dec 2019 at 11:54, Johan Doornenbal <jd...@incode.org>
wrote:
> My first reaction is please don’t. I would really like to see that the
> amount of annotations needed on an entity or service is the absolute
> minimum.
>
> In other words: sensible defaults that ‘just work’ and annotations when
> needed.
>
> Reserved words can make the framework harder to grasp as well? It would me
> nice to bring the amount of concepts to works with also down to the bare
> minimum.
>
> Grtz,
>
> Johan
>
> On Wed, 4 Dec 2019 at 11:44, Dan Haywood <da...@haywood-associates.co.uk>
> wrote:
>
> > Hi folks,
> >
> > Canvassing opinions here.
> >
> > Andi and I are still hard at work on v2.0. We've been chatting offline
> > about the @Action annotation. Currently this is optional, but there's a
> > config property (isis.reflector.explicit-annotations.action) that can be
> > set to require it to be required.
> >
> > If it's required, then it allows actions that start with a "reserved"
> word,
> > such as "clear", "disable" and "addTo" to be used as action names.
> >
> > What do folks think about this? Obviously it means there's more effort
> to
> > migrate to v2.0, but is it a worthwhile trade-off.
> >
> > A couple of follow-on questions.
> >
> > First, if we make @Action mandatory, should we do the same for @Property
> > and @Collection?
> >
> > Second, if we are being explicit about the "main" methods, should we also
> > annotate supporting methods? There was an earlier discussion about this,
> > where Andi had suggested a @Model annotation, the semantic opposite
> > of @Programmatic. I prefer the name @Supporting, but at any rate the
> idea
> > is that the developer would annotate all supporting methods, and the
> > framework would then be able to ensure that none had become orphaned.
> >
> > So, to summarise, what do we think about:
> > - @Action mandatory
> > - @Property and @Collection also mandatory
> > - @Supporting as an indicator of any supporting method, to make part of
> the
> > metamodel and ensure not orphaned?
> >
> > Thanks
> >
>
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: Should @Action be mandatory in v2.0 ?
Posted by "Rade, Joerg / Kuehne + Nagel / HAM GI-DP" <Jo...@Kuehne-Nagel.com>.
Hi,
I see the following aspects:
1 experienced users migrating an application
2 novice users
3 effort in implementation
Maybe a final decision can be postponed with being optimized for 3 right now.
IMO a programming environment optimized for 2 that is as simple and consistent as possible should draw in more users..
-j
-----Ursprüngliche Nachricht-----
Von: Dan Haywood [mailto:dan@haywood-associates.co.uk]
Gesendet: Mittwoch, 4. Dezember 2019 13:05
An: users
Betreff: Re: Should @Action be mandatory in v2.0 ?
OK, Johan, thanks for that vote.
I guess we're balancing this against the complexity within the framework,
to be able to support both styles of programming model. So at the moment
the framework is more complicated because it does need to support both
modes. One plus if we do make this change is that @Programmatic goes away
completely.
A different perspective: this makes the framework more of an opt-in rather
than an opt-out. I could argue that it also changes the "feel", to more of
a library than a framework. That is, an Apache Isis v2 app is just a
Spring Boot app with various domain objects, and they can be made visible
in the UI if they are annotated.
I'm about 60:40 myself for the proposal ... but that's perhaps because my
head is in the "framework layer" at the moment rather than at the
application layer.
Anyone else?
On Wed, 4 Dec 2019 at 11:54, Johan Doornenbal <jd...@incode.org>
wrote:
> My first reaction is please don’t. I would really like to see that the
> amount of annotations needed on an entity or service is the absolute
> minimum.
>
> In other words: sensible defaults that ‘just work’ and annotations when
> needed.
>
> Reserved words can make the framework harder to grasp as well? It would me
> nice to bring the amount of concepts to works with also down to the bare
> minimum.
>
> Grtz,
>
> Johan
>
> On Wed, 4 Dec 2019 at 11:44, Dan Haywood <da...@haywood-associates.co.uk>
> wrote:
>
> > Hi folks,
> >
> > Canvassing opinions here.
> >
> > Andi and I are still hard at work on v2.0. We've been chatting offline
> > about the @Action annotation. Currently this is optional, but there's a
> > config property (isis.reflector.explicit-annotations.action) that can be
> > set to require it to be required.
> >
> > If it's required, then it allows actions that start with a "reserved"
> word,
> > such as "clear", "disable" and "addTo" to be used as action names.
> >
> > What do folks think about this? Obviously it means there's more effort
> to
> > migrate to v2.0, but is it a worthwhile trade-off.
> >
> > A couple of follow-on questions.
> >
> > First, if we make @Action mandatory, should we do the same for @Property
> > and @Collection?
> >
> > Second, if we are being explicit about the "main" methods, should we also
> > annotate supporting methods? There was an earlier discussion about this,
> > where Andi had suggested a @Model annotation, the semantic opposite
> > of @Programmatic. I prefer the name @Supporting, but at any rate the
> idea
> > is that the developer would annotate all supporting methods, and the
> > framework would then be able to ensure that none had become orphaned.
> >
> > So, to summarise, what do we think about:
> > - @Action mandatory
> > - @Property and @Collection also mandatory
> > - @Supporting as an indicator of any supporting method, to make part of
> the
> > metamodel and ensure not orphaned?
> >
> > Thanks
> >
>
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: Should @Action be mandatory in v2.0 ?
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
OK, Johan, thanks for that vote.
I guess we're balancing this against the complexity within the framework,
to be able to support both styles of programming model. So at the moment
the framework is more complicated because it does need to support both
modes. One plus if we do make this change is that @Programmatic goes away
completely.
A different perspective: this makes the framework more of an opt-in rather
than an opt-out. I could argue that it also changes the "feel", to more of
a library than a framework. That is, an Apache Isis v2 app is just a
Spring Boot app with various domain objects, and they can be made visible
in the UI if they are annotated.
I'm about 60:40 myself for the proposal ... but that's perhaps because my
head is in the "framework layer" at the moment rather than at the
application layer.
Anyone else?
On Wed, 4 Dec 2019 at 11:54, Johan Doornenbal <jd...@incode.org>
wrote:
> My first reaction is please don’t. I would really like to see that the
> amount of annotations needed on an entity or service is the absolute
> minimum.
>
> In other words: sensible defaults that ‘just work’ and annotations when
> needed.
>
> Reserved words can make the framework harder to grasp as well? It would me
> nice to bring the amount of concepts to works with also down to the bare
> minimum.
>
> Grtz,
>
> Johan
>
> On Wed, 4 Dec 2019 at 11:44, Dan Haywood <da...@haywood-associates.co.uk>
> wrote:
>
> > Hi folks,
> >
> > Canvassing opinions here.
> >
> > Andi and I are still hard at work on v2.0. We've been chatting offline
> > about the @Action annotation. Currently this is optional, but there's a
> > config property (isis.reflector.explicit-annotations.action) that can be
> > set to require it to be required.
> >
> > If it's required, then it allows actions that start with a "reserved"
> word,
> > such as "clear", "disable" and "addTo" to be used as action names.
> >
> > What do folks think about this? Obviously it means there's more effort
> to
> > migrate to v2.0, but is it a worthwhile trade-off.
> >
> > A couple of follow-on questions.
> >
> > First, if we make @Action mandatory, should we do the same for @Property
> > and @Collection?
> >
> > Second, if we are being explicit about the "main" methods, should we also
> > annotate supporting methods? There was an earlier discussion about this,
> > where Andi had suggested a @Model annotation, the semantic opposite
> > of @Programmatic. I prefer the name @Supporting, but at any rate the
> idea
> > is that the developer would annotate all supporting methods, and the
> > framework would then be able to ensure that none had become orphaned.
> >
> > So, to summarise, what do we think about:
> > - @Action mandatory
> > - @Property and @Collection also mandatory
> > - @Supporting as an indicator of any supporting method, to make part of
> the
> > metamodel and ensure not orphaned?
> >
> > Thanks
> >
>
Re: Should @Action be mandatory in v2.0 ?
Posted by Johan Doornenbal <jd...@incode.org>.
My first reaction is please don’t. I would really like to see that the
amount of annotations needed on an entity or service is the absolute
minimum.
In other words: sensible defaults that ‘just work’ and annotations when
needed.
Reserved words can make the framework harder to grasp as well? It would me
nice to bring the amount of concepts to works with also down to the bare
minimum.
Grtz,
Johan
On Wed, 4 Dec 2019 at 11:44, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> Hi folks,
>
> Canvassing opinions here.
>
> Andi and I are still hard at work on v2.0. We've been chatting offline
> about the @Action annotation. Currently this is optional, but there's a
> config property (isis.reflector.explicit-annotations.action) that can be
> set to require it to be required.
>
> If it's required, then it allows actions that start with a "reserved" word,
> such as "clear", "disable" and "addTo" to be used as action names.
>
> What do folks think about this? Obviously it means there's more effort to
> migrate to v2.0, but is it a worthwhile trade-off.
>
> A couple of follow-on questions.
>
> First, if we make @Action mandatory, should we do the same for @Property
> and @Collection?
>
> Second, if we are being explicit about the "main" methods, should we also
> annotate supporting methods? There was an earlier discussion about this,
> where Andi had suggested a @Model annotation, the semantic opposite
> of @Programmatic. I prefer the name @Supporting, but at any rate the idea
> is that the developer would annotate all supporting methods, and the
> framework would then be able to ensure that none had become orphaned.
>
> So, to summarise, what do we think about:
> - @Action mandatory
> - @Property and @Collection also mandatory
> - @Supporting as an indicator of any supporting method, to make part of the
> metamodel and ensure not orphaned?
>
> Thanks
>
Re: Should @Action be mandatory in v2.0 ?
Posted by Kevin Meyer <ke...@apache.org>.
Hi Dan,
Thank you for raising this question here.
To answer your question: I accept that sometimes it makes sense to have
an action that starts with a reserved word. I would prefer an "override"
type of annotation that explicitly marks individual methods as
not-for-metalanguage. Like disabling a compiler warning in source
code...
I.e. with the annotation, "disableX" appears as the "disable X" action.
Without the annotation "disableX" is used by the framework to determine
the enabled/disabled state of "X".
Based on my experiences with software development, I feel that "our"
needs, as developers of the Apache Isis, should always be at the bottom
of the list, that we should place lower value on the effort of
implementation.
The primary focus must always be on "what makes Apache Isis more useful
to it's users?"
Ask the following questions:
- Do we know what our users want?
- Is what Apache Isis provides to our users clear and unambiguous? (Are
we sending mixed messages?)
- Is it clear to visiting, potential users, what Apache Isis does and
provides? (What's our 30 second elevator pitch?)
Personal opinion:
I have always felt that Apache Isis was about making life easier
(faster) for our users. Providing a framework that lets users rapidly
implement a fully functioning application, with easy-to-read user code.
It can optionally support numerous special compile-time-only (or
equivalent) checks:
- business rules that check the metalanguage implementation
Finally, I believe that a significant failure at the moment is that we
don't have good traction with our user community. Or, if we do, it's
that our user community consists of a handful of people, judging by
replies to this mailing list.
Kind regards,
Kevin
On 2019-12-04 10:43, Dan Haywood wrote:
> Hi folks,
>
> Canvassing opinions here.
>
> Andi and I are still hard at work on v2.0. We've been chatting offline
> about the @Action annotation. Currently this is optional, but there's
> a
> config property (isis.reflector.explicit-annotations.action) that can
> be
> set to require it to be required.
>
> If it's required, then it allows actions that start with a "reserved"
> word,
> such as "clear", "disable" and "addTo" to be used as action names.
>
> What do folks think about this? Obviously it means there's more effort
> to
> migrate to v2.0, but is it a worthwhile trade-off.
>
> A couple of follow-on questions.
>
> First, if we make @Action mandatory, should we do the same for
> @Property
> and @Collection?
>
> Second, if we are being explicit about the "main" methods, should we
> also
> annotate supporting methods? There was an earlier discussion about
> this,
> where Andi had suggested a @Model annotation, the semantic opposite
> of @Programmatic. I prefer the name @Supporting, but at any rate the
> idea
> is that the developer would annotate all supporting methods, and the
> framework would then be able to ensure that none had become orphaned.
>
> So, to summarise, what do we think about:
> - @Action mandatory
> - @Property and @Collection also mandatory
> - @Supporting as an indicator of any supporting method, to make part of
> the
> metamodel and ensure not orphaned?
>
> Thanks
--
Kevin Meyer
Ljubljana, Slovenia
Vice President Apache Isis (https://isis.apache.org)
The Apache Software Foundation