Thanks, that makes sense. I just didn't know if it was OK to leave that pipe hanging there.
-erik

So I read the whole thread on disconnecting pipes but still didn't find what I was looking for. Here is what I am currently doing:

:

//remove the pipe
var shellJunction:Junction = QueryMessage(message).getBody() as Junction;

//disconnect the input pipe
var pipeIn:Pipe = junction.retrievePipe(PipeAwareModule.SHELL_IN) as Pipe;
var shellOut:TeeSplit = shellJunction.retrievePipe(PipeAwareModule.STD_OUT) as TeeSplit;
shellOut.disconnectFitting(pipeIn);

So this disconnects the pipe coming out of the shell into the module. I wanted to also disconnect the pipe for traffic out of the module to the shell but the TeeMerge on the shell doesn't have a "disconnectFitting" method. It only has a "disconnect" method. How do I go about disconnecting the module input pipe from the shell without disconnecting all other input pipes to the shell?

Thanks Cliff, that clears a lot up!

This may just be that I am still a little confused of the difference in what is application and view states. I am trying to control a tabnavigator with the FSM. I don't know of a good way to do this besides catching the index change event, canceling it, and then if it successfully transitions to the next state I will set the tab navigator to the new index. Is there a better way to do this?

How would you define the difference between view state and application state? I have a simple user admin panel I decided to test the FSM utility out on. It has two tabs; one is for searching users and the other for creating new users. From the searching tab you can deactivate/activate/edit a user. If deactivating/activating you stay on the same page and are alerted to the outcome of the db call. If you edit you are sent to the create page and the form is pre-populated. Submitting changes to a user or creating a user will take you back to the search page.

The issue I'm running into is that a user can hit a tab in the tab navigator while the application is in the "STATE_DELETE" state or something and the view will progress but the fsm wont because it is waiting on a response from the server.

Here is my simplified FSM XML:

:

<fsm initial={INITIAL_STATE}>
<state name={STATE_SEARCH} changed={CHANGED_SEARCH}>
<transition action={ACTION_CREATE} target={STATE_CREATE} />
<transition action={ACTION_EDIT} target={STATE_EDIT} />
</state>
<state name={STATE_CREATE} changed={CHANGED_CREATE}>
<transition action={ACTION_CREATE_SAVE} target={STATE_CREATE_SAVE} />
<transition action={ACTION_GO_TO_SEARCH} target={STATE_SEARCH} />
</state>
<state name={STATE_CREATE_SAVE} changed={CHANGED_CREATE_SAVE}>
<transition action={ACTION_CREATE_SAVE_SUCCESSFUL} target={STATE_SEARCH} />
<transition action={ACTION_CREATE_SAVE_FAILED} target={STATE_CREATE_TRY_AGAIN} />
</state>
<state name={STATE_CREATE_TRY_AGAIN} changed={CHANGED_CREATE_TRY_AGAIN}>
<transition action={ACTION_CREATE_RETRY_YES} target={STATE_CREATE_SAVE} />
<transition action={ACTION_RETRY_NO} target={STATE_SEARCH} />
</state>
<state name={STATE_DELETE} changed={CHANGED_DELETE}>
<transition action={ACTION_DELETE_SUCCESSFUL} target={STATE_SEARCH} />
<transition action={ACTION_DELETE_FAILED} target={STATE_SEARCH} />
</state>
</fsm>

Is this a proper use of this utility or should the utility be used in a less granular way?

Couldn't get the timer to work, maybe because it is in a command. But I used an asynchronous DB call and it fixed the issue.

The original DB call wasn't asynchronous because I was just running it on the flex side and hacking things in the proxy. When I am done it will be asynchronous so I probably wont hit this issue.

Is the issue that the state change event type is being set by reference rather than by value?

So I have two commands listening on most every FSM notification. One is basically a logging command that keeps FSM history and listens on all actions, changes, and cancels. The other is the one that does all the work. I ran into some unexpected behavior with this. Here is the scenario:

