Dispatcher is null when loading a popup from a module.

[Codeflayer]

Hi guys,

We're trying to implement swiz in a rather large project. For the most
part everything has worked great and the mailing list has been a big
help in getting around some of the module related issues with events.
The problem we are trying to solve right now is loading a popup from a
module in the main app. It all works great except the dispatcher is
null.

I will try and explain this in snippets:

The module has the following function that creates the popup:
public function createNewTab():void {

PopUpManager.addPopUp(newTabModal,FlexGlobals.topLevelApplication.parentDocument,true,null,moduleFactory);
PopUpManager.centerPopUp(newTabModal);
}

The NewTabModal declares the dispatcher like so:

[Dispatcher]
public var dispatcher:IEventDispatcher;

Then calls it in this function:

private function okHandler(event:MouseEvent=null):void{
var tabEvent:TabEvent = new TabEvent(TabEvent.CREATE);
tabEvent.name=tabname.text;
tabEvent.id=UIDUtil.createUID();
dispatcher.dispatchEvent(tabEvent);
closeWindow();
}


Stepping through the code in the debugger, when the app calls the
okHandler function, the dispatcher is null.

Any advice would be most appreciated.

[Brian Kotek]

Two questions: what version of Swiz are you using, and are you certain that the PopUp class is in one of the viewPackages that you have defined?

--
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=en.

[Codeflayer]

I'm using Swiz 1.0.0 RC2

Yes, the view package that contains the popup is defined in the main
app swizconfig and in the module swiz config.

On Sep 14, 1:07 pm, Brian Kotek <brian...@gmail.com> wrote:
> Two questions: what version of Swiz are you using, and are you certain that
> the PopUp class is in one of the viewPackages that you have defined?
>

> > swiz-framewor...@googlegroups.com<swiz-framework%2Bunsu...@googlegroups.com>
> > .

[Codeflayer]

Interesting workaround:
If I set the dispatcher when opening the modal it works just fine.

[Brian Kotek]

Well I would think that this should work ok if you're only injecting a dispatcher, but there are definitely complications if a module creates a pop up that depends on beans defined in the module. That is because Flex does not add pop ups to the display list, but instead adds them to the SystemManager. As a result, when Swiz is notified that a pop up has been added, there is no reliable way to determine which Swiz instance should process it. Swiz currently falls back to using the root Swiz instance when it cannot locate the display object in the display list of one of the Swiz instances. That means that if the pop up is depending on having beans injected that were defined in another Swiz instance (not the root), those beans can't be found (since they're not in the root's bean factory).

The team has gone back and forth on this a number of times, and we're still thinking about ways we might try to deal with this, but currently, the approach I would recommend that each Swiz instance that needs to process pop ups should define a bean that is ISwizAware to act as the factory for your pop ups. You can then inject this pop up factory anywhere you need to create a pop up, and this factory will create it and have the correct Swiz instance process it. Under RC2, I'm using a class like this, see if using something like this helps:

package org.swizframework.moduleexample.util

{

import flash.display.DisplayObject;

import flash.events.Event;

import mx.core.IFlexDisplayObject;

import mx.core.IFlexModuleFactory;

import mx.managers.PopUpManager;

import org.swizframework.core.ISwiz;

import org.swizframework.core.ISwizAware;

/**

* This class will create PopUps that are processed by the specified Swiz instance.

* It should be useful for PopUps created in Modules, to ensure that the correct Swiz

* processes the PopUp.

*/ 

public class SwizAwarePopUpManager implements ISwizAware

{

private var _swiz : ISwiz;

public function set swiz( swiz : ISwiz ) : void

{

_swiz = swiz;

}

public function addPopUp( window : IFlexDisplayObject, parent : DisplayObject, modal : Boolean = false, childList : String = null, moduleFactory : IFlexModuleFactory = null ) : void

{

window.addEventListener( Event.REMOVED_FROM_STAGE, onPopUpRemove );

PopUpManager.addPopUp( window, parent, modal, childList, moduleFactory );

PopUpManager.centerPopUp( window );

_swiz.beanFactory.setUpBean( _swiz.beanFactory.createBeanFromSource( window ) );

}

private function onPopUpRemove( event : Event ) : void

{

IFlexDisplayObject( event.target ).removeEventListener( Event.REMOVED_FROM_STAGE, onPopUpRemove );

_swiz.beanFactory.tearDownBean( _swiz.beanFactory.createBeanFromSource( event.target ) );

}

}

}

