At 21:14 20/02/2010, you wrote:
>That's not how the one-click images are setup, thus I would prefer if
>you created your own package.
I just uploaded AAS-Pier-Widget Adaptors that:
- Adds a new *system administration* toolbar, which contains the
*widget adaptor commands*, and is only accessible to the *master* user.
- Moves all toolbars to the top of the page (instead of the bottom).
- Patches Pier code to add a Close button to system administration widgets.
May I ask you please to remove from your repository the deprecated
"AAS- Pier Commands-Widget Adaptors".
>673.
Great work; thanks for the information.
Regards,
Reza
Hi Lukas,
Thanks again for your time and precisions!
At 12:23 20/02/2010, Lukas Renggli wrote:
>Did you press 'refresh' to see the change?
No.
>Just hitting the back
>button only shows you the page from the browser cache.
Just double checked it, and you are perfectly right. The new value is
maintained. What I observed when using the back button was the value
cached by the browser.
>Maybe there are other setups where that might make sense?
Sure. For example, for practical reasons, I've preferred replacing
the *management* page with a specific *admin toolbar*, which is
actually only accessible to the *root* (and not users with *admin* rights).
>That's why I
>suggested to package the wrappers separately.
There is some progress in that direction, but some extra work is
necessary. The first package that I posted lacks usage examples. The
2nd package addresses this issue, but patches PRDistribution. Now,
I'm going to sub-class PRDistribution. However, before posting the
final package, would you please tell me your preference for one of
the followings:
1) The warper commands and the new distribution class integrated in
Pier-Setup as package.
2) The warper commands and the new distribution class integrated in a
new package.
I'd prefer the first one to avoid an additional package for a piece
of code that addresses basically the same needs than "Pier-Setup".
>If anywhere -- on potentially thousands of pages (like in the seaside
>book)
That's an interesting use case indeed. Would it be possible to
communicate more precisely the number of Pier structures that
contains Seaside book (just curious)?
> -- you (accidentally) give the permissions to edit the kernel
>name, anybody is able to change it. In the current default setup you
>just have to make sure that the system page and its children are
>protected.
Well noted; thanks for the precision. In my current experimental
distribution, I've addressed this issue as follows:
1) Added a "root" user (called *master*), and
2) Overridden PRCommand class >> #valideIn: for wrapper widgets to
return true only if the current user is master (and not superusers).
Regards,
Reza
Hi,
I noticed that the help button on the enhanced editor was broken in
Pier/Seaside 3.0. I've attached a simple fix, though as I don't entirely
understand the intent of the implementation, it would be good if someone can
review it to check the bug shouldn't be fixed elsewhere.
Nick
At 09:48 20/02/2010, Lukas Renggli wrote:
>That's a bug, I've seen that too at some time, but never managed to
>reliably reproduce.
It looks like being related to a mismatch between the actual and
cached values in MAMultipleOptionDescription >> validateKind:. I
don't have the exact context within within the bug appears, but was
wondering if it could be caused by MADynamicObject.
Hi Lukas,
Thanks for your feedback!
At 22:14 18/02/2010, Lukas Renggli wrote:
>I think that makes a good addition to Pier as an extension.
I understand your choice, and I'd basically do the same. However, let
me emphasize that I decided to develop this as an alternative to
http://localhost:8080/pier/system/management, which is proposed as a
default solution in PRDistribution, since I had two issues with that tool page:
1) 'Save' and 'Cancel' buttons in that page have a somehow
non-standard behavior.
2) To close that page, I only found the following two options:
(a) close the page
(b) use the back button
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?
>I don't
>feel like adding it to Pier-Seasde though, as commands are normally
>designed to work on a specific structures.
Yes, this mismatch is in fact a concern, although, the WtC adaptor
refers too to a structure (the dummy PRComponent created by
#widgetHolder, which is not the current structure). But, in my case,
the practical benefit justifies a kind of conceptual compromise.
>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.
>Also your strategy of wrapping the
>widgets into commands makes security sort of fragile.
This is an important issue. Could you develop this a little more please?
As far as the current widget adaptor commands are concerned, the
security is the same as the management page: the are only available
to admin users. Additionally, Pier allows reenforcing this policy
quite easily, for example, by attaching specific permissions to the
admintoolsPage proposed above. Won't this suffice?
>Maybe better write
>a short mail to the list explaining the change,
Sure; well noted.
Regards,
Reza
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
