Hi Stephen,
that Decorator solution would work, but not in my case. Let me explain
why.
I'm trying to come up with another approach to Cairngorm's
SequenceCommand. The problem with that implementation is that the
commands in the sequence know that they are part of a sequence. This
makes it impossible to reuse a command outside a sequence or in a
another sequence without coding some conditional logic inside the
commands. The solution I'm trying to figure out let you define
commands as single units and then group together the events that will
trigger the commands in a sequence allowing better code reuse.
I already wrote some code that lets you define the sequence etc. I
have a CommandProxy class that proxies a command and is able to
intercept the execute method. This all works fine.
The problem is that when you implement IResponder, and you pass the
command as a responder to a delegate, you have no control over the
result and fault methods because it is not the proxy that is passed
but the original command instance.
The code to do this in the command proxy (I was hoping to work):
_command.execute.apply(this, event);
where "_command" is the proxied command and "this" is the command
proxy. Unfortunately this doesn't work.
I sort of worked around this by adding bindings on properties in the
ModelLocator and when a property changes because of the result method
in a command, the next event is dispatched to invoke the next command.
This works, but it assumes that you always update a property in the
ModelLocator when a command executes.
I hope this all makes sense. If apply() would work with instance
methods, I'm sure this solution would be a big improvement to the
Cairngorm framework.
Any thoughts? (and thanks for your time!)
regards,
Christophe
--- In flexcoders@yahoogroups.com, Stephen Allison <[EMAIL PROTECTED]>
wrote:
>
> Hi,
>
> To address your case of wanting to execute code before and after the
> fault and result methods of IResponder, would it be sufficient to
> create an implementation of IResponder that takes another IResponder
> and wraps that object's fault and response methods. Something like:
>
>
> class ResponderWrapper implements IResponder {
>
> private var _wrappedResponder;
>
> public ResponderWrapper(wrapped:IResponder) {
> _wrappedResponder = wrapped;
> }
>
> public function fault() {
> // your pre-execution code here
> _wrappedResponder.fault()
> // your post-execution code here
> }
>
> // and similarly for result.
> }
>
> You then use ResponderWrapper in place of the 'wrapped' IResponder.
>
> Further flexibility could be achieved by passing in additional
> parameters that are functions defining the pre and post execution
> operations when constructing this object. I have found this kind of
> 'decorator' approach quite useful in the past.
>
> Regarding the use of 'apply' - I think you are correct that you
> cannot use 'apply' on a method, for methods 'this' always is the
> owning object, even if you are referring to a method via a variable
> of type function.
>
> HTH
> Stephen
>
