Thank you Dan! I will pass these on.
Regards, Kevin Dan Haywood <[email protected]> wrote: >On 21 November 2013 19:39, Kevin Meyer - KMZ <[email protected]> wrote: > >> >> I was aked if the wars can be deployed into non-Tomcat installations. >> >> >Don't see why not, it's a WAR file after all. In dev mode, we run it >under >jetty as well as Tomcat. Haven't tried it under a JBoss server, >though. > > > >> > > and how much of EE >> > > infrastructure can it leverage? (see next questions) >> > > >> > Since Isis is a framework that provides a container for domain >objects, >> the >> > user's code is substantially hidden from JEE. So the question >really is >> to >> > what extent could one expose these services. >> >> I think this question was from the other perspective: Can the >> user-written domain classes access services provided by the EE >> server? (i.e. can the "developer" access more than what is provided >> by Isis). [I don't know what these could be, personally]. >> >> >Yeah, that's how I understood the question, let me have another bash at >answering it. > >So, the short answer is... no, there is no mechanism for user-written >domain classes (specifically, domain entities) to access services >provided >by the EE server... and that's deliberate. The domain entities should >not >depend on technology stuff. > >The longer answer is... while the domain entities should have no >access, >the domain services (or rather, the implementations of domain services) >can >use EE services. The API of the domain service represents that >functionality to the domain entity (into which it is injected) in a >technology-agnostic way. > > > >> > >> > Supporting a different JPA implementaition would be much more >work... >> > Note: we cannot ever support Hibernate because of its license >(LGPL); >> that >> > basically leaves OpenJPA. >> >> To clarify, a user could add Hibernate into their own extension, but >it >> could never be added to the Apache Isis codebase on >> isis.apache.org. >> >> >Yes, one could write a Hibernate object store as a third-party plugin. > > > > > f) What about client-side validation? >> > > >> > What's the client in this context... presumably the >browser/Javascript? >> > >> > It would be possible, if using the Wicket viewer, to write some >custom >> > Javascript, and have it call back into the Restful Objects viewer >to >> > perform validation. Otherwise, we are leveraging the capabilities >of the >> > Wicket framework. That does quite a lot in this space. Isis' >Wicket >> > viewer has a pluggable architecture for its components, so writing >> cleverer >> > widgets is certainly do-able. >> >> On further questioning, the asker of this question was after reducing >> the number of queries to the server - so the idea of AJAX calls back >> to the RO viewer is not ideal. He'd want scripts that do the >validation >> on the client without additional calls back to the server. >> >> I can imagine a system whereby validation scripts get served to the >> client. Can they be introspected from the validateXXX methods? That >> would be interesting! >> >> >In Wicket it is possible to associate arbitrary bits of Javascript with >the >components. It would therefore be possible to develop more >sophisticated >components that use Javascript to enforce some of the semantics of the >domain model. (Indeed, the maxLength of a string is done this way) > >Isis' Wicket viewer is also extensible through its ComponentFactory >API, so >"dropping in" new and improved components would be quite feasible. > > > > >> > > General feedback: The guys asking all seemed to working on or for >> > > Redhat (JBoss) and related. They seemed surprised that Isis >adopted >> > > JDO over JPA, with comments along the lines of "but JDO is dead >> > > already". >> > >> > >> > I doubt that Andy Jefferson would agree. But yes, it is the betamax >to >> > JPA's vhs. Note: it's also more capable, eg supporting NoSQL >stores as >> > well as RDBMS [2] >> >> Interesting! Are you offering to push this analogy to the next level: >> betamax was also the better technology over VHS.. is JDO somehow >> better than JPA? (apart from the extra NoSQL functionality). >> >> >Yes, the analogy was deliberate :-) JDO is better than JPA. > >Actually, if excluding the NoSQL functionality, then to be completely >fair, >I've seen benchmarks that JDO/DN is not the fastest ORM; there are >JPA-only >solutions that have the edge. > >And, the more pressing issue is probably community... DataNucleus is, >it >would appear, pretty much a one-man band. That said, given we can't >use >Hibernate, I think that DN is as a good a choice as either OpenJPA or >EclipseLink (the only other two candidates). > >If we take the NoSQL functionality into account, then - to me at least >- >JDO fits much better to Isis' hexagonal ports-and-adapters >architecture: >JDO takes care of the various adapters for the "persistence" port, >while >Isis takes care of the "presentation" port. A nice symmetry. > > >Cheers >Dan -- Sent from my phone with K-9 Mail. Please excuse my brevity.
