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

Pages: [1]
Print
Author Topic: Alert prompt (with close handler) in a command?  (Read 8555 times)
JJfutbol
Sr. Member
****
Posts: 53


View Profile WWW Email
« on: September 24, 2008, 10:20:07 »

I know commands are good places to have common actions that need to happen from different views in your app. For example, if you display a pop up based on a keyboard event, a button click and even some other action, abstracting that repeated code into a command is useful. I have a situation where I'm building a desktop application where there is much more communication going on between components and am wondering if a command fits well with what I'm trying to do. Let me explain.

I have a List and AppControlBar component each with its own mediator. When an item is selected the AppControlBar is notified and has a tracker (variable) for that item. A "Delete" button is in the control bar (plus many other item-selected dependent actions) that displays an Alert prompt with Yes/No buttons. Pretty straightforward. The catch is that I've added a key down handler on the List component so if the user hits their DELETE key I want to trigger that same Alert prompt but that is defined within the AppControlBar MXML component.

Is this where I would take that block of code with the Alert prompt and move it into a command? Seems like an easy question but I'm not really used to knowing exactly when to use commands and when not too. My concern here is that the Alert needs a close handler and I know commands shouldn't have state. Would the code for the Alert prompt still go in a command?

Suggestions/Thoughts?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: September 24, 2008, 02:49:19 »

Go back through the 'Recent posts' link at the front page of the forums. I'm on a wap browser or I'd link you direct. Anyway just a yesterday I think I answered a post about handling popups. Simon at nutrixinteractive has a good Popmanager construct for this.

-=Cliff>
Logged
JJfutbol
Sr. Member
****
Posts: 53


View Profile WWW Email
« Reply #2 on: September 24, 2008, 03:05:38 »

@Cliff,

Always can count on a reply from you. :) Don't know how you do it! My problem though is that this is just a simple Alert. No need for an MXML popup, although I will be saving and using that PopManager technique for when I do!

Maybe I should use that approach with a unique class, AlertManager, but it doesn't take a mediator. Say... pass it a notification for each of the different alert options (yes/no,etc.)?? Or only the ones you need.

If I add a anonymous function to the Alert.show() call within a command, does that command still have state? I'm wondering if by defining the function even anonymously (inline with the show() call) still creates state in the command? It just seems so natural to put this into command rather than elsewhere.

Thoughts?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: September 25, 2008, 05:03:52 »

Creating and passing the anonymous function won't give state to your Command, it should go away as soon as executed.

But then what will that function do when called? It won't have Facade access to send a Notification. Seems like you actually need to pass a reference to a method on the Command itself, which can take action based on the yes/no/cancel response. The Command is living a little longer than normal, but it isn't actually keeping state. That is, it isn't relying on values from previous executions.

The Alert will be modal, so nothing else can happen until you answer it so I don't think its as problematic as making Commands responders to service calls (which can't be cancelled once sent since you can't retrieve an executed but 'waiting' Command).

-=Cliff>
Logged
Pages: [1]
Print