To unsubscribe from this group, send email to swiz-framewor...@googlegroups.com.

[Codeflayer]

Thanks for the reply. I've been reading the mail list for a couple of
months now and know that this is a headache for you guys. I will give
your class a shot and see if that alleviates the issues we've been
having.

Thanks again, and keep up the great work!

> > <swiz-framework%2Bunsu...@googlegroups.com<swiz-framework%252Buns...@googlegroups.com>

[Codeflayer]

Hi guys,

We implemented SwizAwarePopUpManager and this resolved the
[Dispatcher] issue and we are able to do injects in the top level
popup. Our next issue is propagating this down to child components
that use injects within the popup. Right now we are just creating the
injects on the popup container and binding those to the sub
components. Is there a way to propagate to the sub components
automatically? We'd thought of just looping through the subcomponents
using getElement but I'm not convinced this is an elegant solution.

Thanks!

[Codeflayer]

Hi guys,

I'm not sure if my previous comment went through so if this is a dupe
I apologize in advance.

We've implemented the SwizAwarePopupManager. This has taken care of
the dispatcher and injects being null and points the popup to the
right bean. Our next issue is how to tackle propagating this to the
child components of the popup. Is there a recommended way of doing
this? We'd thought of just looping through the children but this
didn't seem very elegant.

Thanks,

[Michael Harper]

Hi, I would be interested in this solution too. I've temporarily stopped using modules to speed up development because it was wasting a lot of time. In my case I'm doing a personal project. I couldn't conceive of approaching a large project for a client without this being resolved.

Rest of Swiz is great btw.

Mike

To unsubscribe from this group, send email to swiz-framewor...@googlegroups.com.

[Brian Kotek]

Well to be clear, the module stuff works fine. The problem is when you have modules that create PopUps that need to be wired. And the problem is really a Flex issue, primarily their decision to place PopUps outside the display list that every other display object lives within. Which sucks, because so much of the power of Swiz is that it handles the processing of all the other display objects automatically. Since that seems to go out the window when it comes to PopUps, particularly complex ones with multiple children, we may be stuck having to come up with some manual way to relate them to their target Swiz instance.

[Codeflayer]

Hi Brian,

I get where your coming from. It really is too bad that Adobe went the
route they did with popup management. Although they probably didn't
think this would be an issue either. Right now I'm looking into making
complex popup content into their own modules to see if that gets
around the issue with nested insert calls. I will reply with my
results.

On Sep 15, 12:45 pm, Brian Kotek <brian...@gmail.com> wrote:
> Well to be clear, the module stuff works fine. The problem is when you have
> modules that create PopUps that need to be wired. And the problem is really
> a Flex issue, primarily their decision to place PopUps outside the display
> list that every other display object lives within. Which sucks, because so
> much of the power of Swiz is that it handles the processing of all the other
> display objects automatically. Since that seems to go out the window when it
> comes to PopUps, particularly complex ones with multiple children, we may be
> stuck having to come up with some manual way to relate them to their target
> Swiz instance.
>
> On Wed, Sep 15, 2010 at 2:10 PM, Michael Harper <ctd...@gmail.com> wrote:
> > Hi, I would be interested in this solution too. I've temporarily stopped
> > using modules to speed up development because it was wasting a lot of time.
> > In my case I'm doing a personal project. I couldn't conceive of approaching
> > a large project for a client without this being resolved.
>
> > Rest of Swiz is great btw.
>
> > Mike
>

> >> > > > <swiz-framework%2Bunsu...@googlegroups.com<swiz-framework%252Buns...@googlegroups.com>
> >> <swiz-framework%252Buns...@googlegroups.com<swiz-framework%25252Bun...@googlegroups.com>

> ...
>
> read more »

[Michael Harper]

Hi Brian,

Yes your correct modules work great actually it's just the popups as you say. However, I'm led to believe that Parsley has this solved which begs a question. I'll find out if they have an report back.

Mike

[Brian Kotek]

They've solved it by making you do it manually, which is exactly what we're trying to avoid. But like I said, there may not be another way, unfortunately.

Brian

[Michael Harper]

Aha I see. 

[ben.clin...@gmail.com]

Just so I am clear, the problem you are having is you want to inject a bean that is defined within a child Swiz instance into a pop up or a descendant of a pop up, correct?

