onAnswerCommand and structure change
Locked
onAnswerCommand and structure change
 
|
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 |
|
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 <[hidden email]> 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. _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: onAnswerCommand and structure change
|
|
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 <[hidden email]> 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 <[hidden email]> 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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: onAnswerCommand and structure change
|
|
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: onAnswerCommand and structure change
|
|
In reply to this post by Nick
Nick,
thanks for your answer. Comments inline! On 22.10.2010, at 19:01, Nick Ager wrote: Hi Norbert, 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
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
Hi Norbert,
Yes now I understand your use case I realise mine is completely different. It's more about creating a simple environment for edit commands (and others) when my page environments contain a lot of template components; the content area is small relative to the environment.
Nick _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: onAnswerCommand and structure change
|
|
In reply to this post by Lukas Renggli
On 25.10.2010, at 09:21, Lukas Renggli wrote: > 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. I didn't use it in code already but the change looks good to me. But why did you call it success? I'm not that lucky that there is a new word in the mix. To me the cancel operation is of stable meaning. It seems to be cancel everywhere. On the other hand there is save and commit. And now there is even success. Even though it is not nice to call it saveAnswer I think it would be the better name for it. Norbert _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
«
Return to Magritte, Pier and Related Tools
|
1 view|%1 views
| Free forum by Nabble | Edit this page |