confused by PRWidget initialisation

>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

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

> At 21:40 17/02/2010, Lukas Renggli wrote:
>>
>> 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?
>
> Hi Lukas,
>
> Most of the complexity is related to the layers of abstraction that
> necessarily come into play when implementing such a sophisticated and
> flexible system. However, in this specific case roles and responsibilities
> could probably be made a little bit more explicit. A quick fix is suggested
> attached. It is based on the following ideas:
>
> 1) Give a name to the different portions of the logic, and dispatch their
> implementation to responsible objects. This helps by making object
> collaboration flows more explicit (while providing also application
> developers with more hooks to override that specific portion of code, based
> on their specific requirements).
>
> 2) PRComponents have a structural role, where WAComponents have a visual
> role. It could help to make this distinction explicit in the code naming
> conventions. For example, PRStructuralComponent instead of PRComponent, and
> WAVisualComponent instead of WAComponent.
>
> Regards,
> Reza
>
>
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

> At 11:36 18/02/2010, Lukas Renggli wrote:
>>
>> I've integrated your changes in the latest Pier.
>
> Thanks for the integration Lukas!
>
> In the same vein of ideas, I'd like to share the attached change set. It
> contains:
> - A tiny framework that facilitates the *transformation" of Pier Widgets to
> Pier Commands through code reuse.
> - Its application to transform the following Widgets to Commands:
>        PRExportImportWidget
>        PRFileSettings
>        PUGroupsWidget
>        PRKernelSettings
>        PRPersistencySettings
>        PRSystemWidget
>        PUUsersWidget
>        PUSecurityWidget
>
> The second file contains a few patches to the Pier code, to get a 'Close'
> button while remaining fully compatible with the current behavior.
>
> If you find this useful, please don't hesitate to integrate it as you would
> find it better fitting into Pier (specifically, I don't like my patches to
> get the close button, but this was the most straitforward way to get it
> working).
>
> Regards,
> Reza
>
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

> I had an issue with (a) since I simply wanted  to keep using my page.
> Option (b) undos your modifications, since Seaside backtracks the state.
>  This could be tested easily. For example:
> - In "Kernel Settings" just rename the Kernel from "Pier" to "Pier2"
> - Push the "Save" button. The kernel is modified and the page title changes
> from "Pier" to "Pier2"
> - Push the back button (actually twice, in this specific example) to quite
> the page. Seaside brings back the previous Kernel named "Pier".
>
> This is obviously not what we wanted. Am I missing something here?

>> The widgets you wrapped do
>> work on the complete system though.
>
> You are right. To make this difference explicit, I'm actually making these
> widget adaptors available in a separate toolbar, that looks like this:
>
> PRDistribution >> admintoolsPage
>
>        admintoolsPage ifNotNil: [^admintoolsPage].
>
>        adminComp := PRComponent named: 'widget'.
>        adminComp
>                componentClass: PRCommandsWidget;
>                write: AAsWidgetAdaptorCommand allSubclasses using:
> PRCommandsWidget descriptionCommandClasses.
>
>        admintoolsPage:= (PRPage named: 'admintools')
>                addChild: adminComp;
>                contents: 'Admin tools: +widget+';
>                yourself.
>
>        ^admintoolsPage
>
> This assumes that those widget adaptors are additionally excluded from
> #commandsPage.