The original title of this thread implies that [Dispatcher] is not being injected at all, which should never be the case. The way things stand right now, the only injections available to pop ups and their descendants are beans defined within the root Swiz instance. I wouldn't expect this to be a huge or common issue, because it can be solved either by manually supplying dependencies or by defining the necessary beans in the root Swiz instance.

If anyone has a compelling argument about why neither of those solutions is adequate, please provide it so we can discuss/evaluate potential solutions.

Thanks,
Ben

[Codeflayer]

Hi Ben,

The way we'd begun architecture our application was to have a main
application that consisted of tabs that would load modules based on
the tab the user selected. Since each of the sections of our app is
fairly large this seemed like the best approach. We wanted to be able
to develop each module separately so each module would have it's own
swiz to provide that module's wiring. Additionally the main
application would host models that could be used across all parts of
the application. The issue we ran into was that the beans defined in
the modules were not being populated when that module created a popup
window that injected the beans. Any bean access done through a popup
generated by a module seems to break. This is where the null
dispatcher issue was also happening.

This was partially solved by using Brian's SwizAwarePopUpManager since
it pointed the pop-up to the correct bean config, but didn't solve the
problem of getting the beans injected into sub-components of the
module. Since the sub-components didn't get the beans injected, the
workaround would be to inject the beans at the top level of the pop-up
and then manually set the child component values. Obviously this is
not ideal for complex pop-ups with several levels of nested
components.

So the desire would be to have give the developer the ability to
define different bean configs for each module that will work if the
developer wants to also generate complex popups from within the
modules.

This gets even more complicated since part of what we want to do is
call modules from within modules in the pop-ups (we haven't actually
tried this yet) essentially to be able to have n number of child
modules have access to the appropriate swiz beans.

I'm curious if at this point it would be easier to create a custom
PopUp manager that didn't assign the popup outside the display list.


On Sep 15, 6:47 pm, "ben.clinkinbe...@gmail.com"

<ben.clinkinbe...@gmail.com> wrote:
> Just so I am clear, the problem you are having is you want to inject a bean
> that is defined within a child Swiz instance into a pop up or a descendant
> of a pop up, correct?
>
> The original title of this thread implies that [Dispatcher] is not being
> injected at all, which should never be the case. The way things stand right
> now, the only injections available to pop ups and their descendants are
> beans defined within the root Swiz instance. I wouldn't expect this to be a
> huge or common issue, because it can be solved either by manually supplying
> dependencies or by defining the necessary beans in the root Swiz instance.
>
> If anyone has a compelling argument about why neither of those solutions is
> adequate, please provide it so we can discuss/evaluate potential solutions.
>
> Thanks,
> Ben
>
> On Wed, Sep 15, 2010 at 6:20 PM, Michael Harper <ctd...@gmail.com> wrote:
> > Aha I see.
>

> > On Wed, Sep 15, 2010 at 10:08 PM, Brian Kotek <brian...@gmail.com> wrote:
>
> >> They've solved it by making you do it manually, which is exactly what
> >> we're trying to avoid. But like I said, there may not be another way,
> >> unfortunately.
>
> >> Brian
>
> >> On Wed, Sep 15, 2010 at 4:12 PM, Michael Harper <ctd...@gmail.com> wrote:
>
> >>> Hi Brian,
>
> >>> Yes your correct modules work great actually it's just the popups as you
> >>> say. However, I'm led to believe that Parsley has this solved which begs a
> >>> question. I'll find out if they have an report back.
>
> >>> Mike
>
> >>>  --
> >> 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<swiz-framework%2Bunsu...@googlegroups.com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/swiz-framework?hl=en.
>
> >  --
> > 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<swiz-framework%2Bunsu...@googlegroups.com>
> > .

[ben.clin...@gmail.com]

So you are saying you can't even inject shared models defined in the root into pop ups within a module?

Ben

> To unsubscribe from this group, send email to swiz-framewor...@googlegroups.com.

[Michael Harper]

Hi Ben,

Possibly the reason this has become a bit of an irritation is the inordinate amount of time (bearing in mind that like others I was trying to learn Swiz at the same time) not understanding why the injections of child instance beans into PopUps weren't working in the first place. This leads me to believe there should be some section in the documentation that simply says 'Warning Injections into child swiz instance in module popups does not work because of Adobe architecture issues'. If you don't know about to begin with and then spend heaps of time on it you begin to feel the framework itself is unreliable and that's the last thing you need. After all we have enough difficulty with our own incompetence without it being added to by side issues :-) So a good first step might be own up clearly on the documentation site.

