No, it is the call to isKindOf from the super class
that is
failing, the call to includes works fine. My project class does
implement #= and hash, and uses a UUID string for identity. self
kind is resolving to Class class, since isKindOf is being sent to
anObject, that should resolve the proxy, so perhaps something is
wrong with:
Ok.
descriptionProject
^(MASingleOptionDescription selector: #project label: 'Project'
priority: 10)
reference: MAClassDescription new;
options: (MADynamicObject on: [ TMProject repository
asArray]);
beRequired; beSorted ;
yourself
MAClassDescription seems wrong, looking now, I see why isKindOf is
failing, I'm not filling the dropdown with classes, but I don't see
what's appropriate, without it I get MessageNotUnderstood:
TMProject>>do:. So how do I use other domain objects in a
SingleOptionDescription rather than just a simple list of symbols
or strings?
Yep, that's true. MAClassDescription expects a class. I have never
put a single description into a MASingleOptionDescription yet, so I
didn't encouter this problem yet.
I don't know, but I would try
descriptionProject
^(MASingleOptionDescription selector: #project label: 'Project'
priority: 10)
reference: TMProject description;
options: (MADynamicObject on: [ TMProject repository asArray]);
beRequired; beSorted ;
yourself
Else a possibility might be to create a new description, say a null-
object pattern MAUnknownDescription that wouldn't validate the
referenced object.
Another thing that I am not entirely sure about at the moment is, if
the referenced object should be validated at all? I mean, currently
MASingleOptionDescription does its validation, e.g. is the selected
entry one of the items of the list, and then passes it to the
reference ... probably that should happen somewhere else :-/
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch