[
https://issues.apache.org/jira/browse/ISIS-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Haywood updated ISIS-1807:
------------------------------
Description:
This way, all hide/disable/validate constraints, and other
constraints/invariants forced through actions, are always ensured by default.
This will require to wrap by default:
* New Domain Entity instances / objects (ie, changes on FactoryService).
* Domain Entities returned by queries (ie, changes on RepositoryService).
Users might disable this new default behaviour through configuration, as some
projects can prioritize performance (avoiding wrapping invocations) vs Domain
constraints/invariants enforcement.
~~~~
Dan's notes:
I'd like to refine the concept of wrapping as part of this ticket.
The idea of wrapping was originally to allow the UI to be simulated within
integration tests. The intent of this ticket is to formalize the idea of the
same set of validations being done automatically between programmatic
interactions from one service/entity to another service/entity.
So, the more general concept (common to both UI/domain interactions and
domain-to-domain programmatic interactions) is one of _trust boundaries_. If
there is no trust from the calling client to the supplying service/entity, then
that interaction should be wrapped.
However, the wrapping model as it currently stands is a little bit too
UI/domain oriented, in that it has both hidden AND disabled as well as validate
phases. From the perspective of a programmatic domain-to-domain interaction
there's no meaningful distinction between the hidden and disabled constraints:
they both mean: "that object isn't in a state to be called". In other words
its a pre constraint that is not satisfied.
The other aspect here is that I can imagine that there are actions that we
would like to allow to be made programmatically (ie through a wrapper) but
which shouldn't be part of the UI. In other words these actions form part of
the programmatic API of a module, just not part of its UI.
Putting all this together, I propose that we slightly change the meaning of
wrapping (though we'll keep the current implementation too for backwards
compatibility):
- an implicitly wrapped object will check the disable and validate phases only,
ie it will _not_ check the hidden phase. This allows such actions to be
indicated as hidden (probably using @ActionLayout or .layout.xml or security)
but still able to be called programmatically. The disable phase = pre check.
We could define the following terminology:
- "default" wrapping : as described above, checks only disable and validate,
not hidden
- "strict" wrapping - for backward compatibility, also checks hidden first
was:
This way, all hide/disable/validate constraints, and other
constraints/invariants forced through actions, are always ensured by default.
This will require to wrap by default:
* New Domain Entity instances / objects (ie, changes on FactoryService).
* Domain Entities returned by queries (ie, changes on RepositoryService).
Users might disable this new default behaviour through configuration, as some
projects can prioritize performance (avoiding wrapping invocations) vs Domain
constraints/invariants enforcement.
> Wrap Domain Entities by default
> -------------------------------
>
> Key: ISIS-1807
> URL: https://issues.apache.org/jira/browse/ISIS-1807
> Project: Isis
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.15.1
> Reporter: Oscar Bou
> Fix For: 2.0.0
>
>
> This way, all hide/disable/validate constraints, and other
> constraints/invariants forced through actions, are always ensured by default.
> This will require to wrap by default:
> * New Domain Entity instances / objects (ie, changes on FactoryService).
> * Domain Entities returned by queries (ie, changes on RepositoryService).
> Users might disable this new default behaviour through configuration, as some
> projects can prioritize performance (avoiding wrapping invocations) vs Domain
> constraints/invariants enforcement.
> ~~~~
> Dan's notes:
> I'd like to refine the concept of wrapping as part of this ticket.
> The idea of wrapping was originally to allow the UI to be simulated within
> integration tests. The intent of this ticket is to formalize the idea of the
> same set of validations being done automatically between programmatic
> interactions from one service/entity to another service/entity.
> So, the more general concept (common to both UI/domain interactions and
> domain-to-domain programmatic interactions) is one of _trust boundaries_. If
> there is no trust from the calling client to the supplying service/entity,
> then that interaction should be wrapped.
> However, the wrapping model as it currently stands is a little bit too
> UI/domain oriented, in that it has both hidden AND disabled as well as
> validate phases. From the perspective of a programmatic domain-to-domain
> interaction there's no meaningful distinction between the hidden and disabled
> constraints: they both mean: "that object isn't in a state to be called". In
> other words its a pre constraint that is not satisfied.
> The other aspect here is that I can imagine that there are actions that we
> would like to allow to be made programmatically (ie through a wrapper) but
> which shouldn't be part of the UI. In other words these actions form part of
> the programmatic API of a module, just not part of its UI.
> Putting all this together, I propose that we slightly change the meaning of
> wrapping (though we'll keep the current implementation too for backwards
> compatibility):
> - an implicitly wrapped object will check the disable and validate phases
> only, ie it will _not_ check the hidden phase. This allows such actions to
> be indicated as hidden (probably using @ActionLayout or .layout.xml or
> security) but still able to be called programmatically. The disable phase =
> pre check.
> We could define the following terminology:
> - "default" wrapping : as described above, checks only disable and validate,
> not hidden
> - "strict" wrapping - for backward compatibility, also checks hidden first
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
