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
1  Announcements and General Discussion / General Discussion / Re: execute() method of MacroCommand on: May 16, 2010, 11:04:34
If the execute method were protected instead of final, then the likelihood of it being misused by not calling super is pretty high. You can always have the last command in the macro send the note that says it has completed.
But that is the least usage path given that no one typically overrides the `execute` method. All normal usages of MacroCommand override the `initializeMacroCommand` method. Regarding the last command part, like already mentioned, writing a Command class which has a single sendNotification() call seems pretty wrong IMO. Also, there are a couple of other classes in the framework in which not calling the super method anyways ends up screwing things. But those methods were still marked non-final, no? :)

I do understand that the MacroCommand class was created with a different motive in mind but allowing developers to extend on that would be great. Anyways, not a big deal IMO, I just wanted your take on the design decision. I'd now be creating my own version of MacroCommand which I previously didn't want to. :)

Regards,
sasuke
2  Announcements and General Discussion / General Discussion / Re: execute() method of MacroCommand on: May 13, 2010, 10:19:48
Sorry, but the reasoning doesn't sound convincing in your case.

The MacroCommand does execute logic; the logic in this case being executing other commands. It is a specialized command provided as a convenience feature by the framework here. The primary purpose of this would be to help developers re-use existing commands and promote the creation of re-usable commands. But why forbid developers from extending this "handy" class? Why forbid extension?

One of the major points chalked against PureMVC by the users is the exponential explosion of classes when it comes to using the framework for executing a use case. Creating a command just for sending a single notification really can't be justified.

Anyways, Cliff, thoughts?

TIA,
sasuke
3  Announcements and General Discussion / General Discussion / execute() method of MacroCommand on: May 12, 2010, 09:41:13
Hi,

Is there any reasoning behind why the `execute` method of the MacroCommand is marked `final`? I've at times found the need to override the `execute` method to execute sub-commands *along* with executing some additional functionality. Something along these lines:

:
class MyCommand extends MacroCommand
{
override protected function initializeMacroCommand( ) : void
{
addSubCommand(FirstCommand);
addSubCommand(SecondCommand);
addSubCommand(ThirdCommand);
}

override public function execute(notification:INotification):void
{
super.execute();
sendNotification(COMPLEX_INITIALIZATION_COMPLETE);
}
}

In the absence of the above setup, I'd have to do something like:
:
class MyCommand extends MacroCommand
{
override protected function initializeMacroCommand( ) : void
{
addSubCommand(FirstCommand);
addSubCommand(SecondCommand);
addSubCommand(ThirdCommand);
addSubCommand(ComplexInitializationCompleteCommand);
}
}

public class ComplexInitializationCompleteCommand extends Command
{
    override public function execute(notification:INotification):void
    {
        sendNotification(COMPLEX_INITIALIZATION_COMPLETE);
    }
}

Thoughts?
4  Announcements and General Discussion / General Discussion / Re: When to remove a Mediator for a view on: May 12, 2010, 09:08:02
Just what I was thinking; thanks for the confirmation Cliff. :)
5  Announcements and General Discussion / General Discussion / Re: When to remove a Mediator for a view on: May 04, 2010, 10:53:03
You can easily have the mediator not respond to the note if the view component isn't shown.
How? By checking the 'visible' property of the viewComponent before handling a notification in handleNotification? How would the above scheme deal with UI components which utilize a timer to continuously send out events to the mediator?
6  Announcements and General Discussion / General Discussion / Re: Mediator registration for viewstack views on: May 04, 2010, 10:50:26
The demo looks interesting, thanks. :)
7  Announcements and General Discussion / General Discussion / Mediator registration for viewstack views on: May 01, 2010, 01:32:40
Hi,

My module which has a facade of its own (ModuleFacade) looks something like this:

:
<mx:Module>
  <mx:ViewStack creationPolicy="auto">
    <mx:View1 />
    <mx:View2 />
  </mx:ViewStack>
</mx:Module>

