Widget to Command adaptor
razavi at acm.org
Fri Feb 19 09:41:04 MET 2010
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
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?
>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'.
write: AAsWidgetAdaptorCommand allSubclasses using:
admintoolsPage:= (PRPage named: 'admintools')
contents: 'Admin tools: +widget+';
This assumes that those widget adaptors are additionally excluded
>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.
More information about the smallwiki