Hi Oscar, thanks for your various emails on the list, and apols for not answering before now. Let me have a go at answering each in turn...
On Thursday, 9 May 2013, GESCONSULTOR - Óscar Bou wrote: > > What's the status of the DHTMLX viewer? > > This is Maurizio's baby, so he should probably answer for definite. My guess is that there's a month or two more of development required on it, though the best way to knock off the rough edges would be to have someone start prototyping on it. If this sounds of interest, I suggest you contact Maurizio offline about this. As I'm sure you are aware, the DHTMLX viewer won't ever be integrated into Isis proper, because of its dependency on the license of DHTMLX toolkit. However, to my mind it seems to be quite inexpensive, so if you found it to your liking, I am sure that wouldn't be a blocker for you. Also, there is some degree of coupling between the DHTMLX viewer and the Google App Engine; mostly because this is the target architecture that Maurizio works most commonly with. It ought to be straight-forward enough to decouple the two, but it isn't a piece of work that's been done. I was speaking offline with Maurizio today, and he'll create a branch on the Isis codebase to start teasing this out. (Irrespective of DHTMLX viewer, it would be good to be able to say that Isis can run on the GAE, but that isn't something available out of the box). > 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). > > It should be possible to implement many-to-many in Isis/JDO, though whenever I've done this I've always later found myself teasing out the association into a full-blown entity. For example, in Estatio (the app that Jeroen and I work on), there is a many-to-many between Lease and (shopping precinct) Unit. Although this is still called "LeaseUnit" in the domain model, we may well rename it to Occupancy, because this is the domain concept that it represents. > We used Application Identity, but in order to conform to Apache Isis > requirement, we must use > "@PersistenceCapable(identityType=IdentityType.DATASTORE)". I'm not sure that's correct; I'm pretty sure I've tested that the JDO objectstore works with application identity as well. My uncertainty is just that Estatio does use datastore identity throughout. You should check this then; it may well just work (at least on trunk/snapshot). > 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. > Please do so, then. We use SortedSet and TreeSet as the impl, and have our domain entities implement Comparable so that they sort correctly. I could quite that this has been fixed in trunk/snapshot; there's been a lot of work done in this space over the last few months. > > 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). > For myself, I'm less and less keen on the in-memory objectstore, precisely because one gets these subtle differences in implementation. Certainly, on Estatio we pretty much use the JDO objectstore all the time, but configured to use an in-memory HSQLDB. It's a bit slower, perhaps, but I prefer the predictability. (Incidentallly, in Naked Objects for .NET, Isis' sort-of sister project outside of Apache, they are considering getting rid of their in-memory object store. Perhaps we might vote on doing the same in the future). > > 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. > > Yes, JDO/DN doesn't really provide support for managed relationships; they are quite clear about that on their web pages. So you need to use the mutual registration pattern (as defined in the Eclipse templates). In fact, this is one area where the JDO objectstore and in-memory objectstore are identical: neither provide support for managed relationships. An alternative thing you can do, if you want, is to use the IsisJdoSupportImpl domain service's refresh() method. You can do a DomainObjectContainer#flush() to force JDO/DN to insert/update to the database, then reload the impacted object(s). This is less boilerplate overall, at the cost of a bit of a loss of performance. > > Our Domain Model has a lot of Entities (more than 200) so we are > constantly creating Repositories and Factories. That's an awful lot of entities. I hope you've organized them into modules, and are using a tool such as Structure101 to make sure you don't have any cyclic dependencies. Otherwise you might end up with a big ball of mud (which would be a shame). That said, I suspect that your use of Axon (that you mention below) might mitigate this/help you to decouple. > An annotation for automatically registering them would be really helpful. > Two things you can do. 1. raise a ticket in JIRA. 2. contribute a patch. If you look at the ServicesInstaller class, you will see that there is an API there. So it ought to be easy enough to implement this. Put a breakpoint on the constructor for ServicesInstallerFromConfiguration and look at the stacktrace so you can see how it is currently instantiated. But, in brief, you can configure your own implementation by registering in isis.properties; the key would be something like: isis.services-installer=com.mycompany.isis.MyServicesInstallerFromAnnotaition > > 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. Sounds a little bit like Guava's event bus? As I alluded to above, I can see that this might well be helpful for decoupling your system. I can't say that I have much experience of using in-process event busses, though; only ever external busses for interacting with other systems. My one concern with an architecture such as this is that you might end up with a lot of boilerplate (all those handlers, and commands, and such like), and that will slow down your ability to uncover new concepts in your ubiquitous language. > 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. > > As you know, Isis uses metamodels, so we try not to reify such things into code unless we really need to. Hence, the PublishingService lets us publish data with a minimum bit of boilerplate. Speaking for myself, I'm rather happy with how the architecture leverages the Restful API in order to allow the subscriber be able to pull additional information on receipt of the event (as opposed to the event have to bundle up lots of information that may or may not be relevant to the subscriber). This can be customized: see the PayloadFactory stuff. > > > 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". You are right, a lot of work has been done over the last few months. My intention is to push out a new release (of Isis code, wicket, JDO, RO and the archetype) later this month. It takes about one full day to do this (1/2 day before the vote, 1/2 day after), so you can appreciate it isn't something I feel inclined to do too often. > 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. > Hmm. Maybe. I see from your other recent mails on the list that there are still some issues with it. So I'm not sure I'm going to commit to that just yet. > > 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). > > As Jeroen said, we expect that Estatio will be released as open source. It isn't as large as your domain (about 50 entities), but is sufficiently rich to provide a good resource. > > 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 :-)) > > That's great to hear. > > 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 !!! > > Thanks again. Obviously Isis is still a small community and we're still picking up momentum, but it's really encouraging to see you and others doing real work with the framework. Perhaps later on in your project we might be able to create some publicisity (a case study, or similar); even if your code is closed-source, there's still a lot of value for other prospective users in knowing that big, substantive systems can be built with the framework. Cheers Dan
