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
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
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
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
Anything which saves time in troubleshooting such issue is more than
welcome
Thanks,
Jayesh
On Sun, Sep 22, 2019, 13:30 Andi Huber 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,
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
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
