Hi Josh,
For the addedToStage stuff:
You made me look! Swiz does not actually use the ADDED event, it definitely
does use ADDED_TO_STAGE by default, but you're absolutely right, this does
not bubble.
I did not pay too much attention to the 'bubbling' side of things because I
could see it working in flash and just assumed that's what was happening.
But it is actually being listened to as a capture phase event. And that
does give the same outward impression (without looking too closely) as if
it were bubbling in this case.
I even resorted to a quick test in Adobe Animate to verify:
import flash.display.Sprite;
import flash.events.Event;
var sprite:Sprite = new Sprite();
sprite.name ='1';
function onAdded(event:Event):void{
trace('added' ,event.target.name)
}
function onRemoved(event:Event):void{
trace('removed' ,event.target.name)
}
sprite.addEventListener(Event.ADDED_TO_STAGE, onAdded, true);
sprite.addEventListener(Event.REMOVED_FROM_STAGE, onRemoved, true);
var sprite2:Sprite = new Sprite();
sprite2.name = '2'
var sprite3:Sprite = new Sprite();
sprite3.name = '3'
addChild(sprite);
sprite.addChild(sprite2)
sprite2.addChild(sprite3);
//remove the child tree
sprite.removeChild(sprite2)
/*
trace output:
added 2
added 3
removed 2
removed 3
*/
So I updated the stage events emulator to support this. 'removedFromStage'
now also works in capture phase on the strand that the bead is on for child
event targets that were removed.
In terms of the names of the events... that is quite easy to change. But
whatever we decide on, I just need to add as a COMPILE::JS variation to
the 'default' setupEventType/teardownEventType in the Config class for Crux
to account for what would now be a difference between SWF and JS (which is
fine by me, I only started with the same names by trying to match how
things worked in swf as they were). So far it does work the same between
swf and js builds, although there is only one simple example that builds
for both which I have tested with.
In terms of the name of the bead, also that can be whatever people think
makes sense. I put JS in the name because one of the builds works for both
swf and js. And seeing that a bead is for JS only is maybe helpful to
know.. although I have always wondered whether it would make sense to have
compiler switches in mxml - some sort of 'transparent' enclosing tag
similar to how a COMPILE::JS { code here } compile block works in
actionscript. I don't know it that makes sense.... something like that
could mean that the swf build does not get the unnecessary bead (which does
nothing in swf anyway)
Thanks heaps for the prompts on these things.
-Greg
On Fri, Jul 5, 2019 at 5:49 AM Carlos Rovira <carlosrov...@apache.org>
wrote:
> Hi Andrew,
>
> good point! That's without doubt another new point to bring to :
>
> - Royale-docs: We can follow most of the documentation available here [1]
> - Examples: In this case I don't see a Tour app since the use cases are
> very direct and can be exposed in few examples.
> Greg already provide 3 examples that shows all the things currently
> developed here [2]. I think we'll need to do soon a blog example
> covering Crux too that could be one of those or a new one. For example TODO
> List example would be a good one to apply Crux ;)
>
> [1] https://swizframework.jira.com/wiki/spaces/SWIZ/overview
> [2] https://github.com/apache/royale-asjs/tree/feature/Crux/examples/crux
>
> So many work there too to make it all avaialble to Apache Royale users as
> easy as possible ;)
>
>
>
> El jue., 4 jul. 2019 a las 18:46, Andrew Wetmore (<cottag...@gmail.com>)
> escribió:
>
> > This is great.
> >
> > However, even with the original Swiz I found the documentation quite thin
> > and that it made a lot of assumptions about what a general developer
> might
> > know and need to know. This site [1] made an attempt about ten years ago
> to
> > improve on an intro to Swiz. What plans are in the works to not only
> > provide Crux, but make it welcoming and accessible? Tour de Crux??
> >
> > a
> >
> > [1] https://deshartman.wordpress.com/2010/02/07/first-swiz/
> >
> > On Thu, Jul 4, 2019 at 1:17 PM Josh Tynjala <joshtynj...@bowlerhat.dev>
> > wrote:
> >
> > > Cool stuff, Greg and Carlos!
> > >
> > > One concern: In Flash, the "addedToStage" event does not bubble. It's
> > > actually the "added" event that bubbles and is used by frameworks like
> > > Swiz, Cairngorm, Robotlegs, etc.
> > >
> > > To avoid potential confusion for people migrating an existing app from
> > > Flex/Flash that might already listen for that event (and wouldn't
> expect
> > it
> > > to bubble), I'd recommend using a different name than "addedToStage".
> It
> > > could be "added", like Flash. Or it could even have a new name that's
> > > similar to "addedToStage", but is more relevant to Royale. Royale
> doesn't
> > > have a "stage", so that name feels a bit out of place to me anyway.
> Maybe
> > > "addedToApplication" or something like that.
> > >
> > > - Josh
> > >
> > >
> > > On Wed, Jul 3, 2019, 11:11 PM Greg Dove <greg.d...@gmail.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > Just a quick advance notice that we are getting something very
> similar
> > to
> > > > Swiz before too long.
> > > > There is a new branch called feature/Crux
> > > >
> > > > We can still explore other possible ways to incorporate Swiz code in
> > > Royale
> > > > (we have looked at having the code donated in the past), but for now
> at
> > > > least it is as a derivative work, differentiated by name as 'Crux'
> and
> > > > hence the name of the branch. 'Crux' means a main or pivotal point -
> > > > something important - and a common English expression that can
> express
> > > that
> > > > is when someone says ""the crux of the matter" - it means an
> important
> > > > thing to focus on.
> > > >
> > > > The name is what it is now - it is short and has a powerful meaning.
> > But
> > > > certainly we can review that too.
> > > >
> > > > The branch has the beginnings of the original Swiz functionality
> which
> > > > supports metadata driven Injection (including runtime Binding
> > Injection),
> > > > EventHandlers, main Dispatcher etc.
> > > > Those things are already shown in 3 examples [1] in examples/crux in
> > the
> > > > branch, (but I did not check the ant builds for those yet- I will get
> > to
> > > > that). Beyond those features, I have not ventured far yet, and
> perhaps
> > > some
> > > > of the others may not be relevant for Royale.
> > > >
> > > > In case it's useful elsewhere, there is also a new JSStageEvents
> > 'stage
> > > > events' simulator bead which works from the main application level,
> and
> > > > provides bubbling 'addedToStage' events which Crux listens to at the
> > top
> > > > level. These can be filtered (so not everything generates the events,
> > for
> > > > example). Not sure if that might be useful for other things, just
> > > > mentioning it for now... It does dispatch 'removedFromStage' as well,
> > but
> > > > too late for bubbling, so I will investigate if I can do something a
> > bit
> > > > sneaky to see if I can make that work. Otherwise it is always
> possible
> > to
> > > > add removedFromStage listeners directly to the target of interest
> > > inside
> > > > an 'addedToStage' listener.
> > > >
> > > > I expect there will be bugs, and I of course there will be many
> things
> > I
> > > > can continue to improve, so this is just an early announcement for
> your
> > > > awareness. Carlos sponsored a large chunk of my time on this, so you
> > have
> > > > him to thank for that, but I have also contributed a lot of my own
> > time,
> > > > and will continue to do so. Thanks also to Alex for recent guidance
> on
> > > > licencing issues, this was uncharted territory for me.
> > > >
> > > > Anyhow, Carlos will, I am sure, provide more info, he is very
> familiar
> > > with
> > > > Swiz from the past.
> > > >
> > > > -Greg
> > > >
> > > >
> > > > 1.
> > https://github.com/apache/royale-asjs/tree/feature/Crux/examples/crux
> > > >
> > >
> >
> >
> > --
> > Andrew Wetmore
> >
> > http://cottage14.blogspot.com/
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
