incubator-isis-dev mailing list archives

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

On 13 Jul 2011, at 17:41, Kevin Meyer - KMZ wrote:
> Right. I would write my own code generator, see bottom :)
> 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.

Right on both counts :)

> 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 If you need this class, wrap it (see below).

I've given this a shot - annotating methods that depend on AniDirectoryPackage. Unfortunately,
the mere presence of the latter class causes the exception to be thrown. I've tried stripping
out dependencies to see if there's a particular one causing it, but no luck. 

> 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 AnidirectoryFactory class causes no issues, and even if it did, omitting it is a simple
case of not copying it into the Isis project.

As for wrapping AnidirectoryPackage, I'm trying to do so by having as an inner class. Unfortunately,
static methods and variables (along with an interface that depends on one of its variables)
are making this tricky (as these are only allowed in top-level classes). I'll keep hammering
away at it, unless you have a better suggestion?

> 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

I'll have to bring this up with my supervisor the next time we meet.

Thank you for your continued help,

- Iain
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message