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 {
...
@Ignore
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
problems?).
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 isis.properties. 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.
Regards,
Kevin
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!
