26 Jun
2009
26 Jun
'09
9:56 a.m.
Hi,
I'm toying around with MAPluggableAccessor. While I really like
to introduce some kind of delegated descriptions it doesn't
work that easy. I'm not really familiar with caching of the
magritte descriptions. My problem is that I'm operating on
a MAContainerComponent using childAt: . The children are
detected by =. The MAPluggableAccessor implements equality based
on the equality of the read and write accessors. But these are
blocks and return false if compared.
So I'm wondering what is the intended of the class. I can get
it to work if I'm caching the accessor inside the component.
But maybe it is supposed to work different.
Norbert
26 Jun
26 Jun
11:27 a.m.
I'm toying around with MAPluggableAccessor. While
I really like
to introduce some kind of delegated descriptions it doesn't
work that easy. I'm not really familiar with caching of the
magritte descriptions. My problem is that I'm operating on
a MAContainerComponent using childAt: .
I don't have such a method.
The children are
detected by =. The MAPluggableAccessor implements equality based
on the equality of the read and write accessors. But these are
blocks and return false if compared.
Indeed, identity of descriptions is currently established with the accessors.
The whole identity thing is problematic and caused some lengthy
discussion dating back to ESUG 2006 in Brussels. At the time I started
with Magritte the accessor seemed to be a decent choice, however later
it became clear that it does not work well for accessors like the
MAPluggableAccessor or MANullAccessor.
Today I think the identity should be established using a special
object, by default it would just use the identity of the description.
If the developer provided an UUID in the code it would use that
instead. Although such an approach does not sound very OO, it is
probably the only way to ensure object identity even if the
description changes completely (including the accessor and the class)
or when identity has to be preserved across multiple images.
So I'm wondering what is the intended of the
class. I can get
it to work if I'm caching the accessor inside the component.
But maybe it is supposed to work different.
I don't understand the above part.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
12:06 p.m.
On Fri, 2009-06-26 at 11:27 +0200, Lukas Renggli wrote:
Really? If this since ages and it seems to be your code :)
MAContainerComponent>>childAt: aDescription
^ children at: aDescription ifAbsent: [ nil ]
I'm using gemstone but I had this method in my old squeak installation
as well.
I was just wondering if I try to use the MAPluggableAccessor the
wrong way and hence facing problems. I can do
accessor
^ accessor ifNil: [
accessor := (MAPluggableAccessor
read: [:model|]
write: [:model :object| ]) ]
and then
descriptionThings
^ MAToManyRelationDescription
accessor: self accessor
label: 'Things'
priority: 10
This way I get it running but I don't like it much. I don't know exactly
what MANamedBuilder is caching. I just thought it might solve the
problem by caching the instances.
Norbert
I'm toying
around with MAPluggableAccessor. While I really like
to introduce some kind of delegated descriptions it doesn't
work that easy. I'm not really familiar with caching of the
magritte descriptions. My problem is that I'm operating on
a MAContainerComponent using childAt: .
I don't have such a method.
The children
are
detected by =. The MAPluggableAccessor implements equality based
on the equality of the read and write accessors. But these are
blocks and return false if compared.
Indeed, identity of descriptions is currently established with the accessors.
The whole identity thing is problematic and caused some lengthy
discussion dating back to ESUG 2006 in Brussels. At the time I started
with Magritte the accessor seemed to be a decent choice, however later
it became clear that it does not work well for accessors like the
MAPluggableAccessor or MANullAccessor.
Today I think the identity should be established using a special
object, by default it would just use the identity of the description.
If the developer provided an UUID in the code it would use that
instead. Although such an approach does not sound very OO, it is
probably the only way to ensure object identity even if the
description changes completely (including the accessor and the class)
or when identity has to be preserved across multiple images.
So I'm wondering what is the intended of the
class. I can get
it to work if I'm caching the accessor inside the component.
But maybe it is supposed to work different.
I don't understand the above part.
12:52 p.m.
I'm toying around with MAPluggableAccessor. While
I really like
to introduce some kind of delegated descriptions it doesn't
work that easy. I'm not really familiar with caching of the
magritte descriptions. My problem is that I'm operating on
a MAContainerComponent using childAt: .
I don't have such a method.
I don't
understand the above part.
I was just wondering if I try to use the MAPluggableAccessor the
wrong way and hence facing problems. I can do
accessor
^ accessor ifNil: [
accessor := (MAPluggableAccessor
read: [:model|]
write: [:model :object| ]) ]
and then
descriptionThings
^ MAToManyRelationDescription
accessor: self accessor
label: 'Things'
priority: 10
This way I get it running but I don't like it much. I don't know exactly
what MANamedBuilder is caching. I just thought it might solve the
problem by caching the instances.
2:16 p.m.
On Fri, 2009-06-26 at 12:52 +0200, Lukas Renggli wrote:
Really? If this since ages and it seems to be your code :)
MAContainerComponent>>childAt: aDescription
^ children at: aDescription ifAbsent: [ nil ]
Ahh, I thought you refereed to MAContainerDescription. I have
#childAt: in MAContainerComponent too.
What you could try is to replace the Dictionary with an
IdentityDictionary in #buildChildren of MAContainerComponent. I am not
quite sure about all the consequences, but I guess it should solve
your problem.
Ok, I test it at least.
Why don't quite understand what you are trying to do? If you don't use
the accessor just don't assign one.
I must be more careful about how to do example code :) At the end the
blocks are of course not empty. Storing the accessor in an instance
variable gives me the identical accessor object with identical blocks.
This way the childAt: call succeeds.
The whole problem deals with tags. Until now I had several objects that
should be taggable. But as the code grew there were other things those
objects could have: comments, scores, etc.
Trying to solve this by inheritance is not possible for me. My idea now
is to treat tags more as meta data: The objects don't contain the data
anymore. At the moment I have any taggable object WHChallenge to that
I add
WHChallenge class>>descriptionTags
^ WHTag tagsDescription
WHTag class>>tagsDescription
^ (MAToManyRelationDescription
accessor: (MAPluggableAccessor
read: [:model|self tagsFor: model]
write: [:model :tags| self storeTags: tags for: model])
label: 'Tags'
priority: 40
)
classes: {WHTag};
reference: WHTag description;
componentClass: WHTagSelectComponent;
yourself
The WHTag classes holds all the tag instances. If this approach works
out I would try to solve this even more generic so that I can have a
common code base for this meta-data/annotation kind of things. All
other cases for comments, scores etc. should then be fairly easy
Norbert
I'm toying
around with MAPluggableAccessor. While I really like
to introduce some kind of delegated descriptions it doesn't
work that easy. I'm not really familiar with caching of the
magritte descriptions. My problem is that I'm operating on
a MAContainerComponent using childAt: .
I don't have such a method.
I don't understand the above part.
I was just wondering if I try to use the MAPluggableAccessor the
wrong way and hence facing problems. I can do
accessor
^ accessor ifNil: [
accessor := (MAPluggableAccessor
read: [:model|]
write: [:model :object| ]) ]
and then
descriptionThings
^ MAToManyRelationDescription
accessor: self accessor
label: 'Things'
priority: 10
This way I get it running but I don't like it much. I don't know exactly
what MANamedBuilder is caching. I just thought it might solve the
problem by caching the instances.
5412
days inactive
5412
days old
4 comments
2 participants
participants (2)
-
Lukas Renggli -
Norbert Hartl