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: A big "gotcha" to watch for with dynamic Proxies extending FabricationProxy  (Read 2859 times)
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« on: June 10, 2009, 08:59:50 »

When using Fabrication with dynamically generated Proxies, there's a big gotcha to be aware of. I just spent hours debugging this problem so I thought I'd share my findings and save others the hassle.

When using dynamically named proxies, Fabrication will alter any outgoing notification names from that proxy. For instance, if you have a proxy named DataProxy_563 and you send a notification from within the Proxy called DataComplete, Fabrication will alter the outgoing notification name to DataProxy_563/DataComplete. This is done, in conjuction with a second notification sent named NOTIFICATION_FROM_PROXY, so that you can have mediators listen for specifically named proxys using a respondToDataProxy_563(note). The problem, however, is that this alteration requires your mediator to know ahead of time that the proxy they are interested in is named DataProxy_563, which you can't do when naming proxys using a dynamic generated name like _563. You lose the simple DataComplete notification altogether and can only listen for "DataProxy_563/DataComplete" (which won't work as a respondTo name) so you have to use the respondToDataProxy_563(note) method.

In my case I wanted to listen for that basic DataComplete notification and then inside the respodToDataComplete() call figure out what Instance of DataProxy it came from and go about my business that way.

Luckly, Darshen was smart (like you didn't know) and include a little mysterious property called expansion which, when set to false, will completely bypass the renaming and send the normal notification. YAY!

My only complaint is that I would have rathered this been set to false by default, rather than true. I don't really see many instances where I would want that default behavoir.

Anyway, simply set this to false in your proxy, assuming of course that you are entending FabricationProxy, to have the normal notification behavoir.
« Last Edit: June 10, 2009, 09:04:50 by Jason MacDonald » Logged
Pages: [1]
Print