flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: Squiggly Oddness
Date Wed, 27 May 2015 16:20:02 GMT
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 <aharui@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.lists@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.lists@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message