1. Mediator fires off an notification with FSM Action #1.
2. Logging Command picks it up and Action #1 and logs it.
3. Working Command picks up the corresponding CHANGED event (Changed #1) from the FSM and it does its work (not asynchronously).
4. The Working Command's work causes a state change and fires off Action #2.
5. Logging Command picks up Action #2 and logs it.
6. Logging Command picks up Change #2 and logs it.
7. Logging Command picks up Change #2 and logs it.

It looks like step 7 should be handling the changed event from step 1. I am assuming that since the state changed in the FSM again before the first CHANGED event finished propagating that it pulled the current state. But I thought that the original event would maintain the integrity of its type variable. Is that variable somehow still bound to the FSM's original current state variable?

If I comment out the code that does the work and in turn fires off the Action #2 this is what happens:
1. Mediator fires off an notification with FSM Action #1.
2. Logging Command picks it up and Action #1 and logs it.
3. Logging Command picks up Change #1 and logs it.

Also, I could probably get rid of this logging thing if I knew a way to get the current state at will rather than storing the state each time a CHANGED event is fired off. Is there a way to do this?

Currently this isn't an issue for me, it is just unexpected behavior.

Not that I'm challenging what you said, but I'm curious why I shouldn't make the data requests before the mediator is created? I check in the onRegister method of the mediator if the data requests were fulfilled before it was created and then I get the retrieved data from the proxy accordingly. It takes a bit more code but it seems like it should be more efficient. Is it that the efficiency is negligible and isn't worth the extra code? I have to write an extra command for each view now and extra logic to handle calling both.

Thanks! I was confused as to what should be handled in the FSM and was trying to handle both the view and application states I think.

Yeah, I realized I was doing things wrong. I needed the ability to create and destroy items in a view stack and was using module loaders to do that. I found a better way. Thanks.

Generally, I render the view component, then call its command on CREATION_COMPLETE. The command first initializes the mediator and then the proxy and calls the methods on the proxy to get the required data. I initialize the mediator first so that it can catch the responses from the proxy. I make sure the view component is completely created so the mediator can set the data on it.

I find this to be acceptable in most situations but on some more complex pages I find that my page loads with empty fields and then they get populated because the view rendered and then the proxy got its data. I would prefer that when I go to a "new page/tab" that the first thing that happens is that the proxy registers and starts the asynchronous calls to the service layer/db. While I am waiting for a reply, the view component can get rendered and then the mediator created. When the mediator is created it will set all the data on the view component from the proxy. The mediator will still have its listeners on the proxy to set the data if it comes in after the mediator is created.

Is this the best way to do this? Its annoying to call the proxy prep command, then wait for the view to hit CREATION_COMPLETE, and then call the view prep command. I also have to write extra code in the mediator to initially set the proxy data that came in before its creation.

I'm just fishing for better ways to do this!

So I would like to be able to define sub-FSMs, for lack of a better term. Here is an example for why:

Say I have an application that has a menu with items/states A, B, and C. I select item B and I now am brought to a complex form with states X, Y, and Z. If the main menu is still accessible then I could be half way through the form and change to item C. I would want state B to be able to respond to this rather than having states X, Y, and Z be able to handle it. That would make things a lot simpler. Is this possible without having separate cores that have separate FSMs? Can I make a hierarchical FSM?

I'm new to using this utility and may be missing something.

I have it working now by using an interface for the module view component. The interface has to have a method for accessing everything in the view the mediator should have access to. Please someone tell me there is a better way?

Is there a way to include the classes used by a module in that module even if the view doesn't reference them? If so, I am assuming that the main app should have no knowledge of the mediators, commands, and proxies that the module contains. Which would mean the module view component would have to initialize them...and probably have its own facade. Can you have a module that isn't a core, ie, doesn't have a facade, and still get around this issue without using interfaces?

So I ported my project from Flex 3 to Flex 4. I'm trying to simply load a module in an application and setup its mediator to use it. I keep getting this error:

TypeError: Error #1009: Cannot access a property or method of a null object reference.
   at mx.core::UIComponent/getStyle()[E:\dev\4.0.0\frameworks\projects\framework\src\mx\core\UIComponent.as:10372]
   at spark.components::Label/createTextLinesFromTextBlock()[E:\dev\4.0.0\frameworks\projects\spark\src\spark\components\Label.as:831]
   at spark.components::Label/createTextLines()[E:\dev\4.0.0\frameworks\projects\spark\src\spark\components\Label.as:808]
   at spark.components::Label/http://www.adobe.com/2006/flex/mx/internal::composeTextLines()[E:\dev\4.0.0\frameworks\projects\spark\src\spark\components\Label.as:474]
   at spark.components.supportClasses::TextBase/measure()[E:\dev\4.0.0\frameworks\projects\spark\src\spark\components\supportClasses\TextBase.as:533]
   at mx.core::UIComponent/measureSizes()[E:\dev\4.0.0\frameworks\projects\framework\src\mx\core\UIComponent.as:8042]
   at mx.core::UIComponent/validateSize()[E:\dev\4.0.0\frameworks\projects\framework\src\mx\core\UIComponent.as:7966]
   at mx.managers::LayoutManager/validateSize()[E:\dev\4.0.0\frameworks\projects\framework\src\mx\managers\LayoutManager.as:617]
   at mx.managers::LayoutManager/doPhasedInstantiation()[E:\dev\4.0.0\frameworks\projects\framework\src\mx\managers\LayoutManager.as:709]
   at mx.managers::LayoutManager/doPhasedInstantiationCallback()[E:\dev\4.0.0\frameworks\projects\framework\src\mx\managers\LayoutManager.as:1072]

I was reading on the adobe forum about this and they said in response to someones similar issue:
[http://forums.adobe.com/message/2792526#2792526]

The main point of modules is to make the main application SWF smaller.  When using modules you have to realize that any mention of a class in the application code links in those classes and all dependent classes.  We sort of assumed that folks knew that and have made changes to the styles system in Flex 4 that require that you know that.

And again, in reference to someones specific problem:

You are using the module class in the main app which sort of defeats the point of having a module as it will link testModule into the main app.  When that happens in Flex 4, the styles don't get set up properly.  You should use an interface instead of the module class.

The basic idea I gather is that you cant reference the module view component in any other code. Which brings me to a lot of problems and two questions:

1. Is that true?
2. If it is, how do I strongly type the view component in the mediator? Do I have to write an interface for every module?

Ok, I figured most of this out using SWFLoader. Got pipes working too after making a PipeAwareApp class and extending it on my sub-apps. Last thing to figure out is how to get the sub-app and main app to use the same RSLs. Bet that would speed up load time. Any ideas?

So, I've been trying to break my project down into multiple projects. So far I have one for the core, one for the library, and one for a group of modules, with more to come when I write the other modules.

I keep getting a "Type Coercion failed: cannot convert XXXXX to Application" when I try and load one of the groups of modules. I realize it is because what used to be a module should now be an application but isn't. How should these "groups of modules" be put in a project? If it is a standard flex project then it needs an application doesn't it? Or did you mean i should make a library project with it?

My ideal situation is that the shell can actually load stand alone applications into it like it can with modules. Is this possible? If so, can I talk to it with pipes? Also, if that app uses the same RSL as the main app, is there a way it can reference the same RSLs on the server when it deploys without being in the same folder?