19 Feb
2010
19 Feb
'10
9:41 a.m.
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