[Autowire] is broken using "includeIn" / "excludeFrom" (Flex 4)
sectore
unfortunately I haven't found any good workaround so far, neither any
feedback on this issue.
If a view component is added to stage for the first time, its
properties delcared as [Autowire] are wired pretty well. After that
and if a view is removed using Flex 4 state syntax "excludeFrom", all
[Autowire] properties are unwired. So far, so good.
But if any view is added again to the stage based on "includeIn", the
[Autowire] won't be executed. That means all binding to model data are
lost.
Here is an example (Swiz rev. 171 / Flex SDK 4.0.0.11566 / view source
code is enabled):
http://websector.de/playground/swiz/issue46/SwizIssue46Example.html
This issue based on the default event "preinitialize" for autowireing
beans and properties. Because after removing a view based on
"excludeFrom" and adding to stage again based on "includeIn" the
FlexGlobals.topLevelApplication (aka Swiz.systemManager) dispatches an
"addedToStage" event for this view, but not a "preinitialize" event
anymore.
My workaround is to use "addedToStage" as an "injectionEvent" (via
SwizConfig). Unfortunately most of views need its model data asap and
before "addedToStage".
Any other workarounds?
P.S.: All issues mentioned above posted on issue 46 (comments 8 + 9)
http://code.google.com/p/swizframework/issues/detail?id=46#c8
Thanks!
-Jens
Ben Clinkinbeard
I don't know how much we can really do about this. If the component is
added and removed to the stage repeatedly, as you pointed out, the
only event that will notify us each time is addedToStage. I am open to
suggestions but we are more or less at the mercy of the player and
Flex framework. How would you see this working in an ideal situation?
Thanks,
Ben
Brian Kotek
--
You received this message because you are subscribed to the Google Groups "Swiz Framework" group.
To post to this group, send email to swiz-fr...@googlegroups.com.
To unsubscribe from this group, send email to swiz-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/swiz-framework?hl=.
sectore
I have had some time to think over it and I think there is no need for
any change. Because using "addedToStage" works fine. And from a Flex
component lifecycle view, "addedToStage" is dispatched before a the
lifecycle of a component starts. That means "addedToStage" is
dispatched before "preinitialize", "initialize" and all the other
"lifecycle" events are dispatched. So my personal quote "Unfortunately
most of views need its model data asap and before "addedToStage" is
wrong, because all needed model data are already there - as soon as
possible!
Just using "addedToStage" as an default injection event for Swiz
should be fine.
Thanks!
-Jens
--
http://www.websector.de
Ben Clinkinbeard
I think we need to do some research into that event order. In Flex 3,
if I am remembering correctly, the order of events for normal views
added to stage is preinit, init, creationComplete, addedToStage. For
views added to PopUpManager though, addedToStage was fired first then
the rest in the same order. I haven't used Flex 4 yet but am wondering
if the default order has changed, or maybe it has something to do with
using states?
Will put this on our list to investigate, unless you'd like to report
back some more detailed findings. :)
Thanks,
Ben
Brian Kotek
sectore
The event order is changed only if a view uses a state attribute
"includeIn" / "excludeFrom" and it is not added at the "default"
state. The same as Ben mentioned for the PopupManager in Flex 3. All
other views has its "normal" event order like in Flex 3:
"preinitialize", "initialize", "creationComplete", "updateComplete",
"addedToStage".
-Jens
sectore
UIComponent has some interesting changes of dispatching events, such
as FlexEvent.PREINITIALIZE, FlexEvent.INITIALIZE or
FlexEvent.CREATION_COMPLETE. These events will be dispatched only if
these events have any listeners.
For example: Check UIComponent.as, line 7243:
if (hasEventListener(FlexEvent.PREINITIALIZE))
dispatchEvent(new FlexEvent(FlexEvent.PREINITIALIZE));
So if a view component has not an event handler for
"preinitialize" (which is by default), it won't be autowired by
default.
As mentioned above using "addedToStage" as a default injection event
for Swiz works fine furthermore. Anyway, Flex 4 is still beta and I
guess it won't be the final changes... ;)
P.S.: Great news about Swiz 1.0 - Swiz team, you rock!
-Jens
Ben Clinkinbeard
Ben
Chris Scott
-c
--
You received this message because you are subscribed to the Google Groups "Swiz Framework" group.
To post to this group, send email to swiz-fr...@googlegroups.com.
To unsubscribe from this group, send email to swiz-framewor...@googlegroups.com.
Ben Clinkinbeard
happens even before PREINITIALIZE, and its not suppressed by these
changes because it is intrinsic to the player. Will be investigating
it as a potential replacement soon.
Ben
On Dec 16, 6:10 pm, Chris Scott <chris.scott....@gmail.com> wrote:
> Jesus, that's a potential major pain. Nice going flex sdk team!
>
> -c
>
> On Wed, Dec 16, 2009 at 3:03 PM, Ben Clinkinbeard <
>
> > swiz-framewor...@googlegroups.com<swiz-framework%2Bunsu...@googlegroups.com>
gabriel
On Dec 17, 8:19 pm, Ben Clinkinbeard <ben.clinkinbe...@gmail.com>
wrote:
> There may actually be a decent fix for this. Turns out the ADDED event
> happens even before PREINITIALIZE, and its not suppressed by these
> changes because it is intrinsic to the player. Will be investigating
> it as a potential replacement soon.
>
Do remember that PREINITIALIZE and INITIALIZE, even in flex 3, happen
only
once in the life of a component, even if it's dettached and re-
attached
(either by states or by hand).
When Flex instantiates the components it sets its properties but holds
off the
rest of the lifecycle events (in the broad sense of things that
happen) until
the component has been attached to the display list. When a component
is
attached, a framework method, "initialize" will itself cause the
dispatch of
PREINITIALIZE, will run createChildren, and then will indirectly
dispatch
INITIALIZE (by calling another method called
"initializationComplete"). And
that's it for those events.
Likewise, CREATION_COMPLETE will only be dispatched once the
initialized
property has been set on the component by the flex framework. And
this will
only happen after the first round of validation has been completed
successfuly. That is, until commitProperties, measure and
updateDisplayList,
etc. have been run enough times (hopefully not that many!) so that
all the
invalidation flags have been cleared. Again, this will only happen
once for
each component.
My question would be, then, why would the components be unwired when
they
are removed from the display list?
Thanks,
Gabriel
Ben Clinkinbeard
for our purposes. The good news though, is that it sounds like I may
have gotten them to reconsider the quashing of the startup events. If
you'd like to lend your support to the cause be sure to drop a comment
at http://bugs.adobe.com/jira/browse/SDK-24249
> My question would be, then, why would the components be unwired when
> they are removed from the display list?
Because traditionally that has signaled the end of their life and been
a good place to clean up references to allow for GC. With the rise of
states in Flex 4 I think we'll need to add some sort of flag to turn
off the unwiring in response to display list removal.
Ben