Strugging with Commands

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Strugging with Commands

keith1y
I am struggling to write a command which edits a model, rather than the
command instance itself. I am trying to do it this way since the model
class and description may change whereas the command class does not.


PREditUser-asComponent

    | component |
     
    component := self model asComponent.
   
    ^ component addValidatedForm: (Array with: self saveButton with:
self cancelButton);
        onAnswer: [ :value |
            [ self execute ] on: Error do: [:err |  ^ component errors
add: err.                    ].
            value storeOnDB.
            self context: self answer  "<<<does not work" ];
        yourself.


The problem that I am having is that the standard onAnswer: for commands
is implemented by the containing Contents Widget somewhere else and I
cant see any way of overriding it.

Thanks in advance for any ideas

Keith
   

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Strugging with Commands

Lukas Renggli-2
> I am struggling to write a command which edits a model, rather than  
> the
> command instance itself. I am trying to do it this way since the model
> class and description may change whereas the command class does not.

Why do you use a command then? As described in the GOF book, this  
design pattern is used to encapsulate an action and its parameters.

> [code]
>
> The problem that I am having is that the standard onAnswer: for  
> commands
> is implemented by the containing Contents Widget somewhere else and I
> cant see any way of overriding it.

I neither understand your code nor the sentence above ;-)

Is the problem that Seaside doesn't allow to have multiple onAnswer:  
handlers? I guess this is something that should be fixed ...

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Strugging with Commands

keith1y
Lukas Renggli wrote:

>> I am struggling to write a command which edits a model, rather than  
>> the
>> command instance itself. I am trying to do it this way since the model
>> class and description may change whereas the command class does not.
>>    
>
> Why do you use a command then? As described in the GOF book, this  
> design pattern is used to encapsulate an action and its parameters.
>
>  
It does encapsulate an action. The problem being that commands as they
are can only act upon themselves.

Keith

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Strugging with Commands

Lukas Renggli-2
>>> I am struggling to write a command which edits a model, rather than
>>> the
>>> command instance itself. I am trying to do it this way since the  
>>> model
>>> class and description may change whereas the command class does not.
>>>
>>
>> Why do you use a command then? As described in the GOF book, this
>> design pattern is used to encapsulate an action and its parameters.
>
> It does encapsulate an action. The problem being that commands as they
> are can only act upon themselves.

Why do you think that? All commands I know act on other objects,  
mostly on structures in Pier.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Strugging with Commands

keith1y
Lukas Renggli wrote:

>>>> I am struggling to write a command which edits a model, rather than
>>>> the
>>>> command instance itself. I am trying to do it this way since the  
>>>> model
>>>> class and description may change whereas the command class does not.
>>>>
>>>>        
>>> Why do you use a command then? As described in the GOF book, this
>>> design pattern is used to encapsulate an action and its parameters.
>>>      
>> It does encapsulate an action. The problem being that commands as they
>> are can only act upon themselves.
>>    
>
> Why do you think that? All commands I know act on other objects,  
> mostly on structures in Pier.
>
> Cheers,
> Lukas
>  
I must choose my words more carefully: they can only display themselves,
since the value returned from the component must be a command or nil.

Here is my solution....

PRContentsWidget-i-buildComponent: aContext
    ^ aContext command asComponent
        onAnswer: [ :value | aContext command onAnswerValue: value to:
self ];
        yourself


PRCommand-i-onAnswerValue: componentReturnValue to: widget

"componentReturnValue is typically but not necessarily a command"  

componentReturnValue isNil
        ifTrue: [ ^ widget context: (widget context structure: widget
context structure) ].
    [ componentReturnValue execute ]
        on: Error
        do: [ :err |
             
            Preferences debugPierFormErrors ifTrue: [ err pass ].
           
            ^ widget component errors add: err.  ].
       
    widget context: componentReturnValue answer

=========
what do you think?

Keith










_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Strugging with Commands

keith1y
In reply to this post by Lukas Renggli-2
A simpler solution:

PRContentsWidget-buildComponent: aContext
    ^ aContext command asComponent
        onAnswer: [ :value | self onAnswerCommand: (aContext command
onReturn: value) ];
        yourself

PRCommand-onReturn: value

^ value

This gives commands an opportunity to handle the form's reply, returning
a command for the PRContents widget to #execute.

I think this is a better solution.

Keith

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Pier-Jetsam and PRViewToEditCommand

keith1y
Hello,

PRViewToEditCommand displays a read only display of the supplied model,
with Edit/Cancel buttons. Clicking Edit, goes to an editable version of
the same form, with a Save/Cancel button.

PRViewToEditCommand is a subclass of PRAction, a subclass of PRCommand,
which expects to display an editor for a supplied model.

This addition has been made available in a new "Pier-Jetsam" package for
some pier/magritte base add ons, where some of the base pier extensions
(i.e. from my previous email) can await potential inclusion in the main
release. I have also moved Pier-Debugging over into Pier-Jetsam.

Pier-Jetsam includes some logging of pier events, so it depends upon
Logging which in turn depends upon Kernel-Extensions

Installer ss project: '311'; install:'Kernel-Extensions'.
Installer ss project: 'Logging'; install:'Logging'.

best regards

Keith




_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki