At 02:18 18/02/2010, Nick Ager wrote:
>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: ?
Pier provides a general mechanism for handling the issue we
discussed. It could be done differently, like the solution above.
But, in that case you break the logic of your implementation
framework, Pier, which means that you take an additional maintenance
responsibility to keep your logic in synch. with that of Pier (that
may change with time). I'd avoid this, and would keep the Property
Pattern of Pier that works just fine. After all, widgets are
transient objects that provide users a view on your model objects
during a session. I'd therefore recommend to focus on model objects,
and just reuse the solution provided by Pier.
Hoping this helps,
Reza
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
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
Hi,
i'm interested to display and change the priority of MADescription components when the browser display Halos.
For example i have a class with descriptionA, descriptionB.
For display the priority i change the WAClassnameHaloPlugin renderOn: method.
For change i create the WAPriorityHaloPlugin.
In the relative execute method i test if component is anMAComponent : self target description respondTo: #priority .
If yes i,m interested to open the Browser or WABrowser on the relative descriptionA.
The first question is: how i can define the name of descriptionA from anObject with magritte structure ?
into execute context of WAPriorityHaloPlugin i see aObject with memento, description, accessor ..... but i d'ont found link to the relative generating descriptionA.
The second question is: after change the descriptionA with the WABrowser and return to the halo browser how i can update the view to reflect the change ?
i have do some test but for now ti need to close and reopen the view.
Thanks for any considerations.
Dario
Hi,
I touched some packages I want you to take notice of. I found the code in AudioScrobbler useful that does xml binding stuff with magritte. I decided to rip it out into a new package to enhance it for write support.
Basically I just divided ASObject from AudioScrobbler in two classes:
- MXObject carries all the xml binding stuff
- ASObject deal with network stuff (curl etc.)
All *Reader classes in AudioScrobbler moved into the new package as well as the extensions to MADescription etc. The prefix changed from AS to MX.
I wanted to leave a clean state behind. There are dependencies between AudioScrobbler, Topfeeder and NetworkAddress. All used old magritte semantics so I had to change all of them.
So I touched 4 packages:
- NetworkAddress (magritteaddons repo)
- Magritte-XMLBinding (created in magritteaddons repo)
- AudioScrobbler (audioscrobbler repo)
- TopFeeder (topfeeder repo)
All tests were green afterwards while top feeder takes ages. There is a starting implementation for write support that is just at its beginning. I checked the package in to resolve all inter-package dependencies. As far as I can tell there hasn't been a side effect so far regarding the refactoring.
Norbert
Hi,
at the moment I'm thinking about a new project. The project will need a Web API to communicate with an iphone. To me it is quite obvious to implement the API part as a request handler. But when it comes to generation of e.g. XML I'm not sure what is the best way to do.
Sure, the seaside way to do it is to create my own canvas and every object needs to draw itself onto the canvas. But then I have magritte and a lot could be done automatically. Using xpath in the descriptions I could use Pastell to deserialize objects. To produce the output there could be a similar way. This would be some kind of XML binding then.
I wanted to ask if there is anything already available that could help me on my way or if there dedicated ideas how to solve this in seaside.
thanks in advance,
Norbert
Pier Group,
For a small site, I have a list of the item costs and the day:
|! Date | ! Cost of Item 1 |! Cost of Item 2
| 2010-Feb-11 | $2.50 | $2.25
| 2010-Feb-10 | $2.45 | $2.23
| 2010-Feb-9 | $2.41 | $2.26
| 2010-Feb-8 | $2.52 | $2.24
My customer is perfectly happy entering the text each day, however he wants a line graph showing the rise and fall of the two items for the last few weeks. Is there anything in pier which will display this sort of data? Maybe something in Squeak/Pharo which would generate a morph, that can be turned into a jpg?
Thanks,
John
I brought up the topic twice already. There is always a few months in between. The topic back then was the parameterization of component links when embedding them into a pier page.
The first problem did Lukas already solve. If I provide a description with parameterName in my component I can get the parameterValue in my component. A
MyMaComponent class>>descriptionChild
^ MAStringDescription new
parameterName: 'child';
accessor: #child;
label: 'Child component';
priority: 100;
yourself
enables me to specify
+mycomponent|child=title+
on a page and the component will get the "title" value through the child: setter. That is really nice. But the origin of my problem is a step further. In my last project I had big trouble accomplishing the wanted design by using renderers and componentClasses. I wanted to have a more freely doable design.
So the idea was to have a wrapper component around a MAContainerComponent that has the child description. With the child parameter I could select the child of the internal MAContainerComponent to display. Unfortunately the component mycomponent I get by doing
+mycomponent|child=title+
+mycomponent|child=abstract+
are not the same on one page. Is there a way to specify that I want to use the identical component if the embedded label (mycomponent) is the same? May I did something wrong but I always get different objects and it does make sense to me . Would be nice if this would bedoable. Otherwise I guess I need to do my own component-per-page-cache.
Any hints appreciated as always.
Norbert
Hi,
I'm trying to do in-place editing on Pier pages (or rather I want to
use pier wiki markup in user comments in my app). Has anyone done
something like that before? I am using the seaside 3.0 one-click
image.
I can do in-place editing with 'normal' text, the problem with pier
seems to be that the text that you want to edit (pier's wiki source)
is different from what you have on the displayed page (the HTML
rendering of the wiki text).
The Scriptaculous documentation mentions this:
http://wiki.github.com/madrobby/scriptaculous/ajax-inplaceeditor
How to edit server side formatted text (formatted with eg. textile)
Format the text on the server when the initial page is rendered. Add a
new server side action that returns the unformatted text in the
reponse and specify the load Text URL? option as a URL to this action.
The control will load the text from the server instead of using the
text on the page. The action that receives the updated text should
save it and return the formatted text as an HTML snippet in the
reponse.
The relevant option in Scriptaculous Ajax.InPlaceEditor is
loadTextURL V1.5 null Will cause the text to be loaded from
the server (useful if your text is actually textile and formatted on
the server)
Now I see nothing related to this in SUInPlaceEditor.
Do you have any hints how this combination of in-place editing and
wiki markup could be done?
Thanks in advance
Matthias
Hi,
I know that a PRDocument is a tree of objects that correspond to the
structure of a HTML document, such as paragraphs (PRParagraph), list
items (PRListItem) etc. When I edit an existing wiki page, where does
the raw wiki text come from? Is it re-generated from the objects
inside the PRDocument (how?), or is it kept somewhere in a separate
place?
Thanks
Matthias
