I've updated the 'interim' roadmap 2 page [1] to summarize the current vision and thought process. Cheers, Andi!
[1] https://github.com/andi-huber/isis-2-demo/wiki On 2018/07/31 07:15:55, Dan Haywood <[email protected]> wrote: > 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. >
