Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 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.

...

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 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.