Hi folks, Andi and I have been discussing off-list some possible ideas for future improvements to the framework, and so I want to bring them onto this list for wider discussion.
As a starting point, Andi did a great job of summarising our off-line conversations on this wiki [1], which is associated with the demo he's built for showcasing Isis 2.0 features. (Incidentally, we're also building this app as a docker image, which you can pull down and run from [2]). Of course, we have lots and lots of tickets still on our kanban board [3], which aren't going away, but the wiki highlights some of the stuff we perhaps "want" to do rather than maybe "ought to" do. It's also picking up some more strategic ideas. Let me list a few other ideas I had; I'll add to the Andi's wiki when I get the chance/remember to (!) To start with, I'd like to do some profiling to speed up the bootstrapping... in particular the time it takes to build the metamodel. I have some ideas on how to tackle this. Since we want this for our app, Estatio, I might also start this in the 1.16.x codebase and then forward port it into Isis 2.x. I also am thinking that it ought to be useful to be able to serialize the metamodel into some sort of flat file, eg XML. One reason for doing this is as a safety net - to allow refactorings of the metamodel building and check that the output is still the same. I also have an intuition that a serialized metamodel would also be useful for tooling/static analysis. A small UI enhancement is to allow actions to be invoked for rows on a table. I envisage an additional column which provides "common" actions as a drop-down that can be invoked against the row instance without having to navigate into the object first. A simple modal dialog should suffice, I think. A slightly larger idea, also with the idea of saving the user from having to navigate away, is to somehow let the user "peek" at the main details of a domain object object. This could be within a fieldset, or it could be in a row of a table. Perhaps this is enabled by the presence of supplementary xxx.layout.xml, eg Customer.row.xml or Customer.peek.xml which identify the properties to be rendered. Another UI enhancement is to use tabs for collections. Again, in Estatio, we have an Order/OrderItem structure, where typically there's only one OrderItem per Order, but very rarely more than 5, say. So we think that a tab per item would be a useful way of using the screen real estate. Another feature (which again I think we're going to need for , Estatio) is the ability to enter grids of data. This is typically for bulk entry of data which is then validated all together. 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. At a rather grander scale, one long-term vision I have is to replace our Wicket UI with one that's works across the REST API. This is the direction that the .NET NakedObjects framework has taken. In fact because both frameworks use Restful Objects [6] 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 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 (who some of you I know have met) 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 we 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 the stuff on the wiki about supporting different backend persistence runtimes such as SpringBoot/Hibernate and Axon/CQRS. Finally, going back to the more mundane (but important), one thing that I want Isis 2.0 to support is JDK9-style modules, with Isis being loaded from the module path.... though still to run on JDK8+ One thing that the 2.0.0-M1 introduced is a byte buddy implementation of WrapperFactory, to replace our Javassist and cglib implementations. We've also started to remove use of guava in order to use JDK8+ streams. ISIS-1277 [4] is to track work for moving up to JDK11. As I say, I'll try to write some of this up in Andi's wiki (or Andi: you are welcome to copy-n-paste if you wish). Thanks for reading! Cheers Dan [1] https://github.com/andi-huber/isis-2-demo/wiki [2] https://hub.docker.com/r/apacheisis/isis-2-demo/ [3] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=87 [4] https://issues.apache.org/jira/browse/ISIS-1277 [5] https://github.com/nakedObjectsGroup/NakedObjectsFramework [6] http://www.restfulobjects.org -- DISCLAIMER: This e-mail is from Haywood Associates Ltd (Registered Number 3525455) and it and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any unauthorised use or dissemination of this communication is strictly prohibited. Any information provided to Haywood Associates Ltd shall be retained and used in accordance with our Privacy Statement at http://www.haywood-associates.co.uk/privacy. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication.
