Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
December 18, 2017, 05:31:57 AM
Home Help Search Login Register
News: Please DM @puremvc on Twitter to gain forum access. Spambots are why we can't have nice things.
Pages: [1]
Print
Author Topic: EmployeeAdmin Demo: Why don't use method removeRoleFromUser() any notification ?  (Read 4346 times)
openoli
Full Member
***
Posts: 44


View Profile
« on: November 02, 2010, 01:45:50 AM »

Hi,
can anybody help me to understand the following:
By adding a new role to the selected user, addRoleToUser() is called and the role proxy sends a notification, the RolePanelMediator handles the ADD_ROLE_RESULT notification and updates the view... that's clear !

By removing a role from the selected user, removeRoleFromUser() is called but no notification is send and the view is update anyway... seems through some binding ?

My Questions:
1)
I don't understand this binding, for me it seems something like voodoo.
The removeRoleFromUser() method manipulates the local userRoles ArrayCollection. Why has this manipulation an effect to the view at least ?
2)
Is it a good practise using in the first (add role) case a notification and in the second (remove role) not ?

Many thanks for help in Advance, hope my questions arent's so stupid ;-)

Olaf



RoleProxy.as
Code:
       // add a role to this user
        public function addRoleToUser( user:UserVO, role:RoleEnum ) : void
        {
            var result:Boolean = false;
            if ( ! doesUserHaveRole( user, role ) ) {
                for ( var i:int=0; i<roles.length; i++) {
                    if ( roles.getItemAt(i).username == user.username ) {
                        var userRoles:ArrayCollection = roles.getItemAt(i).roles as ArrayCollection;
                        userRoles.addItem( role );
                        result = true;
                        break;
                    }
                }
            }
            sendNotification( ApplicationFacade.ADD_ROLE_RESULT, result );
        }

RolePanelMediator.as
Code:
       override public function handleNotification( note:INotification ):void
        {

            switch ( note.getName() )
            {
                ...
                    
                case ApplicationFacade.ADD_ROLE_RESULT:
                    rolePanel.userRoles = roleProxy.getUserRoles( rolePanel.user.username );
                    rolePanel.reset();
                    break;
                    
            }
        }



RoleProxy.as
Code:
       // remove a role from the user
        public function removeRoleFromUser( user:UserVO, role:RoleEnum ) : void
        {
            if ( doesUserHaveRole( user, role ) ) {
                for ( var i:int=0; i<roles.length; i++) {
                    if ( roles.getItemAt(i).username == user.username ) {
                        var userRoles:ArrayCollection = roles.getItemAt(i).roles as ArrayCollection;
                        for ( var j:int=0; j<userRoles.length; j++) {
                            if ( RoleEnum( userRoles.getItemAt(j) ).equals( role ) ) {
                                userRoles.removeItemAt(j);
                                break;
                            }
                        }
                        break;
                    }
                }
            }
        }

« Last Edit: November 02, 2010, 11:36:35 PM by openoli » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW
« Reply #1 on: November 03, 2010, 11:50:27 AM »

Of course a notification could be sent from the Proxy, which would be heard by a mediator which would update the view, but in Flex, when an ArrayCollection is used as a data provider to a view control, the control automatically updates when the contents of the collection change. On a platform that did not have view components that observe their data providers' changes in this way, you would of course be able to complete the circuit with PureMVC notifications.

What is being demonstrated is that there can be a happy medium in your implementation. You don't have to be so strict as to rebuild the wheel often in your code, as long as adequate separation of roles and responsibilities are being made in your application. You can leverage stuff that's happening in the GUI framework without feeling you've taken a shortcut.

If that view component is already going to see the change and update itself because of its clearly defined relationship with a collection data type, then its fine to rely on that. Your alternative is to use the Array object and manage it as a collection yourself, ensuring that all the notifications are sent on changes, and listened to by mediators and update methods written in the components to make the updates possible without giving up too much of the component's encapsulation.

And if you port your application to another platform, you can be sure that components and data types are going to be the number one thing that will change anyway. If you find yourself at porting time having to put in the code to send notifications from the proxy that end up affecting a view update, then so be it. At that point, you've written the code because you had to and not just for form's sake alone.

-=Cliff>
Logged
openoli
Full Member
***
Posts: 44


View Profile
« Reply #2 on: November 05, 2010, 12:58:13 AM »

Many thanks for this detailed answer Cliff !

So, this means that following lines of code only demonstrates the notification handling, but
aren't really neccessary cause rolePanel.userRoles is bound to the model, right ?
Perhaps it's a good idea to remove this completely from the demo or to place a short comment to avoid confusion ?

RolePanelMediator.as:
Code:
case ApplicationFacade.ADD_ROLE_RESULT:
rolePanel.userRoles = null;
rolePanel.userRoles = roleProxy.getUserRoles( rolePanel.user.username );
break;

Great work, keep up this incredible engagement Cliff !
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW
« Reply #3 on: November 08, 2010, 10:09:23 AM »

That is correct.

Thanks,
-=Cliff>
Logged
Pages: [1]
Print
Jump to: