Hi Oscar, First of all welcome to this mailinglist. From the code you showed there's quite a good match between your framework and Isis. Together with Dan I'm developing a business application for managing and invoicing property leases. In the process of building the application Isis matured a lot and I think now is the time to have more people joining in developing critical business applications.
In regard to your viewer solution I that Maurizio Tavernina is working on a DHTMLX viewer with an integrated DSL to develop custom(ised) user interfaces. This might be an interesting project for you to watch [1] and an a possible alternative to WaveMaker. Today I discussed open sourcing our codebase (which is still under construction) with the client and he agreed to do that. The only decision to be made is whether it's under Apache License 2.0 or GPLv3 but I expect that to be finalised soon. I will update the mailinglist when we have the code online. Kind regards, Jeroen van der Wal [1] http://isis.markmail.org/thread/scdyj62aujav7cfi On Fri, May 3, 2013 at 10:06 AM, GESCONSULTOR - Óscar Bou < [email protected]> wrote: > Hi, Adam and Dan. > > Thanks a lot for your responses. > > Adam, I'll look in detail on the project to pointed me and Dan, I (and > many others :-) will wait for the "Estatio" code with really, really > interest :-)) > > Dan, regarding JPA I've seen on previous posts that LGPL licensing was the > reason to choose JDO. These 2-3 days I've seen that it's a really powerful > API also, and with more flexible solutions than JPA for @MappedSuperclass, > @Embeddable, for example. Also is clearer for specifying indexes, etc. But > the matter is that the majority is using JPA, so I think that a JPA > implementation compatible with Apache, such as OpenJPA will be needed on > the mid-term. > > ISIS framework implementation is quite more powerful than our framework. > That's the reason for change :-)) What I didn't noticed was the > Localization-related API. Thanks to point me towards it. > > Despite the JUnit viewer is not "finished", we will try to use it with the > maven archetype generated project. It would be really interesting to have > such a complete Domain testing framework fully integrated on ISIS and > available on the Maven Archetype, the first point of contact of all > evaluators. > > Regarding the Wavemaker's viewer, currently is propietary technology. If > the proof-of-concept goes well (I'm quite confident :-) we will need to > migrate it from our framework to Isis. > I'll try to convince Management to donate it to ISIS ;-) I'm not sure if > we will be able to commit to a full viewer's implementation for our own, > but at least the Wavemaker "specific" screen generations, etc. will be > done. Let's see how much effort and "ISIS specific knowledge" is needed for > a full viewer implementation or if any volunteer is needed. Wavemaker is a > really good complement to ISIS, as it's a visual RAD-like tool with User > Interface drag-and-drop design, completely developed on Java and DOJO. > > Regarding the "Ids" and Lazy Loading debate, I vote for "Id" referencing > for Aggregates from different Bounded Contexts (in order to limit the > dependencies between them, "types" importing, ...) but for references > between Aggregates on the same Bounded Context when using an ORM with Lazy > Loading support, we prefer referencing the type (as it's been done on ORM > since the beginning). > > The framework is becoming really powerful. Let's see how easy it's to > evaluate it :-) > > Thanks a lot to all the team for the really good work you are doing, > > Oscar > > > > > > > > > El 03/05/2013, a las 00:21, Dan Haywood <[email protected]> > escribió: > > > 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 > > > > > > > > > >
