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:
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