That being said I don't understand why Adobe and now the frameworks see popups as second class citizens. I have a modular application in which one module is using gantt charts that have intensive data entry in popups (floating and updating as the user moves around the gantt chart (no I can't hide the gantt chart every time the user wants some detail). Also if your restricted to 1024 * 768 screen resolution as you are in many cases then you have to use popup windows. In that scenario the framework is only used 50% of the time which isn't great.

For the most part (and I would argue all) the child module functionality should be self contained for clarity for the same reasons we are using a framework to start with so I can't see a good argument for moving module popup beans into the parent application either, especially since providers of modules may be different companies. Even when you have control over the code I don't believe shared libraries are a replacement for modules either.

In summary I think Modules and PopUps are a much bigger issue than it seems to be and it will/has to be solved cleanly by somebody, perhaps Adobe are keen on on this as well?

Mike

[Codeflayer]

To answer your question Ben: Yes you can inject beans defined in the
root application into popups spawned by modules. You can also inject
beans defined in the module into popups spawned by the module using
something like Brian's SwizAware class but if that popup is complex,
the child components do not have access to the beans. If you try to
create a popup that loads a module the module has access to the beans
defined in the module but not beans defined in the main app.

As a side note, I took my own advice and started working on a Popup
manager replacement. I created a Group component that is defined in
the bean config and added it to the top level application. Then I can
call that bean to add and remove popups. It's not as nice as the Popup
manager (considering I only worked on it a few hours) but it does
resolve the display list issue that the standard PopupManager
presents. Below is the code I've come up with so far:

The Popup canvas:

<?xml version="1.0" encoding="utf-8"?>
<s:Group xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx" width="100%"
height="100%">
<fx:Declarations>

</fx:Declarations>
<s:states>
<s:State name="normal"/>
<s:State name="modal"/>
</s:states>
<fx:Script>
<![CDATA[
import mx.containers.TitleWindow;
import mx.core.IVisualElement;
public function addPopup(window:IVisualElement,
modal:Boolean):void{
this.addElement(window);
this.currentState = modal?"modal":"normal";

}
public function centerPopup(window:IVisualElement):void{
window.x = (this.width/2)-(window.width/2);
window.y = (this.height/2)-(window.height/2);
}
public function removePopup(window:IVisualElement):void{

}
]]>
</fx:Script>
<s:Rect top="0" bottom="0" left="0" right="0" includeIn="modal">
<s:fill>
<s:SolidColor color="0xffffff" alpha="0.5" />
</s:fill>
</s:Rect>
</s:Group>

Injecting it into the main app:

[Inject]
public var swizPopupCanvas:SwizPopupCanvas;
[PostConstruct]
public function addPopupCanvas():void{
this.addElement(swizPopupCanvas);
}

calling it from another part of the app:

swizPopupCanvas.addPopup(testModal,true);
swizPopupCanvas.centerPopup(testModal);

As you can see I still need to work out removing the popup and making
the popup draggable but I'm hopeful that this will be a good
workaround.

> On Thu, Sep 16, 2010 at 1:47 AM, ben.clinkinbe...@gmail.com <

>
> ben.clinkinbe...@gmail.com> wrote:
> > Just so I am clear, the problem you are having is you want to inject a bean
> > that is defined within a child Swiz instance into a pop up or a descendant
> > of a pop up, correct?
>
> > The original title of this thread implies that [Dispatcher] is not being
> > injected at all, which should never be the case. The way things stand right
> > now, the only injections available to pop ups and their descendants are
> > beans defined within the root Swiz instance. I wouldn't expect this to be a
> > huge or common issue, because it can be solved either by manually supplying
> > dependencies or by defining the necessary beans in the root Swiz instance.
>
> > If anyone has a compelling argument about why neither of those solutions is
> > adequate, please provide it so we can discuss/evaluate potential solutions.
>
> > Thanks,
> > Ben
>
> > On Wed, Sep 15, 2010 at 6:20 PM, Michael Harper <ctd...@gmail.com> wrote:
>
> >> Aha I see.
>

