FWIW, I solved my specific issue by using an index instead of a reference to
the controller, and I always resolve the controller using
flowComposer.getControllerAt(_flowIndex);
As for the why:
Squiggly replaces the standard ContainerController with a
SquigglyCustomContainerController (which extends ContainerController) with a
signature like this:
public function
SquigglyCustomContainerController(container:Sprite,textHighlighter:IHighlighter,
wordProcessor:IWordProcessor, engine:SpellingService,
func:Function,
compositionWidth:Number=100,compositionHeight:Number=100)
I believe the primary reason is to support the context menu.
I was thinking about this some more, and I’m thinking that there should be an
ISpellingController and Squiggly should only replace the controller if the
existing controller is not a ISpellingController. That would allow clients to
add their own ISpellingControllers which would not be replaced.
If there’s some way to inject the context menu and take care of the other four
components (IHighlighter, IWordProcessor, SpellingService and the
ignoreWordFunctionProcessor), that might be best.
On May 27, 2015, at 5:54 PM, Alex Harui <aha...@adobe.com> wrote:
> I haven’t looked at the code at all, but maybe it would be worth trying to
> figure out “why” Squiggly replaces the controller. I would imagine it is
> to get certain events so it knows when to run its spell checker and/or
> injecting the squiggly decoration. Having the controller dispatch the
> right events and providing a hook to inject decorations might be a better
> approach so Squiggly doesn’t have to be so invasive.
>
> -Alex
>
> On 5/27/15, 3:23 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>> One idea which could solve problem #1 would be to add a method
>> IFlowComposer.replaceController() which would dispatch an event with the
>> old controller and the new one.
>>
>> But, this doe not solve problem #2. There must be some way of solving
>> this using composition…
>>
>> On May 27, 2015, at 1:18 PM, Harbs <harbs.li...@gmail.com> wrote:
>>
>>> When loading Squiggly, it modifies the controllers in the FlowComposer
>>> and swaps out the existing controllers with
>>> SquigglyCustomContainerControllers.
>>>
>>> This is problematic:
>>> 1) There’s no way to track ContainerControllers while using Squiggly.
>>> Any tracked ContainerControllers become unused. (I currently have this
>>> problem. I have some code which tracks threading across containers.)
>>> 2) If someone subclasses ContainerController for some reason, their
>>> code blows up.
>>>
>>> Any suggestions on how to solve this problem?
>>>
>>> Harbs
>>
>
