...
This is typically for bulk entry of data which is then validated all together.
Quoting Dan:
I haven't figured out the coding model yet, but it might be to resurrect the "validate()" supporting method on the domain class to check that all data entered is correct. I see this being used with view models rather than with entities. There would also need to be some sort of "save()" method that would allow the view models to post their state into actual entities.
Authentication: support for OAuth 2.0
OAuth 2.0 support is a thing modern frameworks should not lack. We have no concrete plans yet but talked about integrating with [keycloak](https://www.keycloak.org/).
UI architectural redesign
Decouple current Wicket UI from the framework's core components.
Quoting Dan:
At a rather grander scale, one long-term vision I have is to replace our
Wicket UI with one that works across the REST API. This is the direction
that the .NET NakedObjects framework has taken. In fact because both
frameworks use [Restful Objects](http://www.restfulobjects.org) as their API (albeit slightly different
dialects) then it ought to be possible for us to support their UI. But I'd
also like us to have our "own" Rest UI also, with the explicit goal of
making it easier for developers to customise the UI ... it should be easy to
move from fully generic to fully customised, or any point in between. At
the moment the Wicket UI makes this too hard to do. Having a REST UI based
on Angular.x (and eventually, web components) will hopefully improve this.
Sebastian Slutzky [...] is making steady progress on this. It'll take a while yet before we get to feature
equivalence with the Wicket UI, though.
Allow for multiple backends to feed the UI with data.
Quoting Dan:
Moving to a REST UI also enables another idea, which is that of composite
UIs. At the moment the framework assigns an OID to every domain object, be
that a domain service, an entity or a view model. This is basically the
object type (as in @DomainObject(objectType=... ) or
@DomainService(objectType=...) ) along with an ID (for an entity, it's
datastore Id and for a view model, a seriailsation of its internal state).
With REST this OID is part of the URL, with the rest of the URL in effect
specifying the "backend" that owns the domain object. My idea is that the
UI being rendered is made up of state that could be from multiple backends;
they are all just URLs, after all. What I haven't figured out is how to
define references from one backend app (eg order_mgmt) to another backend
(eg customer). And I also don't know how to do mixins (eg so that
order_mgmt could contribute the "recentOrders" collection to a
representation of a customer). But if we could figure this out, then it
could be possible to use an Isis REST UI on top of multiple backend
microservices - all they would need is a REST API. This also motivates [... as mentioned above] supporting different backend persistence runtimes
such as SpringBoot/Hibernate and Axon/CQRS.