> >> On Wed, Sep 15, 2010 at 10:08 PM, Brian Kotek <brian...@gmail.com> wrote:
>
> >>> They've solved it by making you do it manually, which is exactly what
> >>> we're trying to avoid. But like I said, there may not be another way,
> >>> unfortunately.
>
> >>> Brian
>
> >>> On Wed, Sep 15, 2010 at 4:12 PM, Michael Harper <ctd...@gmail.com>wrote:
>
> >>>> Hi Brian,
>
> >>>> Yes your correct modules work great actually it's just the popups as you
> >>>> say. However, I'm led to believe that Parsley has this solved which begs a
> >>>> question. I'll find out if they have an report back.
>
> >>>> Mike
>
> >>>>  --
> >>> 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<swiz-framework%2Bunsu...@googlegroups.com>
> >>> .

> >>> For more options, visit this group at
> >>>http://groups.google.com/group/swiz-framework?hl=en.
>
> >>  --
> >> 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<swiz-framework%2Bunsu...@googlegroups.com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/swiz-framework?hl=en.
>
> >  --
> > 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<swiz-framework%2Bunsu...@googlegroups.com>
> > .

[Michael Harper]

Sounds like a direction that could work

To unsubscribe from this group, send email to swiz-framewor...@googlegroups.com.

[ben.clin...@gmail.com]

Hi Mike,

You are correct that this should be called out in the documentation. The reason it is not yet is simply because we found out about the problem fairly recently and have been debating solutions ever since. If there is not a solution in place by the time 1.0 final is released we will definitely document it.

That being said, I would definitely disagree with your statement that anyone "has to" use pop up windows. I don't think I have ever worked on a project whose screen dimension requirements were greater than 1024 x 768 and I very rarely use pop ups. That is primarily a UX/design issue, but I try to avoid all of Flex's manager classes whenever possible. I've simply not had good experiences with any of them.

This use case is obviously more common that we had anticipated, so we'll need to solve it one way or another. I will notify the list when we have a solution or proposal in place.

Thanks,
Ben

[Michael Harper]

Hi Ben,

Yes 'have to' was a bit strong. My reason for using PopUps rather than designing the background screen differently is an attempt at improving the user experience. I'm not entirely sure I was successful I don't like the idea of not being able to do use them cleanly.

As a side note, I've had to read up on Parsley for a contract I'm doing and they seem to have this nailed, yes it's partly manual in a trivial sense, although you can sidestep the manual part by using a new feature in v 2.3. (8.8 in the documentation - Declarative PopUps)

Thanks

Mike

[ben.clin...@gmail.com]

Quick question: Would it be problematic to require that pop ups who contain their own Swiz instance be created "manually" and passed into addPopUp(), rather than letting PopUpManager actually instantiate them via createPopUp()?

Ben

[Codeflayer]

I'm not sure what you mean Ben. I've only used addPopUp and
instantiate the Popup somewhere in the panel that needs it. I'm not
sure this is the best way to go but that's what I've been doing. My
question is how you would propagate the beans down to child components
of the popup?

On Sep 16, 8:02 am, "ben.clinkinbe...@gmail.com"

<ben.clinkinbe...@gmail.com> wrote:
> Quick question: Would it be problematic to require that pop ups who contain
> their own Swiz instance be created "manually" and passed into addPopUp(),
> rather than letting PopUpManager actually instantiate them via
> createPopUp()?
>
> Ben
>
> On Thu, Sep 16, 2010 at 9:50 AM, Michael Harper <ctd...@gmail.com> wrote:
> > Hi Ben,
>
> > Yes 'have to' was a bit strong. My reason for using PopUps rather than
> > designing the background screen differently is an attempt at improving the
> > user experience. I'm not entirely sure I was successful I don't like the
> > idea of not being able to do use them cleanly.
>
> > As a side note, I've had to read up on Parsley for a contract I'm doing and
> > they seem to have this nailed, yes it's partly manual in a trivial sense,
> > although you can sidestep the manual part by using a new feature in v 2.3.
> > (8.8 in the documentation - Declarative PopUps)
>
> > Thanks
>
> > Mike
>

