Widget to Command adaptor

[Reza RAZAVI]

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