The same in our case for many-to-many relationships between Entities / ARs that have attributes. In our case, not "nearly", but always are Entities / ARs undiscovered.
So they can be modeled as a new Entity/AR with 2 many-to-one relationships to its "parents", and with 2 one-to-many relationships form its "parents" to it. I simply mentioned it for completeness. Regarding @PersistenceCapable(identityType=IdentityType.APPLICATION) support, I will double-check but as I remember an Apache Isis exception was raised with a message indicating that only @PersistenceCapable(identityType=IdentityType.DATASTORE and @PersistenceCapable(identityType=IdentityType.UNSPECIFIED were supported. We will also change our tests to use JDO with in-memory database, despite we are discovering some bugs in our Apache Isis Domain due to some subtle differences between them. Perhaps we will wait a bit more ... :-) I will ask "my bosses", but I don't expect much problems on publicising that it uses Apache Isis as a case study. PD: I'm looking forward the option to see "Estatio"'s way-of-doing things :-)) For its completeness, as it will require for sure latest snapshot, I would recommend to include some JUnit viewer tests as examples also. Thanks! El 12/05/2013, a las 15:55, Dan Haywood <[email protected]> escribió: > 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
