onAnswerCommand and structure change - smallwiki

Nick Ager

22 Oct 22 Oct

7:01 p.m.

Hi Norbert, I think I might have solved a similar problem in a different way. I created a "clean" environment specifically for non-view commands. Then I derived from PRPierFrame and implemented: environment ^ self context command useEditingEnvironment ifTrue: [ self kernel editingEnvironment ] ifFalse: [ self context structure environment ] Then: PRCommand>>useEditingEnvironment ^ (self isView or: [self isQuick]) not --- Other ways round would be to create your own PRContents widget or return a command with the structure you want to display, instead of returning nil --- I only mention the above work-arounds as I don't have enough knowledge to say for certain that your changes wouldn't cause unintended side-effects.. Hope this helps Nick On 22 October 2010 12:57, Norbert Hartl <norbert(a)hartl.name> wrote:

...

I like to execute a command in a way that the structure is changed while the command is being executed. If the command is commited I like to advance the structure to another structure. If the command is aborted than I like to return to the structure from where the command has been invoked. Basically I do something like this html anchor goto: (self context structure: self structureWhileCommandIsExecuting command: MyPierCommand new); with: 'do it' ] In MyPierCommand>>doExecute I do at the end self answer: (self context structure: self structureAfterCommandHasBeingCommited ) This way I have chose a structure for command execution and the structure if the command is commited. But on abort it stays where it has been executed (structureWhileCommandIsExecuting). Looking at PRContentsWidget>>onAnswerCommand: aCommand aCommand isNil ifTrue: [ ^ self context: (self context structure: self context structure) ]. [ aCommand execute ] on: MAError do: [ :err | ^ self component errors add: err ]. self context: aCommand answer we see that if aCommand isNil (abort) the structure is nailed to the current one (while executing). Would it be ok to change that so it is answering every time? I simple change would be to change buildComponent: aContext ^ aContext command asComponent onAnswer: [ :value | self onAnswerCommand: value ]; yourself to buildComponent: aContext ^ aContext command asComponent onAnswer: [ :value | value ifNotNil: [ self onAnswerCommand: value ] ifNil: [ aContext command doAnswer ] ]; yourself this way PRCommand>>doAnswer self answer ifNil: [ self answer: (self context structure: self structure) ] would the same but some could overwrite the answer when creating the link what do you think? Norbert _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Reply

Lukas Renggli

9:21 a.m.

I posted some changes that should be mostly backward compatible. The changes give much more control over the flow of commands. It is already used in the halo-view and the security-browser. Let me know what you think. Name: Pier-Model-lr.398 Author: lr Time: 25 October 2010, 9:19:02 am UUID: d92bbefb-5cfe-4323-8eff-8d39323b5aaf Ancestors: Pier-Model-lr.397 - replaced PRCommand>>#answer: with #successAnswer: and #cancelAnswer: to give more control over the flow Name: Pier-Seaside-lr.497 Author: lr Time: 25 October 2010, 9:19:07 am UUID: f04066ae-fabc-4a66-863b-0adaf5980374 Ancestors: Pier-Seaside-lr.496 - replaced PRCommand>>#answer: with #successAnswer: and #cancelAnswer: to give more control over the flow Name: Pier-Security-lr.172 Author: lr Time: 25 October 2010, 9:19:12 am UUID: 57dc8ba1-cedb-49c9-92ac-5990b30be64e Ancestors: Pier-Security-lr.171 - replaced PRCommand>>#answer: with #successAnswer: and #cancelAnswer: to give more control over the flow Name: Pier-EditorEnh-lr.59 Author: lr Time: 25 October 2010, 9:19:23 am UUID: 1fe5b2a7-e6cb-4f48-ba76-da58e136e3f3 Ancestors: Pier-EditorEnh-lr.57 - replaced PRCommand>>#answer: with #successAnswer: and #cancelAnswer: to give more control over the flow Name: Pier-Tests-Model-lr.16 Author: lr Time: 25 October 2010, 9:19:15 am UUID: 76a4502d-c534-445f-b4cc-49396a4fabc4 Ancestors: Pier-Tests-Model-lr.15 - replaced PRCommand>>#answer: with #successAnswer: and #cancelAnswer: to give more control over the flow Name: Pier-Security-lr.172 Author: lr Time: 25 October 2010, 9:19:12 am UUID: 57dc8ba1-cedb-49c9-92ac-5990b30be64e Ancestors: Pier-Security-lr.171 - replaced PRCommand>>#answer: with #successAnswer: and #cancelAnswer: to give more control over the flow On 25 October 2010 08:28, Lukas Renggli <renggli(a)gmail.com> wrote:

...

Norbert, While what Nick proposes is a nice workaround, I think it would be useful to let the command decide on the cancel continuation. However the logic for that should go into the Model, not the View. Also we have to pay attention not to use #ifNil:ifNotNil: and friends, because that doesn't work across all supported platforms. Norbert, can you provide a change? Lukas On 22 October 2010 19:01, Nick Ager <nick.ager(a)gmail.com> wrote:

