Hi All,
 I've been using puremvc here and there for a while now and like lots of what it has to offer,
 (dont like all the boiler plate though).
I also use spring a lot, and in order to properly springify things I found it convenient to be able to get/set Lists for registered Proxies, Mediators, and Commands. I end up creating duplicate Lists of each, with getters & setters in my ApplicationFacade, which are injected directly by spring, and then I do something like this in the spring afterPropertiesSet:
   public void afterPropertiesSet() throws Exception {
      for (IMediator mediator : instance.mediators) {
         instance.registerMediator(mediator);
      }
         
      for (IProxy proxy : instance.models) {
         instance.registerProxy(proxy);
      }

      registerCommand(MVCCommand.STARTUP.name(), startupCommand);

   }

I also then just iterate these lists in a shutdown command which saves boilerplate and ensures I unregister everything.
ie I dont have to maintain a list of stuff like this: getFacade().removeCommand(MVCCommand.SHUTDOWN.name());

It would be easier if the facade had getCommands(), getProxies(), getMediators(), and would be really nice if there were also a
setProxies(List<IProxy> proxies),
setCommands(Map<ICommand,String notification>) etc too so I dont have to create duplicate lists.

Thoughts?

the basic java port of puremvc has been around for years.
Has nobody else noticed that Proxy core Mdel never calls onRemove when proxies are removed?
Same is true of both the Single and MultiCore versions.

Hi, I'm wondering why this port doesnt use ConcurrentHashMaps instead of HashMap+synchronized block?

for example in the Facade.getInstance method, its synchronized which has gotta be bad for performance
since its a commonly accessed method.
also, why does it bother to generate a "new Facade(key)" if one isnt provided? if it hasnt been subclassed then the app cant be using puremvc as its intended, and if it has been subclassed then creating this new Facade is a waste of effort.

at any rate to keep existing functionality, wouldn't replacing the instanceMap with a concurrenthashmap and reworking the method something like this make sense?
   
public static Facade getInstance(String key )
if (key== null) {
            throw new Exception("key cannot be null.");
        }

 Facade facade, newVal;
    do {
      facade= instanceMap.get(name);
      newVal = (facade== null) ? new Facade(key):facade;
    } while (!instanceMap.replace(name, facade, newVal));

        return newVal;
    }
}


Cheers

I'm concerned that in this implementation the facade 'singleton' is never a singleton, there are always 2 copies if you extend Facade (which I believe is what one is supposed to do?).
In java you can only hide a static object, so when you create your appFacade extends Facade, you are forced to declare your own static instance variable too. this might be ok, but the Notifier object grabs its copy of the facade object directly from the Facade class

hence it matters in what order you create appFacade and the Notifier object:
in once case it throws an error (RuntimeException("Facade already constructed")),
 and in the other it runs (except that 2 facade objects exist).

either way shouldn't there only be 1 facade instance?

I'm also concerned about thread safety in general. There is another thread here remarking on the hashmaps, but the following pattern is used to create singletons, and its not safe.

      if (instance == null) {
         try {
            instance = new Facade();
         } catch (Exception e) {
         }
      }
      return instance;

is anyone still working on or using this project?