30 Nov
2007
30 Nov
'07
6:19 a.m.
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
30 Nov
30 Nov
8:51 a.m.
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
7:29 p.m.
Lukas Renggli wrote:
It does encapsulate an action. The problem being that commands as they
are can only act upon themselves.
Keith
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.
7:35 p.m.
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.
7:45 p.m.
Lukas Renggli wrote:
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
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.
8:08 p.m.
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
11:34 p.m.
New subject: Pier-Jetsam and PRViewToEditCommand
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
5986
days inactive
5986
days old
6 comments
2 participants
participants (2)
-
Keith Hodges -
Lukas Renggli