Does this still hold true if the component is just the filter control container?  Meaning the filter component does not contain the datagrid, but visually sits above it.  The reason for this is the filter might be used with s:List, mx:datagrid, etc....

So I am thinking in the filterComp I would give it reference via a property some dataProvider of external s:List or mx:Datagrid (ArrayCollection) then when run assign a filter to that DP.

Do you think having the component clone or copy the dataProvider filtering it then dispatching an event the mediator listen for then have the mediator assign the cloned filtered data (arrayCollection) as the new dataProvider?  Keeping a backup of the original in the mediator of course?

We have a PureMVC based app and we are creating a filtering component, like Apples Finder filter, and I am wondering where to put the filtering code?  I first put filtering function in the mediator, but when we decided to make the component a reusable component that breaks down as now we have duplicate filtering code in several mediators.

Has anyone done this or does anyone have any suggestions?

The issue seems to be a bug in Flex 4 or in my head. The issue is I have a docked ApplicationControlBar, which should always be in top of the display list, but it isn't.  I have added some new popups and such, which end up showing over top the ApplicationControlBar.  These popups and things are shown based on notifications so for a shortcut to get past the release I planned on just reordering the displayList each time a notification is sent.

Guess I will just listen to all the notifications and do the long way.  Thanks for the quick response.

J

So my stageMediator does some special things and I need it to hear all/every notification that is sent out.  Is there an easy way to do this?  So I don't have to type in all the notification interests in the listNotificationInterests Array?

Sorry about urgency, but a release is going out and requirements have changed and I don't have time to fix the code so just need to the stageMediator to hear everything.

TIA, J

If I create a mediator via registerMediator or create a proxy with registerProxy and I call the same function twice will I get two of each or will it grab both mediator and proxy that already exist?

TIA, J

Cliff, I want to say thank you again for making my job so much easier.  The next release of the map should be out by December 12th, 2009.  Its already getting some press PCMag  http://www.pcmag.com/article2/0,2817,2357031,00.asp.

You can read about some of the details here. http://www.flairjax.com/?p=78

Thanks again Cliff!!!

Jason

Or would I create an INodeState object and an editNodeState and editViewState objects put those in my nodeMediator. Then just pass all clicks off to what is current State object.

TIA, J

@Cliff, one more question.

Lets say you have an app that has two modes Edit and View. No tools this time. And lets say you are using the state machine.

Your app has a containerSprite, a nodeSprite and a lineSprite. When a click happens on a nodeSprite some of the click logic is in the nodeSprite, but some of the logic (for changing things) is in the containerSprite, like adding a Transformtool (resize, rotate, scale, etc...) to container which targets the nodeSprite. See senocular transformtool.

Example:
So if the app is in View mode, when a node receives a mouseclick it is highlighted with border and makes a popup show over it with information. In Edit mode things are different, a mouseclick causes the tranform tool to show up and nothing else happens.

So knowing this, where would the state object go? Would you create a IStateNodeMediator and then a viewStateNodeMediator and an editStateNodeMediator (concrete classes) or would you create a InodeSprite and viewNodeSprite and editNodeSprite (concrete classes).

And since the transform tool logic is in the containerSprite Would you create a IconatinerSpriteMediator and then a viewContainerMediator and an editContainerMediator (concrete classes) or would you create a IContainerSprite and viewContainerSprite and editContainerSprite (concrete classes).

Thanks, Jason

Ok, thanks.

When you say "they just do things differently" are you saying as I have asked above that they would dispatch the different click events, which the mediator would sen out different notifications?

Right now in my app, I have eventlisteners on my sprites, these sprites when clicked dispatch events that the mediator gets and the mediator makes changes to the sprites and then send out a notification saying what was changed or simply that a node was clicked (so other thing like menus can change).

But if continue down this path with the new tools, when switching of tools happens it would change the application state. But, then i would need to create state objects (like your ITool, as Gang of Four State Pattern says, for the sprites, menus, callouts, etc...), correct? Then anytime I introduce a new component, sprite class, or other type of class to my project they each would need a new state for each type of tool I create, correct?

I guess with the MegaCursor/SystemManager way I was hoping to prevent what I mentioned in the last paragraph; several types of state objects for each Class.

That is what I was thinking but then when a mouse click happens would not then have to send the mouse click event to my ApplicationMediator for it to send a notification of a click or in my case I have sprites allover the stage, so a Sprite would hear the click > send an event > SpriteMediator would then decide what to do with the event based on which state the app was in (aka another state object or if/switch) which I would rather not have unless I am missing something?

Is it possible to use the SystemManager or Cursor manager to catch the click or doubleclick or drag event from the cursor itself then the cursor sends out an event say "FingerCursorEvent" and the CursorMediator, which handles all events from all curors, would then dispatch the appropriate notification "ApplicationFacade.FINGERCURSORCLICK" or "ApplicationFacade.SELECTCURSOREVENT" if the select-tool was picked.

So
fingermouse's click = open thing clicked
zoommouse's click = zoom in 25%
mousepointer click = select to transform
pointer with a + on it = add a new thing to stage
ponter with a - on it = sub a new thing from stage

I guess this all hinges on if the SystemManager can catch the mouse event or if the cursormanager can catch it first?

I haven't looked at the StateMachine, but I assume that wouldn't require me conditional statements similar in theory to this?

if(State == Edit){
  handle singleclick one way....
}else  if(State == View){
 handle singleclick another way
}

So I have an app that will have, in the near term two modes, edit and view mode, but could have 3 or 4 more modes in the future.  Really not sure if modes is the correct term, think Photoshop or Illustrator.

The user can click a tool and do certain things in my app so with a hand tool a click might mean to open an object; view mode.

In edit mode, that same click will could be something like add an object.

I am wondering how this fits into Puremvc?  I would rather not put messy conditional logic in giant mediators, so would it be better to create dual mediators? Or is there another way?

My app is huge (think upwards of 1000 UIComponents) and takes some time to start up to render everything, so I don't really want to use the multicore and open a second version of my app for editing.

What are my options?

What about making the mouse pointer/tool be "ALL MIGHTY"?

Think photoshop.

What I mean by almighty is, when you select a tool, the toolmediator recognizes the switch and updates the toolproxy to change the tool value. Then the tool would send out different toolEvents based on its state (aka what kind of tool it is) the toolMediator would thus send out notifications based on the type of toolEvent it receives?

See any downsides to this? 

TIA, Jason

Cliff, sent you the images.

J