Hi,
i'am new about Pier.
I do some test with Pharo1-0.10509 and Pier-Seaside-lr.448
I have some questions :
1) i have remove some item from commands.
Now when go into commands edit to add item i can't save the change because the error :
Command Classes: Invalid input given
2) i d'ont understund how i can release the 'project' for deploy.
How i can manage the development with the environment and the command
and the deploy with only 'end user' informations ?
3) i read into Frequently Asked Questions :
Put a link *Top>.* to the bottom of your page.
You can also use the ‘@-‘ syntax to jump to particular locations in a page
But i don't know how manage it.
How i can found example ?
Thanks,
Dario
At 22:14 18/02/2010, you wrote:
>I think that makes a good addition to Pier as an extension.
I just wrapped it with Pier-Setup, and uploaded it to Pier2 repo.
For more details, please see the package comments.
If you don't like it, please feel free to delete the package.
Regards,
Reza
At 15:22 18/02/2010, Lukas Renggli wrote:
>You can post them directly to my repository
Well noted; thanks for the precision!
I just uploaded a Monticello package to your Pier2 repo. It contains
the code for the first .st file sent previously, and some comments on
how to get easily the 'Close' button (code contained in the 2nd .st
file sent previously).
Please don't hesitate to remove it (and the future posts) once you
have looked at it.
BTW, I assume that you automatically get a notification upon each
upload. If this is not the case, please let me know to send then an email.
Regards,
Reza
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
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
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
