incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Meyer - KMZ" <>
Subject Re: Problem with non-support of Collections as arguments.
Date Wed, 13 Jul 2011 16:41:36 GMT
Hi Iain,

See below.

> The application domain is a catalogue of Japanese animation, the
> creators and writers/directors of such, as well as characters and
> the IPs (Intellectual Properties) they belong to. An example of a
> domain entity here would be Series (a kind of Adaptation), with a
> value for amount of episodes, along with operations for adding
> characters to the series, adding alternative (different language)
> names for the series, and so on. 

Ok - right. 

> > And where does Emfatic fit in?  
> I'm using a text editor to define my domain classes, and then feed
> that into a code generator to output domain classes which I can
> ideally slot right into an Isis project. An example class in EMF
> would be the following: 
> class Adaptation {
> 	val Title[+] titles;
> 	ref IP[1] adaptationOf;
> 	op Title addToTitles(Title title);
> 	op String title();
> }

Right. I would write my own code generator, see bottom :)
> > And, to go one step more philosophical, what are actually trying to 
> > achieve with Isis?
> The current objective I would say is to examine the possibility and
> practicality of integrating a model-driven software development
> approach with the Isis framework in order to enable domain-driven
> design using model-generated code that can then use the naked
> objects framework and its benefits with Isis. 

Right - I'm with you now.

To paraphrase from previous messages:

1) AnidirectoryPackage contains methods (with java.util.Collection 
parameters) that are being picked up by Isis as actions (which does 
not support Collections as parameters to actions). But 
AnidirectoryPackage is not a potential domain class (something you 
expect to interact with via Isis UI).

2) Adaptation contains references to AnidirectoryPackage. Adaptation 
is a potential domain class.

I've experimented a little on my own, and confirmed that if I setup 
some classes as follows:
Class with Illegal List parameters in methods:

public class CollectionClass {
    // {{ WithCollections
    public void doSomething(List<String> list) {

    // }}

Domain Class:
public class SimpleClass extends AbstractDomainObject {
    public void doodleCollectionClass(CollectionClass collectionClass) {


The @Ignore method lets Isis introspect and support "SimpleClass", 
with method "doodleCollectionClass" ignored (and not visible).

In your case, you're saying that the issue comes from 
AnidirectoryPackage (although, none of the methods you provided: 
eInverseAdd or eInverseRemove, look like they should cause any 

This would require you to @Ignore any method in your domain classes 
that have a AnidirectoryPackage (or derived class) as a parameter.
Likewise, ensure that AnidirectoryPackage, etc, are not listed as 
services in If you need this class, wrap it (see below).

If you have issues with AnidirectoryFactory, and assuming this is a 
factory the same way that an Isis Service can be a factory - i.e. to 
create your EMF classes, can't you wrap this in your own Factory that 
contains (by composition) the AnidirectoryFactory ?

The point you're trying to make means that you can't really consider 
using another code-generation technique.. At least, I assume you're 
decided upon Emfatic, and are not open to finding another or writing 
your own Java-code generator using the exact same syntax of your 
model language (e.g. val Title[+] titles)?

My gut feeling is that many of the methods introduced by Emfatic 
reproduce the same support provided by the Isis applib/metamodel.


PS: as a little thought experiment, I tried mapping your model 
language syntax onto Isis Eclipse templates:
val X[+]  == iscl [create a collection],
ref X[1] == isp [create a property],
op X addToY == iscmod [modify collection],
etc. Of course this would be a (small?) project all in itself!

View raw message