The page loads, the facade is kicked in action, the module mediator is registered, the module mediator receives the confirmation, another command is fired to register the View1, the mediator for view1 is registered and the control reaches the view1 mediator from the registration command. All this works fine. The problem comes when the user switches view. Since the creation policy of my view stack is auto (can't create all views at once), the view2 mediator registration happens before the view2 has been completely created and this results in an error when I try to access my view2 components after the startup command for the view2 completes.

I can attach a creationComplete event listener to the view2 and make the listener function look up the facade, send the notification to the module mediator which in turn would pick up view2 and send it for registration. But this doesn't seem like a very good approach, I mean referring/lookingup facade in each and every view instead of just the main view. Is there any other approach I can use to tackle this problem or is this the only choice?

TIA,
sasuke
8  Announcements and General Discussion / General Discussion / Re: When to remove a Mediator for a view on: April 30, 2010, 11:09:34
Removing a mediator sometimes becomes necessary when you have views which share a set of common notifications which they listen to. Imagine a viewstack having two distinct views (view A & view B) which end up listening to a common notification from a proxy. If view A is not visible to the client, it makes little sense to keep its mediator alive and respond to notifications given out by proxies, commands etc.

Another option here would be to deactivate your mediator as soon as the view becomes inactive. For e.g. as soon as view A is swapped out of the viewstack to show view B, you can set the `active` flag of mediator A to false. Any notifications/events received get tested against this flag and action is taken only when the mediator has the active flag set to true. The problem I see with this approach is that there is a certain amount of boilerplate code involved when it comes to making this work (testing for liveness/activeness).

Maybe Cliff would be able to shed a bit more light on this one. Cliff?

-sasuke
9  Announcements and General Discussion / Architecture / Re: Q:Flash Tracking using multiple vendors on: November 21, 2009, 12:08:44
> My question is will there be a problem with simultaneous navigateToURL calls, or will I need to implement
> some sort of que system, to stack these calls?

Given that Flash runtime is single threaded, your *simultaneous* calls are not so simultaneous and are anyways scheduled for the single running thread. The only difference would be in the former case you let the flash runtime decide the order whereas in the latter case, you explicitly decide on the order.

> I think simplicity dictates that I just have one tracking proxy with multiple navigateToURL calls for the
> different vendors.

Yes, having a single proxy is the way to go IMO. To make things more flexible, you can kinda implement a registration functionality for your tracking proxy wherein you can register `n' number of trackers at runtime and each call to the tracking proxy will in turn delegate the call to your registered trackers. This is similar to the way in which a notification request sent to the Facade is communicated to all the observers for that Facade.

HTH,
sasuke
10  Announcements and General Discussion / Architecture / Re: Handler classes for mediators on: November 16, 2009, 11:01:19
Having read this thread http://forums.puremvc.org/index.php?topic=1524.0 I realized that I was trying to solve the wrong problem here. Rather than going by the SRP and striving for separation of concerns, I was just shifting the burden from mediators to handlers.

Thanks for the replies Cliff & others. :)

-sasuke
11  Announcements and General Discussion / Architecture / Handler classes for mediators on: November 11, 2009, 11:28:29
Hi all.

When creating mediators for complicated views, the handleNotification method quickly gets out of hand and becomes overly complex when dealing with a bunch of notifications. Would it be a good idea to introduce the concept of handler classes for mediators which lead to even more cohesion [i.e. the handler responsible for handling notifications as opposed to Mediators]. Something along the lines of:

:
public interface IHandler
{
        function handle(notification:INotification);
}

public class NotificationHandler implements IHandler
{
protected var viewComponent:Object;

public function NotificationHandler(viewComponent:Object)
{
super();
this.viewComponent = viewComponent;
}

public function handle(notification:INotification):void
{
// Do nothing, just a base class for other handler classes
}
}

public class BaseMediator extends Mediator
{
protected var handler:IHandler;

override public function handleNotification(notification:INotification):void
{
// If the control reaches here means that the implementing
// class has not overidden the handleNotification funciton.
// Try to handle the notification if the IHandler is set
// otherwise just do a NO-OP
if(handler)
{
handler.handle(notification);
}
}
}

public class MyModuleHandler extends NotificationHandler
{
override public function handle(notification:INotification):void
{
// do something interesting here with the notifications
}
}

public class MyMediator extends BaseMediator
{
public static const FIRST_NOTIFICATION:String = 'FIRST_NOTIFICATION';

public static const SECOND_NOTIFICATION:String = 'SECOND_NOTIFICATION';

public function MyMediator(mediatorName:String=null, viewComponent:Object=null)
{
super(mediatorName, viewComponent);
}

override public function onRegister():void
{
handler = new MyModuleHandler(viewComponent);
}

override public function listNotificationInterests():Array
{
return [
FIRST_NOTIFICATION,
SECOND_NOTIFICATION
];
}
}

What do you guys think? If not this, then what else can be done to remedy the above scenario?

TIA,
sasuke
12  Announcements and General Discussion / Architecture / Why not emulate Events? on: October 24, 2009, 12:29:28
Hi all,

I was wondering as to why the concept of Notifications[publish/subscribe model] was used to implement async event handling? I mean, isn't it possible to actually emulate the Event handling framework already present in Flex,Java and provide a thin portable wrapper around them?

I did hear a while back that Cliff had some issues/complaints with the way event handling worked in AS3 and other languages and wanted to implement some other scheme. I'd like to hear as to what really went wrong with events and what architectural decisions/points were taken into consideration before going with Notification and not Events. Links/Articles/other references purporting the point would be awesome. :)

TIA,
sasuke
13  Announcements and General Discussion / Getting Started / Re: Is it ok for Proxies to gather information from other Proxies on: October 24, 2009, 12:24:49
Cool, I'll keep that in mind; thanks for the explanation. :)
14  Announcements and General Discussion / Getting Started / Re: Is it ok for Proxies to gather information from other Proxies on: October 23, 2009, 12:00:13
Oh, so you are saying that it's OK to expose dependencies between models/coupling between models when required instead of trying to hide it by involving the view in between. I thought according to the MVC paradigm, it was OK for the View or the Controller to modify/influence the model tier?
15  Announcements and General Discussion / Architecture / Re: Sharing proxy between cores on: October 23, 2009, 11:35:13
Thank you for all the suggestions, the link you posted was really interesting. :)
Pages: [1] 2