Comments for Joel Hooks

Comment on Robotlegs, AS3-Signals and the SignalCommandMap Example by sjhewitt

sjhewitt — Sun, 21 Feb 2010 09:03:04 +0000

I thought about using a reflector, but i would still run into the problem of not being able to inject to interfaces. Personally, i think the contract created using Signal.valueClasses should be honoured when it is set, otherwise falling back to the usual method.

Implicitly named injectors could be used, but does add quite a bit more complexity to the signal routing. It could also be possible to create an IInjectedSignal interface that extends ISignal and adds a command something like:
mapValues(injector, valueObjects) and unmapValues(injector, valueObjects)
Then the routeSignalToCommand works like this:
http://gist.github.com/310237

Comment on Robotlegs, AS3-Signals and the SignalCommandMap Example by Will

Will — Sun, 21 Feb 2010 04:49:10 +0000

Should signals be used when a mediator simply needs to respond to a change in the model? I assume in order to do this the signal will need to be registered as a singleton using injector.mapSingleton(MySignal) as a Command is not needed in this use case.

Comment on Robotlegs, AS3-Signals and the SignalCommandMap Example by Jon Toland

Jon Toland — Sun, 21 Feb 2010 03:38:18 +0000

Your first proposition sounds interesting. In practice we (CommandMap too) should be calling IReflector#getClass. Till's implementation actually has the same bug but it's already fixed in Injector#injectInto so I'll file a bug and/or patch right away. I recently proposed CommandMap#executedCommand and wonder whether it could be modified to accommodate SignalCommandMap#routeSignalToCommand too:

https://gist.github.com/11597e33a30351a2e2ad

Could your second proposal work without explicit naming injections? Maybe Joel could implicitly name repeated types ordinally. Thus your Command would be like:

http://gist.github.com/310118

Comment on Robotlegs, AS3-Signals and the SignalCommandMap Example by sjhewitt

sjhewitt — Sat, 20 Feb 2010 15:54:20 +0000

I came across a small problem (caused by the use of the .constructor property) when trying to inject a ListCollectionView into a Command, so thought I'd write a post about the changes I made to SignalCommandMap to overcome it. Any thoughts are welcome!
http://blog.sjhewitt.co.uk/2010/02/robotlegs-an...

Comment on Robotlegs, AS3-Signals and the SignalCommandMap Example by Joel Hooks

Joel Hooks — Wed, 17 Feb 2010 03:25:15 +0000

it *is* kinda hidden in there, but at the same time I don't want they value type changed and it kicks a RTE quickly if a wrong type is passed.

Comment on Robotlegs, AS3-Signals and the SignalCommandMap Example by Will

Will — Wed, 17 Feb 2010 03:05:46 +0000

Wait… I get it… nevermind :/

Comment on Robotlegs, AS3-Signals and the SignalCommandMap Example by Will

Will — Wed, 17 Feb 2010 02:35:11 +0000

Shouldn't the constructor for AddFoodItemToOrder accept a Class as a parameter since you are calling the super's constructor with super(FoodType)?

Comment on Robotlegs, AS3-Signals and the SignalCommandMap Example by Joel Hooks

Joel Hooks — Tue, 16 Feb 2010 03:27:46 +0000

That would definitely be the way to go. Unfortunately until SwiftSuspenders and Robotlegs hit the next dot-release the IInjector API isn't there to accomplish it. It will be more robust in the near future.

Comment on Robotlegs, AS3-Signals and the SignalCommandMap Example by robpenner

robpenner — Tue, 16 Feb 2010 01:46:03 +0000

I fixed the SignalContext constructor issue here:
http://github.com/robertpenner/signals-extensio...

Comment on Robotlegs, AS3-Signals and the SignalCommandMap Example by Will

Will — Mon, 15 Feb 2010 23:43:30 +0000

When instantiating a custom class extended from SignalContext I am unable to pass the contextView & autoStartup parameters usually passable to a regular Context. I there a reason for this?