Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought

Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Show Posts

* | |

  Show Posts
Pages: [1] 2 3 4
1  Announcements and General Discussion / General Discussion / Re: Datagrid filtering component. Where should the filtering code go? on: April 06, 2011, 01:20:49
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.
2  Announcements and General Discussion / General Discussion / Re: Datagrid filtering component. Where should the filtering code go? on: April 06, 2011, 07:27:59
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?

3  Announcements and General Discussion / General Discussion / Datagrid filtering component. Where should the filtering code go? on: April 06, 2011, 07:08:45
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?
4  Announcements and General Discussion / General Discussion / Re: URGENT: How can I get the mediator to listen to all Notifications. on: July 15, 2010, 02:36:56
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.

5  Announcements and General Discussion / General Discussion / URGENT: How can I get the mediator to listen to all Notifications. on: July 15, 2010, 11:27:08
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.

6  Announcements and General Discussion / General Discussion / Registering new mediators (duplicate?) on: March 04, 2010, 09:18:10
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?

7  Announcements and General Discussion / Public Demos, Tools and Applications / New PureMVC based Network Map (Spiceworks 4.5) on: December 11, 2009, 09:19:29
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!!!

8  Announcements and General Discussion / Architecture / Re: Modes on: September 21, 2009, 09:06:56
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.

9  Announcements and General Discussion / Architecture / Re: Modes on: September 21, 2009, 08:40:54
@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.

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

10  Announcements and General Discussion / Architecture / Re: Modes on: September 21, 2009, 07:03:47
Ok, thanks.
11  Announcements and General Discussion / Architecture / Re: Modes on: September 20, 2009, 12:04:26
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.

12  Announcements and General Discussion / Architecture / Re: Modes on: September 19, 2009, 07:06:18
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.

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?
13  Announcements and General Discussion / Architecture / Re: Modes on: September 17, 2009, 02:10:22
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

14  Announcements and General Discussion / Architecture / Modes on: September 17, 2009, 07:01:24
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
15  Announcements and General Discussion / Public Demos, Tools and Applications / Re: Flex Gumbo && IT Network Map with PureMVC on: July 09, 2009, 11:39:41
Cliff, sent you the images.

Pages: [1] 2 3 4