Thanks, Jeroen for your info. What's the status of the DHTMLX viewer?
Regarding the Domain Model, we are looking at various Apache Isis domain examples available on Git repositories. The point is that some of them do not use the JDO object-store and we are trying to migrate part of our model with some complex Entity relationships (one-to-one, one-to-many, many-to-many with attributes - as 2 one-to-many). We used Application Identity, but in order to conform to Apache Isis requirement, we must use "@PersistenceCapable(identityType=IdentityType.DATASTORE)". As we used Application Identity, we are changing our Layer SuperType (http://thierryroussel.free.fr/java/books/martinfowler/www.martinfowler.com/isa/layerSupertype.html) to have a Surrogated key and a different Business Key, because it's needed for working with some Set implementations on Collections when the Entities have not been persisted yet. An interesting link related to "Surrogated Key" vs "Business Key", their implications on "equals()" and "hashTo()", is the following one (talks about JPA, but as DataNucleus documentation, it's the same for JDO): http://stackoverflow.com/questions/5031614/the-jpa-hashcode-equals-dilemma There seems to be a problem with the Wicket viewer version referenced by the Quickstart Prototype related to Entity Collections implemented by Sets, showing only one element on the screen despite the Set has more elements. We have not tested it against current Wicket Viewer version. Also, on our current framework we always made the Tests with an Hibernate repository. But we are trying to use the JUnit Apache Isis support with the "in-memory" repository. That's forcing also to some changes due to "bad practices" (as we always worked with persisted objects Hibernate initialized the Sets. DataNucleus do it also, but working with the "in-memory" implementation seems to not supporting it). Another point is that our current "WaveMaker viewer" automatically implements default operations against @OneToMany elements and now we need to implement each "addToXXX" and "removeFromXXX" methods (we are using the Apache Isis Eclipse templates available here: http://isis.apache.org/getting-started/editor-templates.html). Some teem has been spent reading DataNucleus documentation regarding "managed relationships" for determining the JDO annotations equivalent to JPA, if it's needed to manually update each @OneToMany collection (in JPA terms), the @ManyToOne field, etc. Our Domain Model has a lot of Entities (more than 200) so we are constantly creating Repositories and Factories. An annotation for automatically registering them would be really helpful. Also, our Domain Model publishes (and consumes) Domain Events. We've seen the "Publishing Service" and we are thinking about how to use it within our current architecture. For that we are using the excellent CQRS Java framework by Axon. See: http://www.axonframework.org/. We use it for modeling internal services as @CommandHandlers, so our Entities mainly use only "one Service": a Command Bus, which allows to dispatch Commands synchronously or asynchronously. The @CommandHandler that has been registered for processing the dispatched Command class. @CommandHandler public void handleMonitorServiceFileServerFileCommand( MonitorServiceFileServerFileCommand command) { // Find FTP resource type ResourcePrototype resourcePrototype = vmwExternalAPI .getResourcePrototype("FileServer File"); An @EventHandler is simply a method properly annotated. @Component public class TaskEventHandler { @EventHandler public void handle(final AddTaskEvent event) { We are not fully implementing CQRS, but Axon implementation of the Command and Event bus is excellent. Some kind of similar support inside Apache Isis for Domain Events (and hopefuly Commands) would be great. Current Apache Isis refers to "Auto-publising" a method execution and other options, which is really interesting. Following the "dev" email list I've seen a lot of "commits" to the project. Perhaps a newer version should be released to Maven also for easly evaluating with the Quickstart Prototype with all tested commits and new functionalities implemented (and documented) on "snapshots". It should also include the JUnit viewer (despite we know it will change in the future) for having a complete development framework ready, avoiding dependencies with not "official" packages. A little more complex domain showing one-to-one, one-to-many and many-to-one relationships would be great, in order to avoid searching for JDO documentation (for all JPA techs). After re-modeling the Layer SuperTypes we are going to start evaluating behaviour, etc. I must tell that we are seeing really good things on the framework that can allow us a lot of improvements if leaving our "commodity zone" that it's our custom-made framework :-)) Excuse me for all this long email, and thanks a lot in advance to all group members for your effort towards achieving a great framework !!! El 06/05/2013, a las 22:14, Jeroen van der Wal <[email protected]> escribió: > 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 >>> >>> >>> >>> >> >>