Hi Norbert, I think I might have solved a similar problem in a different way. I created a "clean" environment specifically for non-view commands. Then I derived from PRPierFrame and implemented: environment ^ self context command useEditingEnvironment ifTrue: [ self kernel editingEnvironment ] ifFalse: [ self context structure environment ] Then: PRCommand>>useEditingEnvironment ^ (self isView or: [self isQuick]) not --- Other ways round would be to create your own PRContents widget or return a command with the structure you want to display, instead of returning nil --- I only mention the above work-arounds as I don't have enough knowledge to say for certain that your changes wouldn't cause unintended side-effects.. Hope this helps Nick On 22 October 2010 12:57, Norbert Hartl <norbert(a)hartl.name> wrote:

I like to execute a command in a way that the structure is changed while the command is being executed. If the command is commited I like to advance the structure to another structure. If the command is aborted than I like to return to the structure from where the command has been invoked. Basically I do something like this html anchor goto: (self context structure: self structureWhileCommandIsExecuting command: MyPierCommand new); with: 'do it' ] In MyPierCommand>>doExecute I do at the end self answer: (self context structure: self structureAfterCommandHasBeingCommited ) This way I have chose a structure for command execution and the structure if the command is commited. But on abort it stays where it has been executed (structureWhileCommandIsExecuting). Looking at PRContentsWidget>>onAnswerCommand: aCommand aCommand isNil ifTrue: [ ^ self context: (self context structure: self context structure) ]. [ aCommand execute ] on: MAError do: [ :err | ^ self component errors add: err ]. self context: aCommand answer we see that if aCommand isNil (abort) the structure is nailed to the current one (while executing). Would it be ok to change that so it is answering every time? I simple change would be to change buildComponent: aContext ^ aContext command asComponent onAnswer: [ :value | self onAnswerCommand: value ]; yourself to buildComponent: aContext ^ aContext command asComponent onAnswer: [ :value | value ifNotNil: [ self onAnswerCommand: value ] ifNil: [ aContext command doAnswer ] ]; yourself this way PRCommand>>doAnswer self answer ifNil: [ self answer: (self context structure: self structure) ] would the same but some could overwrite the answer when creating the link what do you think? Norbert _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

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

-- Lukas Renggli www.lukas-renggli.ch

Reply

Norbert Hartl

25 Oct 25 Oct

10:22 a.m.

Nick, thanks for your answer. Comments inline! On 22.10.2010, at 19:01, Nick Ager wrote:

...

Hi Norbert, I think I might have solved a similar problem in a different way. I created a "clean" environment specifically for non-view commands. Then I derived from PRPierFrame and implemented: environment ^ self context command useEditingEnvironment ifTrue: [ self kernel editingEnvironment ] ifFalse: [ self context structure environment ] Then: PRCommand>>useEditingEnvironment ^ (self isView or: [self isQuick]) not --- Other ways round would be to create your own PRContents widget or return a command with the structure you want to display, instead of returning nil --- I only mention the above work-arounds as I don't have enough knowledge to say for certain that your changes wouldn't cause unintended side-effects..

I think what you did is quite nice but for a different use case :) What I'm actually after is to have complete control over the visual transition while a command is being executed. A command is being valid on a certain page and is active if permissions are sufficient. So you have a starting structure. While executing the command every command not being a quick command displays a component. The transitional component is embedded in an environement as well. You solved this with a default environment. But you seem to use this for every command execution. And that is difference. I need different environments while executing commans. That is easy to achieve because you can specify the target structure along with the command which looks natural to me. If I see it correctly than you don't leave the structure while editing, right? You change the environment to display different stuff. On cancel time the old environment is restored and while you didn't leave the structure you are back there, right? That is a nice and pragmatic approach to it. I think it is an advantage to specify a command starting from one structure A, while being executed being embedded in a structure B. On commit/save time it will end on structure C. If the action was abort/cancel instead it would land on structure D. This way it is clearer what will happen. I'm playing with chaining commands and this way you could specify it more like a state machine if things get complex. Norbert

...

On 22 October 2010 12:57, Norbert Hartl <norbert(a)hartl.name> wrote: I like to execute a command in a way that the structure is changed while the command is being executed. If the command is commited I like to advance the structure to another structure. If the command is aborted than I like to return to the structure from where the command has been invoked. Basically I do something like this html anchor goto: (self context structure: self structureWhileCommandIsExecuting command: MyPierCommand new); with: 'do it' ] In MyPierCommand>>doExecute I do at the end self answer: (self context structure: self structureAfterCommandHasBeingCommited ) This way I have chose a structure for command execution and the structure if the command is commited. But on abort it stays where it has been executed (structureWhileCommandIsExecuting). Looking at PRContentsWidget>>onAnswerCommand: aCommand aCommand isNil ifTrue: [ ^ self context: (self context structure: self context structure) ]. [ aCommand execute ] on: MAError do: [ :err | ^ self component errors add: err ]. self context: aCommand answer we see that if aCommand isNil (abort) the structure is nailed to the current one (while executing). Would it be ok to change that so it is answering every time? I simple change would be to change buildComponent: aContext ^ aContext command asComponent onAnswer: [ :value | self onAnswerCommand: value ]; yourself to buildComponent: aContext ^ aContext command asComponent onAnswer: [ :value | value ifNotNil: [ self onAnswerCommand: value ] ifNil: [ aContext command doAnswer ] ]; yourself this way PRCommand>>doAnswer self answer ifNil: [ self answer: (self context structure: self structure) ] would the same but some could overwrite the answer when creating the link what do you think? Norbert _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Reply