17 Jan
2008
17 Jan
'08
8:47 a.m.
Hi,
if an Object holds a collection of other Objects (like a group of Persons), and
these (Persons) should not be created/edited but a list to choose from should be
presented - would a MAMultipleOptionDescription be appropriate? If so, how can
the options presented be made dynamic. - I found, that they are getting cached
in the Default DescriptionBuilder.
Or are there options to pass to a MAToManyRelationDescription, so that it does
not show editors, but choices instead?
Thanks, Christoph
17 Jan
17 Jan
9:55 a.m.
if an Object holds a collection of other Objects (like
a group of
Persons), and
these (Persons) should not be created/edited but a list to choose
from should be
presented - would a MAMultipleOptionDescription be appropriate? If
so, how can
the options presented be made dynamic.
There are several ways to make properties of descriptions dynamic.
1. Override #description on the instance-side and build your
descriptions programmatically. Don't forget to copy the descriptions,
in case you call super to get modify the default behavior.
2. Pass the property a block that you send #asDynamicObject. See the
senders of this message for examples. This approach is simple and
works in most cases, there are some possible drawbacks however: (1)
the implementation uses a proxy object that might not get properly
resolved in all cases, (2) the proxy object references a block context
that might not be serializeable with your preferred persistency
mechanism, (3) proxies are hard to debug, and (4) from within the
block you don't have access to the described object.
PS: I started a Magritte FAQ at http://www.lukas-renggli.ch/smalltalk/magritte/faq
.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
19 Jan
19 Jan
10:47 p.m.
Lukas Renggli schrieb:
Hi,
thanks a lot for the suggestions! I tried some things and would like to share my
experiences here:
[1.] was obvious (after having worked through your exercises at least) but not
very elegant.
I started experimenting with asDynamicObject but in case of
MASingleOptionDescription >> optionsAndLabels: it was not of any use, as the
Collection passed in gets copied, and so the proxy object is lost.
Now simply trying to use MASingleOptionDescription >> options: (providing the
label through model >> printString) raised other questions:
The defaultReference used by the MAOptionDescriptions is a MAStringDescription
which tells a visitor to use the visitStringDescription: method. In case of the
MAStringWriter this is implemented as:
MaStringWriter >> visitStringDescription: aDescription
self stream nextPutAll: self object
This obviously fails in cases where object is no String. visitElementDescription
adds asString which works :
MaStringWriter >> visitElementDescription: aDescription
self stream nextPutAll: self object asString
MAElementDescription however isAbstract and therefore can't be used for
MASingleOptionDescription >> reference:
I could work around by creating a new description class and corresponding
MAStringWriter subclass then setting the reference attribute to it:
MASingleOptionDescription new
label: 'Label' ;
reference: MAMyStringDescription new;
selectorAccessor: #myAccessor;
options: [WAPersonManager persons]asDynamicObject;
Then MAPersonModel >> printString returns lastName or something useful.
That way everything works fine and the choices are dynamic (hitting reload in
the browser updates the list)
To make this work out of the box, maybe 'asString' should be added to
MaStringWriter >> visitStringDescription:
- Or a better defaultReference could be choosen for MAOptionDescription subclasses.
I hope this made sense... Cheers, Christoph
if an Object
holds a collection of other Objects (like a group of
Persons), and
these (Persons) should not be created/edited but a list to choose
from should be
presented - would a MAMultipleOptionDescription be appropriate? If
so, how can
the options presented be made dynamic.
There are several ways to make properties of descriptions dynamic.
1. Override #description on the instance-side and build your
descriptions programmatically. Don't forget to copy the descriptions,
in case you call super to get modify the default behavior.
2. Pass the property a block that you send #asDynamicObject. See the
senders of this message for examples. This approach is simple and works
in most cases, there are some possible drawbacks however: (1) the
implementation uses a proxy object that might not get properly resolved
in all cases, (2) the proxy object references a block context that
might not be serializeable with your preferred persistency mechanism,
(3) proxies are hard to debug, and (4) from within the block you don't
have access to the described object.
21 Jan
21 Jan
12:29 p.m.
Ch Lamprecht wrote:
Lukas Renggli schrieb:
I could work around by creating a new description class and corresponding
MAStringWriter subclass then setting the reference attribute to it:
MASingleOptionDescription new
label: 'Label' ;
reference: MAMyStringDescription new;
selectorAccessor: #myAccessor;
options: [WAPersonManager persons]asDynamicObject;
Then MAPersonModel >> printString returns lastName or something useful.
That way everything works fine and the choices are dynamic (hitting reload in
the browser updates the list)
if an
Object holds a collection of other Objects (like a group of
Persons), and
these (Persons) should not be created/edited but a list to choose
from should be
presented - would a MAMultipleOptionDescription be appropriate? If
so, how can
the options presented be made dynamic.
There are several ways to make properties of descriptions dynamic.
1. Override #description on the instance-side and build your
descriptions programmatically. Don't forget to copy the descriptions,
in case you call super to get modify the default behavior.
2. Pass the property a block that you send #asDynamicObject. See the
senders of this message for examples. This approach is simple and works
in most cases, there are some possible drawbacks however: (1) the
implementation uses a proxy object that might not get properly resolved
in all cases, (2) the proxy object references a block context that
might not be serializeable with your preferred persistency mechanism,
(3) proxies are hard to debug, and (4) from within the block you don't
have access to the described object.
I hope this made sense... Cheers, Christoph
Hmm, maybe it did not...
Is #reference: meant for 'public' use with MA*OptionDescription ?
Thank you, Christoph
24 Jan
24 Jan
12:59 p.m.
I could work around by creating a new description
class and
corresponding
MAStringWriter subclass then setting the reference attribute to it:
MASingleOptionDescription new
label: 'Label' ;
reference: MAMyStringDescription new;
selectorAccessor: #myAccessor;
options: [WAPersonManager persons]asDynamicObject;
What I would use here is the description of persons, given that the
options are instances of Person:
...
reference: Person description;
...
To make this work out of the box, maybe
'asString' should be added to
MaStringWriter >> visitStringDescription:
I agree, the latest commit includes your suggestion.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
6185
days inactive
6192
days old
4 comments
2 participants
participants (2)
-
Ch Lamprecht -
Lukas Renggli