> >>> On Thu, Sep 16, 2010 at 1:47 AM, ben.clinkinbe...@gmail.com <
> >>> ben.clinkinbe...@gmail.com> wrote:
>
> >>>> Just so I am clear, the problem you are having is you want to inject a
> >>>> bean that is defined within a child Swiz instance into a pop up or a
> >>>> descendant of a pop up, correct?
>
> >>>> The original title of this thread implies that [Dispatcher] is not being
> >>>> injected at all, which should never be the case. The way things stand right
> >>>> now, the only injections available to pop ups and their descendants are
> >>>> beans defined within the root Swiz instance. I wouldn't expect this to be a
> >>>> huge or common issue, because it can be solved either by manually supplying
> >>>> dependencies or by defining the necessary beans in the root Swiz instance.
>
> >>>> If anyone has a compelling argument about why neither of those solutions
> >>>> is adequate, please provide it so we can discuss/evaluate potential
> >>>> solutions.
>
> >>>> Thanks,
> >>>> Ben
>
> >>>> On Wed, Sep 15, 2010 at 6:20 PM, Michael Harper <ctd...@gmail.com>wrote:
>
> >>>>> Aha I see.
>

> >>>>> On Wed, Sep 15, 2010 at 10:08 PM, Brian Kotek <brian...@gmail.com>wrote:
>
> >>>>>> They've solved it by making you do it manually, which is exactly what
> >>>>>> we're trying to avoid. But like I said, there may not be another way,
> >>>>>> unfortunately.
>
> >>>>>> Brian
>
> >>>>>> On Wed, Sep 15, 2010 at 4:12 PM, Michael Harper <ctd...@gmail.com>wrote:
>
> >>>>>>> Hi Brian,
>
> >>>>>>> Yes your correct modules work great actually it's just the popups as
> >>>>>>> you say. However, I'm led to believe that Parsley has this solved which begs
> >>>>>>> a question. I'll find out if they have an report back.
>
> >>>>>>> Mike
>
> >>>>>>>  --
> >>>>>> 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<swiz-framework%2Bunsu...@googlegroups.com>
> >>>>>> .

> >>>>>> For more options, visit this group at
> >>>>>>http://groups.google.com/group/swiz-framework?hl=en.
>
> >>>>>  --
> >>>>> 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<swiz-framework%2Bunsu...@googlegroups.com>
> >>>>> .

> >>>>> For more options, visit this group at
> >>>>>http://groups.google.com/group/swiz-framework?hl=en.
>
> >>>>  --
> >>>> 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<swiz-framework%2Bunsu...@googlegroups.com>
> >>>> .

> >>>> For more options, visit this group at
> >>>>http://groups.google.com/group/swiz-framework?hl=en.
>
> >>>  --
> >>> 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<swiz-framework%2Bunsu...@googlegroups.com>
> >>> .

> >>> For more options, visit this group at
> >>>http://groups.google.com/group/swiz-framework?hl=en.
>
> >>  --
> >> 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<swiz-framework%2Bunsu...@googlegroups.com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/swiz-framework?hl=en.
>
> >  --
> > 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<swiz-framework%2Bunsu...@googlegroups.com>
> > .

[ben.clin...@gmail.com]

Everything would work seamlessly, as expected in any other part of an application. I think this solution will work, I may have something to share as soon as tomorrow.

Thanks,
Ben

To unsubscribe from this group, send email to swiz-framewor...@googlegroups.com.

[Michael Harper]

Will look forward to it

Cheers,

Mike

[Codeflayer]

Update on my progress with my custom SwizPopupManager

This seems to be working really well. I am able to access beans from
all bean providers. My test has a popup (handled by the
SwizPopupManager) that loads a module. This module is able to access
its bean provider and the parent's bean provider. The module in turn
loads a grandchild module. The grandchild module is able to access its
bean provider, the parent module's bean provider and the main app's
bean provider. I think this will work for our needs. The only drawback
to my approach is that the popups loaded by the SwizPopupManager have
to handle their own dragging whereas the the Flex PopupManager
automatically handles this.

The next test is to see if the grandchild module can create a popup
with all the same access and then test to see if module's nested
components can access the bean providers.

On Sep 16, 9:11 am, "ben.clinkinbe...@gmail.com"

<ben.clinkinbe...@gmail.com> wrote:
> Everything would work seamlessly, as expected in any other part of an
> application. I think this solution will work, I may have something to share
> as soon as tomorrow.
>
> Thanks,
> Ben
>

> > <swiz-framework%2Bunsu...@googlegroups.com<swiz-framework%252Buns...@googlegroups.com>

