Hi!
As Dan mentioned me as a "third party" ;-) here's a link to the demo I did, the
'Transport Planning Manger'
http://tpmdemo.eidemsnesset.cloudbees.net/
The background is a bit like the example for "Implementing Design Driven
Development", but I didn't know about it when I started.
I had little time to come up with something useful but ISIS has made it
possible.
The demo only uses the in-memory object store. Unfortunately the project has
come to an end for now.
The source code can be found here
g...@git.assembla.com:transportplanner.git
Cheers
Christian
________________________________________
From: Dan Haywood [d...@haywood-associates.co.uk]
Sent: Friday, May 03, 2013 12:21 AM
To: users; o....@gesconsultor.com
Subject: Re: Hi to all. Project introduction and some doubts
Hi Oscar,
Thanks for your interest in Isis, and for your very interesting email. I'm
replying to both you and to the mailing list; you might want to subscribe
to users@isis.a.o and/or dev@isis.a.o.
I'll reply in line so that I don't miss anything....
On 2 May 2013 17:36, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
> We are using JPA with an Hibernate implementation ...
As you probably know, the Hibernate license is incompatible with ASF; this
is one of the reasons why we use JDO/DN.
>
> Here are some examples of Domain classes:
>
> [snip]
> As you can imagine through the previous code, our framework vision it's
> quite similar to this one.
Yes, pretty similar. I didn't notice any actions though? Where do you put
your "know-how-to" responsibilities; do you subscribe to Isis'
"behaviourally complete" objects?
> An important difference is support for multiple languages on some critical
> annotations.
> As you can see previously, de @XMSField is like the @Named one from ISIS,
> but supporting localization.
>
In fact, Isis' architecture does support localization. The @Named
annotation is interpreted by the various FacetFactory's [1] that make up
Isis' programming model and are part of its metamodel builder. In the case
of @Named, it is NamedAnnotationOnMemberFacetFactory [2], which installs an
implementation of NamedFacet on the property.
In addition, Isis has an API called FacetDecorator. One implementation is
I18NFacetDecorator [3]. From this, you'll see that we can provide
localized names, help text and descriptions.
(As an aside: this FacetDecorator API actually predates the FacetFactorys,
and we do intend (at least, I would like) to just have the FacetFactory
API, and have an implementation of FacetFactory that can do the
localization. Not a big deal).
Just a note on your @XMSField annotation; it seems a bit odd to me to have
the translations in the text rather than in a resource bundle. But
presumably it fits your development process well enough, otherwise you
wouldn't have done it that way. One thing you might want to consider: you
could if you wanted write your own implementation of NamedFacetFactory that
understands your @XMSField annotation, if you wanted. In other words,
teach Isis about your programming model, rather than the other way around.
(You would still need to translate the JPA stuff into JDO, though).
> The @Description should also support localization. In our case, we are
> directly generating the help texts from the source files using a custom
> Doclet.
>
> You mean @DescribedAs? Also supported by the I18NFacetDecorator.
> I'm following the project and email list for the last months, because we
> have been spending a lot of resources developing our framework but are
> thinking about evaluating for future Bounded Contexts a mixed approach,
> using Apache Isis for the Domain Model development, testing and REST API,
> and our technology for the User Interface and other infrastructure areas.
>
>
That's very interesting to hear. Which makes me ask in turn: is your UI
stuff proprietary? or could it be open sourced in turn as another viewer
for Isis?
> Migration from JPA to JDO seems quite fast and easy (but directly
> supporting it would be perfect, despite what I've seen from JDO seems
> really, really good). As our programming model was also quite similar, it
> seems also relatively easy to "migrate" our custom annotations to your
> equivalent ones.
>
> Prior to starting the formal evaluation of the migration process, we want
> to make a prototype migrating one Bounded Context. For that, we have used
> the Maven archetype for creating the prototype. Current Archetype is really
> good exposing really fast the Domain through a web and a REST interface.
> But we find Testing (Junit mainly but also BDD), "the programmer's
> interface", is missing and would be perfect to have some test examples with
> the JUnit viewer and the BDD viewer.
>
>
With respect to the JUnit viewer, at the moment it focuses on testing the
UI/domain interaction, and just using an in-memory objectstore.
Separately, there is IsisSystemForTest [4], which can be used to bootstrap
an Isis runtime for domain/DB integration (via the JDO objectstore)
What I want to do is to combine these frameworks into a single JUnit
framework, which allows domain/DB integration and optionally allows the
full-stack UI/domain/DB integration too. This is the main reason I
haven't released the JUnit viewer yet since us becoming a TLP.
With respect to the BDD viewer, I think this also needs to work the same
way; and it probably should be made part of the same single framework. So,
then it's one integration testing stack for domain/DB testing, optionally
testing the UI interaction through the existing JUnit viewer stuff or
through the BDD viewer stuff.
> It would also be really good to have a more complex model on the
> Archetype, showing the proper annotations and use of Entities,
> ValueObjects, Aggregates, Repositories, Factories, ...
As you probably know if you've been following the mailing lists, Jeroen and
I are both working part-time on a substantial app for his company, building
an estate management application ("Estatio"). Think of it as the
calculation engine for rents for tenants in shopping centres and the like,
and then integrates with a separate general ledger system using the new
PublishingService that I developed a month or two back.
The intention is for this app to be open sourced when done (later this
year, we expect). Some parts of it (to do with proprietary calculation
algorithms) will remain closed source, but we think we can provide suitable
plugin points such that the vast majority of the app is open sourced. The
app also has a bunch of integration tests written using the
IntegSystemForTest.
By all means contact Jeroen or me off-list regarding this.
> It would be ideal to have a model equivalent to the SCRUM one exposed on
> the "Implementing Design Driven Development", showing how to implement it
> on Apache Isis.
Yes, that is a nice little domain that one could work up. Don't have the
bandwidth myself, but if you are doing an evaluation of Isis, perhaps you
might consider building it as a proof-of-concept and put it on github.
Also, you might want to ping Christian Steinbach, who was very active a
month or two back on the mailing lists while writing a demonstrator app
using Isis. He would provide some useful "third-party" feedback for you, I
would have thought.
> It would also help on identifying "gaps" on the framework or, if different
> design decisions have been taken, to justify it by comments (for example,
> the one to not referencing Aggregates by id due to automatic lazy loading
> on DataNucleus, that was discussed some days ago).
>
An unsatisfactory exchange... I've never had an answer I could understand
as to why one would wish to do all that tedious mucking about with Ids if
one has the power of an ORM to call upon. And all that extra boilerplate
ultimately impedes being able to develop the ubiquitous language.
>
> Another design recommendation would be the creation of an annotation,
> method example, etc. for automatically registering a new service. We are
> now editing the wicket viewer "isis.properties" file, but we waited for an
> automatic "convention over configuration" way of doing it.
>
Yes, I have this on my todo list... to automatically discover services, eg
using the META-INF/services mechanism (or perhaps CDI).
There is, in fact, a not-at-all-documented API to do this. If you create
an implementation of ServicesInstaller [5], then you can specify to use it
by adding a setting in isis.properties:
isis.services-installer=com.foo.bar.MyServicesInstaller
Haven't tried this for a good while, but it ought to work...
You could use some code similar to the RegisterEntities domain service [6]
that we wrote to bootstrap JDO more reliably.
>
> Is there an example with a more complex Domain, testing, etc. anywhere
> that we can further analyze?
>
>
Estatio would be the best example. When it's done, we do intend to use it
as a substantive case study. "When it's done" being the operative words in
that sentence.
Hope that was helpful,
Cheers
Dan
[1]
https://github.com/apache/isis/blob/master/core/metamodel/src/main/java/org/apache/isis/progmodels/dflt/ProgrammingModelFacetsJava5.java
[2]
https://github.com/apache/isis/tree/master/core/metamodel/src/main/java/org/apache/isis/core/progmodel/facets/members/named/annotation
[3]
https://github.com/apache/isis/blob/master/core/metamodel/src/main/java/org/apache/isis/core/progmodel/facetdecorators/i18n/I18nFacetDecorator.java
[4]
https://github.com/apache/isis/tree/master/core/integtestsupport/src/main/java/org/apache/isis/core/integtestsupport
[5]
https://github.com/apache/isis/tree/master/core/runtime/src/main/java/org/apache/isis/core/runtime/services
[6]
https://github.com/apache/isis/tree/master/component/objectstore/jdo/jdo-datanucleus/src/main/java/org/apache/isis/objectstore/jdo/service
> Thanks a lot in advance,
>
> Oscar
>
>
>
>
