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]
1  PureMVC Manifold / Bug Report / Re: [ BEING FIXED ] removeMediator not managing observer list properly on: December 10, 2007, 12:36:06
Why not a "i--" after the slice call ?
2  PureMVC Manifold / Bug Report / [ FIXED ] removeMediator not managing observer list properly on: December 07, 2007, 01:11:47
I think there is a bug in the View.removeMediator function.

When an element is removed from the Array with the 'splice' function, the next Observer in the Array is skipped because the 'i' counter is increased anyway.

Here is a reproduction of the bug ;

:
var vegetables:Array = new Array("spinach", "green pepper", "cilantro", "onion", "avocado");
for ( var i:int = 0;  i < vegetables.length; i++ ) {
    if ((vegetables[i] as String).indexOf("o") > -1) {
    trace(vegetables[i]);
        vegetables.splice(i,1);
        // i--;
    }
}

The result should be cilantro onion avocado but is cilantro avocado.
3  Announcements and General Discussion / Architecture / Re: Proxy and Business Delegate call on: November 19, 2007, 08:01:40
Yes, it works.
4  PureMVC Manifold / Bug Report / Re: [ DEFUSED ] Bug in View.notifyObservers() on: November 15, 2007, 06:50:03
but I'm not sure the framework needs to change because its possible to put it into a feedback loop.
I think that something must change : the ASDoc or the implementation... because the ASDoc saids :
All previously attached IObservers for this INotification's list are notified and are passed a reference to the <code>INotification</code> in the order in which they were registered.
and the implementation doesn't respect it.

Don't you agree ?
5  PureMVC Manifold / Bug Report / Re: [ DEFUSED ] Bug in View.notifyObservers() on: November 15, 2007, 01:39:00
I don't think you really understand what I mean...

Have a look at the notifyObserver() method in the View :

:
public function notifyObservers( notification:INotification ) : void
        {
            if( observerMap[ notification.getName() ] != null ) {
                var observers:Array = observerMap[ notification.getName() ] as Array;
                for (var i:Number = 0; i < observers.length; i++) {
                    var observer:IObserver = observers[ i ] as IObserver;
                    observer.notifyObserver( notification );
                }
            }
        }

If the line observer.notifyObserver( notification ); cause (in the observer) the creation and the registration of a mediator interested in the notification under process, the observer created by the registerMediator() function will be added in observerMap[ notification.getName() ] AND will be precessed in the current for loop because the test expression is observers.length that will dynamically change after the observer registration...

Instead you could use something like :
:
var observers:Array = observerMap[ notification.getName() ] as Array;
var stopIndex : int = observers.length;
for (var i:Number = 0; i < stopIndex; i++) {
6  PureMVC Manifold / Bug Report / [ DEFUSED ] Bug in View.notifyObservers() on: November 14, 2007, 03:32:47
I get a strange behavior when registering a mediator interested in a notification being processed by the View.notifyObservers() function.

I've a simple application that notify the observers of the application startup.

:
<?xml version="1.0" encoding="utf-8"?>
<mx:Application
creationComplete="handleCreationComplete()"
xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">

<mx:Script>
<![CDATA[
import org.puremvc.patterns.observer.Notification;

private function handleCreationComplete() : void {
// notify application startup...
ApplicationFacade.getInstance().notifyObservers(
new Notification(ApplicationFacade.STARTUP, this));
}

]]>
</mx:Script>
</mx:Application>

The ApplicationFacade assign the StartupCommand to the STARTUP notification.

:
package {

import org.puremvc.patterns.facade.Facade;
import org.puremvc.interfaces.IFacade;

public class ApplicationFacade extends Facade implements IFacade {

public static const STARTUP : String = "STARTUP";

public static function getInstance() : ApplicationFacade {
if (instance == null) { instance = new ApplicationFacade();}
return instance as ApplicationFacade;
}

override protected function initializeController() : void  {
super.initializeController();
registerCommand(STARTUP, StartupCommand);
}
}
}

The StartupCommand create & register a mediator...
:
package {

import org.puremvc.patterns.command.SimpleCommand;
import org.puremvc.interfaces.INotification;

public class StartupCommand extends SimpleCommand {

override public function execute(note : INotification) : void {
// initilize & register a mediator
facade.registerMediator(new TestMediator());
}
}
}

The mediator created is interested in the STARTUP notification...
:
package {

import org.puremvc.patterns.mediator.Mediator;
import org.puremvc.interfaces.INotification;

public class TestMediator extends Mediator {

override public function listNotificationInterests() : Array {
return [ApplicationFacade.STARTUP];
}

override public function handleNotification(note : INotification) : void {
switch (note.getName()) {
case ApplicationFacade.STARTUP:
trace("Bug !!!");
break;
}
}

override public function getMediatorName() : String {
return "TestMediator";
}
}
}

The "handleNotification" should be called if a new STARTUP notification is lunched... BUT it is called direcly after the mediator creation... (because the for loop in the View.notifyObservers is not yet completed)

That not what the asdoc said :
All previously attached <code>IObservers</code> for this <code>INotification</code>'s list are notified and are passed a reference to the <code>INotification</code> in the order in which they were registered.
7  Announcements and General Discussion / Architecture / Re: View composed of view on: October 10, 2007, 05:57:25
Correct me if I'm wrong :

The mainViewMediator is in fact the Application's Mediator. So it handle the creation of the remaining Mediators (the loginViewMediator in my case and the dynamically added views' mediators).
8  Announcements and General Discussion / Architecture / View composed of view on: October 10, 2007, 01:22:02
Hello,