>
> > > >>>>>> .
> > > >>>>>> For more options, visit this group at
> > > >>>>>>http://groups.google.com/group/swiz-framework?hl=en.
>
> > > >>>>>  --
> > > >>>>> 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<swiz-framework%2Bunsu...@googlegroups.com>

> > <swiz-framework%2Bunsu...@googlegroups.com<swiz-framework%252Buns...@googlegroups.com>

>
> > > >>>>> .
> > > >>>>> For more options, visit this group at
> > > >>>>>http://groups.google.com/group/swiz-framework?hl=en.
>
> > > >>>>  --
> > > >>>> 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<swiz-framework%2Bunsu...@googlegroups.com>

> > <swiz-framework%2Bunsu...@googlegroups.com<swiz-framework%252Buns...@googlegroups.com>

>
> > > >>>> .
> > > >>>> For more options, visit this group at
> > > >>>>http://groups.google.com/group/swiz-framework?hl=en.
>
> > > >>>  --
> > > >>> 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<swiz-framework%2Bunsu...@googlegroups.com>

> > <swiz-framework%2Bunsu...@googlegroups.com<swiz-framework%252Buns...@googlegroups.com>

>
> > > >>> .
> > > >>> For more options, visit this group at
> > > >>>http://groups.google.com/group/swiz-framework?hl=en.
>
> > > >>  --
> > > >> 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<swiz-framework%2Bunsu...@googlegroups.com>

> > <swiz-framework%2Bunsu...@googlegroups.com<swiz-framework%252Buns...@googlegroups.com>

>
> > > >> .
> > > >> For more options, visit this group at
>

> ...
>
> read more »

[ben.clin...@gmail.com]

As it turns out, (most of) the solution has been in place and under our noses the whole time. The ISwiz interface, which Swiz implements, includes a method with the following signature: registerWindow( window:IEventDispatcher, windowSwiz:ISwiz = null ):void;. This method was initially created for use with NativeWindows in AIR, because like pop ups, they exist outside of the main display list of your application. Therefore, it also works perfectly for pop up windows.

Now, some detail and background on registerWindow(). You can see that it's implementation is super simple here: http://github.com/swiz/swiz-framework/blob/v1.0.0-RC2/src/org/swizframework/core/Swiz.as#L230

Basically what it does is the following. You pass into it a "window" that you want Swiz to manage, including descendants of that window. If that window defines its own Swiz instance, like a Module or other major part of your app, you pass that Swiz instance as the second parameter. If you do not pass in a Swiz instance, one will be created for you, using the window passed in as the first parameter as the dispatcher. The Swiz instance on which you called registerWindow() is then set up to be the parentSwiz for the instance that was either created or passed in. Since child Swiz instances inherit beans and configuration, that is all that has to be done.

Using this system is as simple as this:

var p:Popper = new Popper();
mySwiz.registerWindow( p ); // THIS IS THE IMPORTANT LINE
PopUpManager.addPopUp( p, this, true );

That should solve every problem discussed in this thread. We did discover and fix an issue that was preventing child Swiz instances from being properly torn down, so that will be in the next release.

The only caveat is this: since establishing the necessary parent/child relationship requires a reference to the view instance, PopUpManager.createPopUp(), where you pass in the view class and the instance is created for you, won't really work. You could potentially do something like mySwiz.registerWindow( PopUpManager.createPopUp( this, MyViewClass ) ) since createPopUp() returns the view instance, but I don't think Swiz will be able to wire up things on stage by default in the pop up, because it won't be ready by the time they are added to the stage. This is simply going to be a fact of life.

Therefore, the disclaimer is as follows: Interacting with non-root Swiz instances from a pop up requires that the pop up be passed into the registerWindow() method of the non-root Swiz _before_ being added to the display list. Pop ups created with PopUpManager.createPopUp() may only interact with the root Swiz instance in an application.

Let me know if any of this is not clear, as I will be transferring most of it to the wiki soon.

Thanks,
Ben

To unsubscribe from this group, send email to swiz-framewor...@googlegroups.com.

[Michael Harper]

Great news, I'll give it a shot.

Thanks very much for dealing with this

Mike

[BrunoBG]

I do not believe an amicable solution, but solved the Dispached = NULL
registering to view the index / app.

