17 Feb
2010
17 Feb
'10
9:07 p.m.
Hi Nick,
My understating is the following:
1) For each specific Distribution, PRComponents keep track of the
default attribute values for each Widget (i.e., user preferences for
that Distribution). PRDistribution>>childrenWidget is an example of
such specification.
2) At runtime, when Widgets are instantiated for each Session, these
default values are affected to their respective Widget attribute by
WAComponent >> initializeOwner:link:, itself called by PRComponent >>
componentFor:, in turn called by PRContext >> buildComponent:for:.
PRWidgets overrides #write:using: to keep track of its attribute
values in its properties dictionary (instead of widget specific
accessors). This design decision facilitates the implementation and
maintenance of specific Widgets.
Hoping this helps,
Reza
At 19:56 17/02/2010, Nick Ager wrote:
Hi,
I'm writing this as PRWidget initialisation had me confused for a
while, and I guess it might confuse other newcomers. I'd also like
to check with the list that my understanding is correct.
For example given the code below:
PRDistribution>>childrenWidget
^ childrenWidget ifNil: [childrenWidget := (PRComponent named: 'children')
componentClass: PRChildrenWidget;
write: 2
using: PRChildrenWidget descriptionLevel;
write: true
using: PRChildrenWidget descriptionExpand;
yourself
]
and:
PRChildrenWidget class>>descriptionExpand
^ MABooleanDescription new
default: self defaultExpand;
parameterName: 'expand';
accessor: #expand;
label: 'Expand';
priority: 310;
yourself
I would have expected an accessor "PRChildWidget>>expand:" to be
called with the value: 'true'. I created my PRWidget derived class
based on this assumption. However my equivalent setter was not being
called and a closer look showed PRChildWidget to have no setters
only getters. The getter reads as:
PRChildWidget>>expand
^ self read: #descriptionExpand
What's actually happening is "PRComponent>>description" is being
called, not as I'd imagined: "PRChildWidget>>description".
tracing through the following code:
PRComponent>>write: anObject using: aDescription
(self basicDescription includes: aDescription)
ifTrue: [ super write: anObject using: aDescription ]
ifFalse: [
(anObject notNil and: [ aDescription isDocumentDescription ])
ifTrue: [ anObject owner: self ].
self settings at: aDescription put: anObject ]
reveals the code: "self settings at: aDescription put: anObject" is
called, so "true" is placed in a settings Dictionary keyed by:
#descriptionExpand
I've just about understood the code so far, and though I haven't
traced through PRChildrenWidget instantiation it looks like in
WAComponent>>initializeOwner:link: that the settings are copied to
the newly created PRChildrenWidget object.
Phew.
I think I can see why there's complexity, but seems a shame that it
in WAComponent>>initializeOwner:link: the code couldn't call the
accessors of the componentClass assuming that the Magritte
descriptions were configured to use an accessor pattern.
Or perhaps I've misunderstood??
Cheers
Nick
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
17 Feb
17 Feb
9:40 p.m.
New subject: confused by PRWidget initialisation
As Reza writes the components (or widgets) cannot carry their own
configuration, because they are instantiated later on and on a
per-session based. So the configuration happens on a generic model
object (PRComponent) that takes the description of the component and
stores its values in the settings dictionary. Whenever a component is
instantiated it is initialized with the settings from the model, that
can be overridden with the settings given in the link that embeds the
component.
It could well be that the current implementation is not as strait
forward as it could be. Over the time Magritte and Pier both changed
quite heavily and maybe it could be done simpler today?
Lukas
On 17 February 2010 21:07, Reza RAZAVI <razavi(a)acm.org> wrote:
Hi Nick,
My understating is the following:
1) For each specific Distribution, PRComponents keep track of the default
attribute values for each Widget (i.e., user preferences for that
Distribution). PRDistribution>>childrenWidget is an example of such
specification.
2) At runtime, when Widgets are instantiated for each Session, these default
values are affected to their respective Widget attribute by WAComponent >>
initializeOwner:link:, itself called by PRComponent >> componentFor:, in
turn called by PRContext >> buildComponent:for:.
PRWidgets overrides #write:using: to keep track of its attribute values in
its properties dictionary (instead of widget specific accessors). This
design decision facilitates the implementation and maintenance of specific
Widgets.
Hoping this helps,
Reza
At 19:56 17/02/2010, Nick Ager wrote:
--
Lukas Renggli
http://www.lukas-renggli.ch
Hi,
I'm writing this as PRWidget initialisation had me confused for a while,
and I guess it might confuse other newcomers. I'd also like to check with
the list that my understanding is correct.
For example given the code below:
PRDistribution>>childrenWidget
^ childrenWidget ifNil: [childrenWidget := (PRComponent named: 'children')
componentClass: PRChildrenWidget;
write: 2
using: PRChildrenWidget descriptionLevel;
write: true
using: PRChildrenWidget descriptionExpand;
yourself
]
and:
PRChildrenWidget class>>descriptionExpand
^ MABooleanDescription new
default: self defaultExpand;
parameterName: 'expand';
accessor: #expand;
label: 'Expand';
priority: 310;
yourself
I would have expected an accessor "PRChildWidget>>expand:" to be called
with the value: 'true'. I created my PRWidget derived class based on this
assumption. However my equivalent setter was not being called and a closer
look showed PRChildWidget to have no setters only getters. The getter reads
as:
PRChildWidget>>expand
^ self read: #descriptionExpand
What's actually happening is "PRComponent>>description" is being
called,
not as I'd imagined: "PRChildWidget>>description".
tracing through the following code:
PRComponent>>write: anObject using: aDescription
(self basicDescription includes: aDescription)
ifTrue: [ super write: anObject using: aDescription ]
ifFalse: [
(anObject notNil and: [ aDescription isDocumentDescription ])
ifTrue: [ anObject owner: self ].
self settings at: aDescription put: anObject ]
reveals the code: "self settings at: aDescription put: anObject" is
called, so "true" is placed in a settings Dictionary keyed by:
#descriptionExpand
I've just about understood the code so far, and though I haven't traced
through PRChildrenWidget instantiation it looks like in
WAComponent>>initializeOwner:link: that the settings are copied to the newly
created PRChildrenWidget object.
Phew.
I think I can see why there's complexity, but seems a shame that it in
WAComponent>>initializeOwner:link: the code couldn't call the accessors of
the componentClass assuming that the Magritte descriptions were configured
to use an accessor pattern.
Or perhaps I've misunderstood??
Cheers
Nick
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
18 Feb
18 Feb
2:18 a.m.
New subject: confused by PRWidget initialisation
Thanks for the replies, as ever very helpful.
> PRWidgets overrides #write:using: to keep track of
its attribute values
in its properties dictionary (instead of widget
> specific accessors). This design decision
facilitates the implementation
and maintenance of specific Widgets.
This helped me understand the mechanism why PRWidget derived objects store
their properties in a directory rather than via an accessor. I experimented
by overriding #write:using in my PRWidget derived class, to reinstating the
default implementation in Object thus:
write: anObject using: aDescription
aDescription accessor write: anObject to: self
Then magically the setters in my derived class where called as I'd
originally anticipated.
I understand that sometimes it's handy to be able to dynamically add fields
to an object, which is when it makes sense to use a Dictionary, however to
aid my understanding it seems much simpler to store properties in instance
variables accessed via accessors. Will I fall into any problems if I use an
accessor pattern on my PRWidget derived classes by ensuring that
#write:using: reimplements the Object>>write:using: ?
Nick
5193
days inactive
5194
days old
2 comments
3 participants
participants (3)
-
Lukas Renggli -
Nick Ager -
Reza RAZAVI