isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Meyer <ke...@kmz.co.za>
Subject Re: Some questions
Date Fri, 22 Nov 2013 10:44:44 GMT
Thank you Dan!

I will pass these on.

Regards,
Kevin

Dan Haywood <dan@haywood-associates.co.uk> wrote:
>On 21 November 2013 19:39, Kevin Meyer - KMZ <kevin@kmz.co.za> 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.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message