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: Enums for Notification names?  (Read 12884 times)
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« on: December 12, 2007, 09:26:05 »

-----Original Message-----
From: Thomas Schuessler [mailto:Thomas.Schuessler@bwservices.de]
Sent: Tuesday, December 11, 2007 12:06 PM
To: cliff@puremvc.org
Subject: One more question...

Hi Cliff,

It is probably too late to make such a change and maybe I am a little paranoid, but what about using Enum-classes instead of strings to identify notifications? This would avoid the need to have naming conventions in larger projects.

br...tgs

Thomas,

I'm not completely against enums, as you can see in the Arch101 demo, I find a variation on it very useful for dealing with combo box population where we have an enumeration of possible settings:
http://puremvc.org/pages/demos/arch101demo/srcview/source/org/puremvc/arch_101/unit_03/lab_02/model/enum/DeptEnum.as.html

But it seems to me that Enums are still a little involved for a core activity like notification constant naming. I think a lot of people would be put off by it. Of course middleware would help, but...

However, this really falls into the area of idiom. You could do it either way.

I would suggest doing demos that use both approaches. One that will be more understandable to people using other versions of PureMVC where constants are used, and another that shows using enums for those who prefer it.

The advantage of enums over constants are that you get all the possible values in one spot, even ordered. But we don't really ever have a need for that in PureMVC. Nothing is ever passing over all possible Notification names. At least not now. If there were utilities for analyzing and interacting with arbitrary PureMVC apps, then it might be nice to expose the notificaiton names supported by the app to such a tool...

-=Cliff>
« Last Edit: December 12, 2007, 09:46:05 by puremvc » Logged
Brian Heylin
Newbie
*
Posts: 1


View Profile Email
« Reply #1 on: July 06, 2008, 12:22:21 »

Hi there

I'm interested in making PureMVC usable with Enums as I see Strings as more hassle to program with.

Hassle purely from a code cleanliness point of view as i would much rather see this:

:
public enum ImaginaryNotifications {

    LaLa,
    MooMoo

}

rather than, what I see as a lot of extra, meaningless, error prone code:

:
public class ImaginaryNotifications {

    public static final String LaLa = "lalas";
    public static final String MooMoo = "moomoo";

}


I appreciate the arguments against using Enums for the community, and I would like to try make both methods possible. I have already partially made this possibly for myself by modifying the current version (0.2) with overloaded sendNotification methods. There are of course many other things that then need to change, the most dangerous being the INotification interfaces etc.

At the moment I have some ugly code checking notification types in commands that handle related notifications, like:

:
if( notification.getName() == MyNotificationEnum.SomeValue.toString() ){

    ...

}

So basically is it possible and desirable to integrate Strings and Enums into the PureMVC Java port?

P.S. I would actually prefer just do use Enums solely but maybe someone might have a technical reason for not doing that

Logged
fede
Newbie
*
Posts: 7


View Profile Email
« Reply #2 on: March 09, 2009, 08:51:17 »

+1 for enum as notifications name, when the application grows the eventuality of name collisions became more and more high.
and you can use a safe switch in the handleNotification of a Mediator
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: March 09, 2009, 09:50:39 »

regardless of whether enums are used, the notification namespace can best be managed by controlling the values. For instance, a utility that will be reused should define any notes it uses like this:

(String)NAME = "MyUtil";
(String)CANCEL = NAME + "/cancel";
(String)SAVE = NAME + "/save";

Etc...

-=Cliff>
Logged
Pages: [1]
Print