Thanks a lot, Christian. I've successfully downloaded your project from "git://git.assembla.com/transportplanner.git".
Seems there are some interesting things regarding Services implementation and more. It's really helpful to have different projects to evaluate and compare. Thanks, Oscar El 03/05/2013, a las 15:45, Christian Steinebach <[email protected]> escribió: > 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 > [email protected]:transportplanner.git > > Cheers > Christian > > > > ________________________________________ > From: Dan Haywood [[email protected]] > Sent: Friday, May 03, 2013 12:21 AM > To: users; [email protected] > 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 [email protected] and/or [email protected]. > > I'll reply in line so that I don't miss anything.... > > > On 2 May 2013 17:36, GESCONSULTOR - Óscar Bou <[email protected]>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 >> >> >> >>
