Thanks for the great job on the 2 release.
To me the most important things that would ease adoption would be: - JPA support (mentioned on Andi’s blog). - Custom UI ease-of-use. Mentioned by you on the REST API and composite UI email contents. I’ve always thought Isis-like UIs would be wonderful also for those working with internally used services (like the ones in distributed systems) that mostly always have a REST API (thinking about Boot services, but also Lagom et al.). The domain metamodel is the key feature of Apache Isis. You transform to it an all grows from it. If the metamodel had a formal specification should be feasible: - For the domain: to automatically generate if from a Boot domain app, or also (slightly different) from a really distributed, Lagom-like app. - For the UI: standardise some kind of support from UI platforms/frameworks like Angular, React, Vue, … - For the API: publish a RESTFul Objects API, generate Swagger artifacts, etc. - … (other ports/adapters in terms of hexagonal architecture). HTH, Oscar > El 31 jul 2018, a las 9:15, Dan Haywood <[email protected]> > escribió: > > 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. Óscar Bou Bou Socio - IT & GRC Management Services Director m: +34 620 267 520 s: <http://www.govertis.com/>www.govertis.com <http://www.govertis.com/> e: [email protected] <mailto:[email protected]> LinkedIn: https://www.linkedin.com/in/oscarbou <https://www.linkedin.com/in/oscarbou> Twitter: @oscarbou <https://twitter.com/oscarbou> Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. A continuación dispone de la información básica sobre protección de datos. Puede consultar la información adicional sobre protección de datos en nuestra página web. • Responsable del Tratamiento: Govertis Advisory Services S.L. • Finalidad: Atender y dar respuesta a su petición o consulta y mantener los contactos y relaciones que se produzcan como consecuencia de la misma. • Base jurídica: El consentimiento inequívoco al ponerse en contacto con nosotros y facilitarnos sus datos para tal fin, pudiendo también ser el interés legítimo o la necesidad para gestionar una relación contractual o medidas pre-contractuales. • Destinatarios: No cedemos sus datos a terceros. Derechos: Acceso, rectificación, supresión, oposición, limitación del tratamiento, portabilidad poniéndose en contacto con nosotros en: [email protected] o en la forma en que se indica en nuestra política de protección de datos