registerClassAlias("viewVerba", br.com.Sisgeral.view.Verba);
registerClassAlias("viewView", br.com.Module1.view.View);

hug

--
****************************************************
www.brunobg.com
brun...@ig.com.br (MSN & Skype)
blogflex.brunobg.com
@brunogrohs
(21) 9913-2397



On Sep 16, 12:11 pm, "ben.clinkinbe...@gmail.com"

<ben.clinkinbe...@gmail.com> wrote:
> Everything would work seamlessly, as expected in any other part of an
> application. I think this solution will work, I may have something to share
> as soon as tomorrow.
>
> Thanks,
> Ben
>

> > <swiz-framework%2Bunsu...@googlegroups.com<swiz-framework%252Buns...@googlegroups.com>

>
> > > >>>>>> .
> > > >>>>>> For more options, visit this group at
> > > >>>>>>http://groups.google.com/group/swiz-framework?hl=en.
>
> > > >>>>>  --
> > > >>>>> 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<swiz-framework%2Bunsu...@googlegroups.com>

> > <swiz-framework%2Bunsu...@googlegroups.com<swiz-framework%252Buns...@googlegroups.com>

>
> > > >>>>> .
> > > >>>>> For more options, visit this group at
> > > >>>>>http://groups.google.com/group/swiz-framework?hl=en.
>
> > > >>>>  --
> > > >>>> 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<swiz-framework%2Bunsu...@googlegroups.com>

> > <swiz-framework%2Bunsu...@googlegroups.com<swiz-framework%252Buns...@googlegroups.com>

>
> > > >>>> .
> > > >>>> For more options, visit this group at
> > > >>>>http://groups.google.com/group/swiz-framework?hl=en.
>
> > > >>>  --
> > > >>> 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<swiz-framework%2Bunsu...@googlegroups.com>

> > <swiz-framework%2Bunsu...@googlegroups.com<swiz-framework%252Buns...@googlegroups.com>

>
> > > >>> .
> > > >>> For more options, visit this group at
> > > >>>http://groups.google.com/group/swiz-framework?hl=en.
>
> > > >>  --
> > > >> 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<swiz-framework%2Bunsu...@googlegroups.com>

> > <swiz-framework%2Bunsu...@googlegroups.com<swiz-framework%252Buns...@googlegroups.com>

>
> > > >> .
> > > >> For more options, visit this group at
>

> ...
>
> read more »

[jsawyer]

Ben,

Now that I need to code a call to a method on the Swiz instance, it
would be nice if the registerWindow() call was in the interface ISwiz,
so I could more easily mock out the call for testing.

Jon

On Sep 17, 8:18 am, "ben.clinkinbe...@gmail.com"

<ben.clinkinbe...@gmail.com> wrote:
> As it turns out, (most of) the solution has been in place and under our
> noses the whole time. The ISwiz interface, which Swiz implements, includes a
> method with the following signature: registerWindow(
> window:IEventDispatcher, windowSwiz:ISwiz = null ):void;. This method was
> initially created for use with NativeWindows in AIR, because like pop ups,
> they exist outside of the main display list of your application. Therefore,
> it also works perfectly for pop up windows.
>
> Now, some detail and background on registerWindow(). You can see that it's

> implementation is super simple here:http://github.com/swiz/swiz-framework/blob/v1.0.0-RC2/src/org/swizfra...

> ...
>
> read more »- Hide quoted text -
>
> - Show quoted text -

[Ben Clinkinbeard]

It is. https://github.com/swiz/swiz-framework/blob/master/src/org/swizframework/core/ISwiz.as#L115

> ...
>
> read more »

[jsawyer]

Oops. Time to update to RC2. Sorry.

Jon

On Nov 3, 6:51 pm, Ben Clinkinbeard <ben.clinkinbe...@gmail.com>
wrote:
> It is.https://github.com/swiz/swiz-framework/blob/master/src/org/swizframew...

[Gareth Arch]

Digging up this old thread, but just wondering how you would go about referencing your swiz instance from the code here (how you would get mySwiz into your page)

[Brian Kotek]

You can implement the ISwizAware interface.

On Wed, Apr 6, 2011 at 1:24 PM, Gareth Arch <lam...@gmail.com> wrote:

Digging up this old thread, but just wondering how you would go about referencing your swiz instance from the code here (how you would get mySwiz into your page)

--

[Gareth Arch]

That worked.  Thanks Brian.