Just one more thing for the roadmap. We also mentioned on IsisCon (but also I can remember Dan mentioned something similar on the mailing list as his intention for version 2) that domain objects (domain entity instances) could be "wrapped by default", acting as a "container" of the business logic and ensuring it was preserved by default when invoked from other domain objects.
That would imply that, for example, a call to: domainObject.someAction(x, y, z); Would always validate the parameters, choices, etc. and all other associated business logic. And that a call to: domainObject.setXXX(x); would always preserve the business rules implemented on the modifyXXX, validateXXX, clearXXX methods, for example. It has many advantages, for example for testing. It really avoids "programming errors" originated by invoking in the domain actions or setters without taking into account validations or business logic inside the modifyXXX methods, for example. In our case, nearly all our actions are setter invocations are made through: this.wrap(domainObject).setXXX, this.wrap(domainObject).actionXXX or, if they're hidden or disabled, this.wrapSkipRules(domainObject).setXXX, this.wrapSkipRules(domainObject).actionXXX That strategy of "always wrapping" helps REALLY A LOT while debugging. Sincerelly, this was one of our expectations when we arrived to Isis. And we don't know of any other platform that always tries to preserve all business logic. Thay would imply that Isis would act as a "true" hexagonal architecture when the UI just is another port-adapter, with exactly the same behavior as any other invokation from any other port-adapter, and what it's most exclusive of any platform, doing the same with intra-domain invocations. Any thoughts? Thanks, Oscar El 10/06/2014, a las 21:28, Kevin Meyer - KMZ <[email protected]> escribió: > Quick immediate reply: > >> ~~~~~ >> Some of the ideas that follow build upon each other, some are independent >> of each other. I won't attempt to outline an exact timetable, but you can >> see that some of this work could be performed in parallel. For example, >> improved Shiro support (4) could be done at the same time as simplifying >> the framework (1). >> >> 1. Simplifying the framework >> >> * Isis will run only as a server-side webapp. This implies that the DnD >> viewer will be retired. This will also enable Isis' bootstrapping to be >> simplified and rationalized. > > By the way: A DnD viewer can be later re-implemented, if so desired. > >> * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus >> ObjectStore implementation then made part of core. The other ObjectStore >> implementations will be retired. This step in particular should enable >> considerable simplification > > As described, this is a temporary state, with a future plan to later > abstract out a new Objectstore API to support other objectstore > frameworks. See below. > >> * Isis will adopt the Shiro authentication classes rather than define its >> own. This will also allow authentication to be moved into the core. > > I have no comment :) > >> 3. Alternative Persistence providers >> >> Having in (1) made Isis dependent on an ORM (for lazy loading and dirty >> object tracking) and on DataNucleus in particular, the next step in the >> roadmap is to re-introduce pluggability so that developers can use other >> ORM implementations; particularly for the JPA API. Being an Apache product >> means that we cannot dependent on certain licenses, but we certainly >> provide alternative implemenation based on either Apache OpenJPA, or on >> EclipseLink (the old TopLink product). >> >> We might also look to provide an implementation for the market leader, >> namely Hibernate. However, because Hibernate is LGPL, this implementation >> would need to live outside of Apache Isis' formal codebase, eg in the >> apache-extras.org site or perhaps just likely on github. >> >> >> 4. Improved support for Shiro >> >> We've noticed a number of users wanting to use our Shiro integration, with >> Shiro configured to use a JDBC Realm. It ought to be relatively simple to >> build Isis entities that map onto the Shiro concepts (users, roles, >> permissions). In this way Isis could provide a self-contained security >> subsystem for managing users "out-of-the-box". >> >> We anticipate delivering this as an optional module that could be included >> as necessary. >> >> An extension of this is to deliver a standalone application built with Isis >> for administrating the users/roles/permissions for any application >> configured to use the Shiro JDBC realm (not just an Isis application). > > The discussions I've had and heard regarding other application > development suites lead me to believe that this would be an extremely > useful add-on! I'd almost like to request that this be the first thing > worked on, before any of the fundamental changes listed above. > > But that's just my wish. > > (I'd like to demo that Isis can also support RBAC, out-of-the-box). > >> >> >> 5. Other Reusable modules >> >> In the applib there are a number of services; some depend on parts of the >> Isis runtime; some do not. Some have their own entities, some do not: >> >> - CommandContext (applib implementation) >> - BackgroundService (core-runtime implementation) >> - BackgroundCommandService (JDO implementation, with entities) >> - AuditingService3 (JDO implementation, with entities) >> >> - PublishingService (JDO implementation, with entities) >> >> - ApplicationSettingsServiceRW (JDO implementation, with entities) >> - UserSettingsServiceRW (JDO implementation, with entities) >> >> - ClockService (applib implementation) >> - QueryResultsCache (applib implementation) >> - Scratchpad (applib implementation) >> >> - MementoService (core-runtime implementation) >> - BookmarkService (core-metamodel implementation) >> - XmlSnapshotService (core-runtime) >> - EventBus (core-runtime implementation) >> - ClassDiscoveryService (applib implementation, >> +optional org.reflections dependency) >> - WrapperFactory (core-wrapper) >> - DeveloperUtilitiesService (core-metamodel implementation) >> >> Extended the idea of the Shiro security module (4, above), we think it >> makes sense to modularize these other services; probably in five or so >> modules in line with the grouping shown above. That way developers could >> bring in a dependency to the services that they require, and ignore the >> others. >> >> >> 6. Profile Store >> >> The profile store is a component of the framework that is not supported by >> either the Wicket or Restful Objects viewers, but whose functionality is >> broadly superceded by the UserSettingsService. > > When the UI becomes user-configurable (re-arranged, pallete change, > etc) this should be demo'd. > > Where are user preferences (e.g. UI language, timezone, etc) currently > stored? Do we have demo code? > >> In line with simplification (1) we'll retire this component. >> >> >> 7. Restful APIs >> >> The Restful Objects viewer implements the Restful Objects spec [2] and >> provides a full REST Hypermedia API to the Isis metamodel and runtime. >> >> >> 8. Wicket Viewer >> >> We intend to continue developing the Wicket viewer. One part of its >> development will be to re-implement its components to use Wicket-Bootstrap >> [5]; this will make it easier for its look-n-feel to be customised. >> >> We will also probably rename it. "Wicket" is merely the implementation >> technology; its name should represent what it's role is. Possible names >> are the "default viewer", or the "standard viewer" (preferences? >> alternatives?) > > Thinking about it further, I would probably prefer to keep "Wicket" in the > name somewhere, as the viewer *is* dependent on Wicket, and those > who wish to extend (I want to add some additional view components), > need to know Wicket. But I guess that other names may also be more > appropriate.. > > >> >> 11. Better documentation, better website. >> >> Probably every open source project would wish for better documentation and >> examples; we are no different, and we intend to keep improving the docs and >> providing examples of usage. >> >> On the homepage one idea is to make Isis' value proposition more obvious. >> We intend to distinguish our audience, though; what a business person >> wants to know about is different from what a techie wants. So we will >> provide different material for each to consume. >> >> For a bit of interest/originality, Maurizio has offered to develop some >> goanimate [6] cartoon videos; he has used these with some success in his >> own software development company. Right now I am working on some scripts >> to be developed; one 2-minute business-focused one, and a number (3 or 4) >> of 2-minute technicaly focussed ones. >> >> Also, I am aware that much of the materials were written by me and all of >> the screencasts have my voice on them. But there should be other voices >> present on the website; Isis isn't a one-man show and visitors to the >> website shouldn't get that impression. > > I agree and will try and step in more, here. > >> 13. Conferences, articles, podcasts >> >> Jeroen and I are intending to submitting a couple of sessions to ApacheCon >> EU in Hungary [7], and in general try to do a few more sessions. >> >> I have also promised an 500-word blog post for Zeroturnaround to advertise >> our JRebel integration. >> >> And, it'd also be good to do some podcasts sessions; I am sure they are >> several looking for new people to talk with. > > I'll be in touch later for ideas for ApacheCon EU and other opportunities. > > Don't forget about opportunities to show off Isis in "rapid app" dev > competitions. Jeroen, you mentioned one in the Netherlands?? > Perhaps Isis can become the disruptive change from a surprising > direction! > >> >> ~~~ >> OK, I think that's it. >> >> As I say, for those who were in Milan, please amplify/expand/correct. For >> everyone else, your comments/thoughts are welcome. >> >> Cheers >> Dan >> Apache Isis PMC Chair > > > :) > > Unless otherwise indicated, I agree with the proposals.. ;) > > Regards, > Kevin > Óscar Bou Bou Responsable de Producto Auditor Jefe de Certificación ISO 27001 en BSI CISA, CRISC, APMG ISO 20000, ITIL-F 902 900 231 / 620 267 520 http://www.twitter.com/oscarbou http://es.linkedin.com/in/oscarbou http://www.GesConsultor.com 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. Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
