25 Oct
2010
25 Oct
'10
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