isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <>
Subject Re: Some questions
Date Fri, 22 Nov 2013 08:54:30 GMT
On 21 November 2013 19:39, Kevin Meyer - KMZ <> 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
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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message