|
|
Show Posts
|
Pages: 1 ... 3 4 [5] 6
|
62
|
Announcements and General Discussion / Fabrication / Re: Fabrication 0.4 released
|
on: October 22, 2008, 06:24:56
|
I haven't got an example of this yet, but its mostly one call. You need to call module.dispose() to cleanup a module. That call does disposal of all the internals like the facade, controller, view, commands, etc. I am also dispatching a SHUTDOWN notification prior to the module's disposable. If you wish to perform any custom cleanup in the module before disposable, you can register a command with this notification.
As a general practice most of the classes implement the IDisposable interface. So when you extend any class you should override the dispose method, implement any custom cleanup if needed and then call super.dispose().
peace, darshan
|
|
|
64
|
Announcements and General Discussion / Fabrication / Re: Fabrication 0.4 released
|
on: October 21, 2008, 10:24:04
|
Hey Ruben, I've been busy refactoring some of my own code and finally everything is working again with 0.41 so that's quite a relief.
Its a relief for me too that you got it working. I was afraid I had gone a little overboard with some of the features. ;-) One question I have so far is about the new FabricationProxy. I have several modules who's proxy extend the same base proxy, named "DataProxy". When they extend "DataProxy", they don't change the ProxyName because I wanted them to share a couple of Commands which fill the "DataProxy".
... So my question is, why does the notificationname get changed when the registered proxyname is not same as the classname?
Good point. This is by design, and works well with the Reflexive Notification interests. I am using some of my Proxies in a similar manner,i.e.:- Multiple instances of the same proxy with a different proxy name. However since the Proxy is the same the notification name is common between them. This is a conflict with the PureMVC's notification system, where each notification name must be unique. Hence the 2 part notification name expansion. There are 2 ways to handle such notifications. The first and easiest is using respondToProxyName. If you name your handler like respondToMyProxy, Whenever the proxy named MyProxy, dispatches a notification this handler will be called automatically. The fabrication mediator picks this notification interest up using reflection. So in your case the code would be, public function respondToModule1Proxy(note:INotification):void {
}
// and
public function respondToModule2Proxy(note:INotification):void {
}
The convention is to have your proxy named something like MyCustom<Proxy>. Any respondTo method with a Proxy in its name is interpreted as a notification interest in that proxy. The second way is a little involved. In this approach you need to qualify the notification explicitly using qualifyNotificationInterests in a mediator. So in your case if you need to do something like, override public function qualifyNotificationInterests():Object { return {dataSet : "Module1Proxy"}; }
public function respondToDataSet(note:INotification):void {
}
This does the expansion of the DATA_SET notification from Module1Proxy to Module1Proxy/dataSet. So you can use respondToDataSet. Hope this clarifies things a bit. I haven't figured yet out how to qualify the same note name with different Proxies without method overloading. So if you might have to stick to the first approach. If this is something you would like to avoid you can use, override public function getNotificationName(note:String):String { return note; };
Should I add a flag like expansion:Boolean to turn this behaviour on or off? Here are some other small comments, but nothing really big so far. A small addition to the FlexModule class is to add some event metadata
Sure, I will do the same. Although I've seen a "removeEventListener" for every "addEventlistener", another addition I've made myself is to add "false, 0, true" to every addEventListener call to make sure those references won't cause any memoryproblems... (yes I know, not really necessary)
Can you tell me where you would like to add this? In general most of the classes in Fabrication implement the IDisposable interface to clean up before they are deleted. My preference is towards explicit removeEventListener and overall cleanup. If an object is no longer used I tend to delete it and any references to it in the dispose method. peace, darshan
|
|
|
65
|
Announcements and General Discussion / Fabrication / Re: Fabrication 0.4 released
|
on: October 21, 2008, 11:27:50
|
Well spotted. Some of the internal piping is showing there. I think I need to add a check in the RouteNotificationCommand. Something like,
if (to != "*" && !(new RegExp("\/INPUT").test(to)) { to += "/INPUT"; }
I will verify everything works and check this in tomorrow. Please use the explicit /INPUT for the moment.
peace, darshan
|
|
|
66
|
Announcements and General Discussion / Fabrication / Re: Fabrication 0.4 released
|
on: October 21, 2008, 05:24:19
|
Ruben, I have fixed the FlexModule to allow loading of modules directly using the ModuleManager. The fix is available from the google code page[1] version 0.4.1. I ended up not requiring the custom event because the ModuleEvent.READY does the job nicely. In your code's ready handler you will need to do something like, protected function onPluginCreated (event:PluginEvent) : void { event.plugin.defaultRouteAddress = applicationAddress; event.plugin.router = applicationRouter; }
The accept router call won't be needed. The new fabricator takes care of that. I duplicated the simple_routing example to simple_routing_with_module_manager[2]. You can refer to this example for further details. The key changes are in ModulesContainerMediator#moduleReadyListener. The rest are minor changes to remove the cast to ModuleLoader. peace, darshan [1] : http://code.google.com/p/fabrication/downloads/list[2] : http://fabrication.googlecode.com/svn/examples/simple_routing_with_module_manager
|
|
|
67
|
Announcements and General Discussion / Fabrication / Re: Fabrication 0.4 released
|
on: October 20, 2008, 08:03:23
|
Jason,
Thanks for your comments. Regarding extending MovieClip, I have kept it for people who might need to extend MovieClip. Extending Sprite would otherwise require 2 sets of fabricators. There is a slight performance hit which should probably be reasonable as long as the internals use Sprite in animations and drawing stuff.
Your points about the lack of deferred instantiation in CS3 components are valid. And it would be difficult to support all the different variations. I am thinking of sticking to Flash designer specific stuff. The link up between the graphic assets into behaviour from CS3 pov is with the instanceName. I am thinking of trying to target this.
So for instance if the graphic designer placed 2 buttons at different points of time on the timeline. Lets say both these buttons are for the same action, to toggle full screen mode. Now suppose I have a FullScreenButtonMediator which adds a listener to the buttons and provides the full screen toggle behaviour. I want to be able to code something like,
registerMediator(new FullScreenButtonMediator(resolver(app).re("fullScreenButton.*")));
So the designer has basically indicated behaviour of the button by giving it an instance name like fullScreenButton1, etc. Your thoughts?
peace, darshan
|
|
|
68
|
Announcements and General Discussion / Fabrication / Re: Fabrication 0.4 released
|
on: October 20, 2008, 07:36:26
|
Ruben,
Ok, I think I got it. You need to set the defaultRoute and the router on the module. I think you will need a FabricatorEvent.FABRICATION_CREATING event where you do something like,
// for setting the module's default route to the shell event.plugin.defaultRoute = "*"; or event.plugin.defaultRouteAddress = applicationAddress; event.plugin.router = applicationRouter;
The current FABRICATION_COMPLETE event is fired after the fabrication is created. I will change the FlexModuleFabricator to fix this by tomorrow.
peace, darshan
|
|
|
71
|
Announcements and General Discussion / Fabrication / Re: Fabrication 0.4 released
|
on: October 20, 2008, 06:12:57
|
Jason,
You are right if you just need the message routing, you do not need to extend the FlashMediator/FlexMeditaor. However, If you intend to use Reflexive notification interests, you will need to extend FlashMediator/FlexMediator. Moving forward this is going to the key integration point for new Mediator specific features.
Ruben,
I didn't realize you were using ModuleManager. Serve's me right for developing in the dark, I guess. ;-) In 0.4 the FlexModuleFabricator looks up the router from the parent ModuleLoader so its linked for the moment. I will try to fix this soon. Can you post some sample code, It would help clarify the usage?
peace, darshan
|
|
|
72
|
Announcements and General Discussion / Fabrication / Re: Fabrication 0.4 released
|
on: October 18, 2008, 07:26:59
|
With the elimination of the ApplicationFacade, does one register all their commands in the StartupCommand now? So essentially the old ApplicationFacade has moved to the StartupCommand? I haven't tested yet, but I wonder how well the StartupManager utility will play with Fabrication. I think it should be fine.
Yes the registration of commands needs to happen in the StartupCommand with Fabrication. The StartupManager utility works fine with it, I am using it as well. PureMVC is a very extensible framework with such aspects. Fabrication only adds behaviours at the typical extension points like, FlexApplication/FlashApplication, FlexMediator, SimpleFabricationCommand, etc. Just trying to wrap my head around building large apps (many commands) using Flash with Fabrication. I assume only our old "JunctionMediator" mediator extends FlashMediator. The rest of our mediators still extend PMVC's Mediator unless we need the routing of Fabrication?
There is no need for the JunctionMediator at all. The routing of pipe messages happens entirely underneath the system. You indicate interest in a notification implicitly by writing a respondToNotificationName method in your mediator(for your environment). When you do a routeNotification the respondTo method will be called automatically. You can find more information here[1]. Btw, If you are familiar with Flex also check out the link I mentioned[1]. Fabrication 0.4 added Reflexive mediator registration for Flex deferred component instantiation. I am looking for feedback for applying this to Flash projects. Flash components do not seem to have support for deferred instantiation, but I am not very familar with the those components, so i may be wrong. I am thinking more on the lines of something to support the MovieClips hierarchy of Flash. Let's say you have MovieClip assets that are placed on the stage. This may be deep and possibly design driven. And additionally not explicitly given top level instance names. I should be able to mediate components/display objects in this hierarchy in an easy way. I am just thinking out loud here. It would be great if you can share your thoughts on the workflow with flash projects with PureMVC. peace, darshan [1] : http://www.codedrunks.com/index.php/2008/10/17/fabrication-04-released/
|
|
|
|
|