I've an application composed of a 'main' view that display a login form at startup (this 'main' view has a mediator). Once the user is successfully identified, others views are dynamically added (function of user permissions) in the 'main view'.

Here is the code of the main view :
:
<?xml version="1.0" encoding="utf-8"?>
<mx:VBox
horizontalAlign="center"
verticalAlign="middle"
xmlns:mx="http://www.adobe.com/2006/mxml"
xmlns:login="org.sampleapps.flex.elibrary.view.login.*">

<mx:Script>
<![CDATA[
import org.sampleapps.flex.elibrary.model.vo.User;

/* ----- Constants ----- */

internal static const STATE_USER_NOT_IDENTIFIED : String = '';
internal static const STATE_USER_IDENTIFIED : String = 'STATE_USER_IDENTIFIED';

/* ----- Properties ----- */

[Bindable]
public var user : User;

]]>
</mx:Script>

<login:LoginView id="loginView"/>

<mx:states>
<mx:State name="STATE_USER_IDENTIFIED">
<!-- Remove the login panel -->
<mx:RemoveChild target="{loginView}"/>
<!-- Add a menu and the main content -->
<mx:AddChild position="lastChild">
<mx:VBox width="100%" height="100%">
<mx:ApplicationControlBar width="100%">
<mx:ToggleButtonBar height="100%"
dataProvider="{viewStack}" id="toggleButtonBar" />
<mx:Spacer width="100%"/>
<mx:Text text="Connected as {user.firstName} {user.lastName}"/>
</mx:ApplicationControlBar>
<mx:ViewStack width="100%" height="100%" creationPolicy="all" id="viewStack" />
</mx:VBox>
</mx:AddChild>
</mx:State>
</mx:states>

</mx:VBox>

Here are my questions :
  • whom should create the mediator of the loginView ? the startup command (that already create the mediator of the main view) or the mainViewMediator ?
  • whom should add and create the views and the mediators that will be added in the viewStack ?

Thank you.
9  Announcements and General Discussion / Architecture / Re: Proxy and Business Delegate call on: October 09, 2007, 08:50:34
Thank you.
10  Announcements and General Discussion / Architecture / Proxy and Business Delegate call on: October 09, 2007, 05:52:28
Hi there,

if a Proxy has more than one interaction with a business delegate (in charge of asynchronous service call), is there a 'nice' way to handle the response / fault ? 

I mean that if a Proxy implements 'IResponder' interface, there is only one result / fault function in charge of handling the result. If I want the send a "UserDeleted" notification after a successful "removeUser()" call and a "UserAdded" notification after a successful "addUser()" call, what is the best solution ?

Is there a best practice in this case ? Should I implement a Command that implements 'IResponder' in charge of calling the BusinessDelegate and updating the Proxy after a successful call ?

Thanks a lot.
Pages: [1]