Over 10 years of community discussion and knowledge are maintained here as a read-only archive.
Partway through setting up the projects, I find the routing demo needs to be refactored into the PureMVC namespace first. It would be helpful if you could give it a name, say FabRouting, and refactor the classes into that namespace.
Repositories are one per project. This is the way the site works now, and automated tools that are being built make it important that it stay that way.
Also, we will need unit tests for your classes and asdoc. Compare to the Pipes utility if you're unfamiliar with unit testing or just looking for the level of documentation to provide.
I've just implemented fabrication in my application and it works great (saves me a lot of headaches right now Roll Eyes), so thanks for that!
I was wondering why the proxy classes don't have a FabricationProxy so they can routeNotifications too. Is this a design choice you've made or something that isn't implemented yet.
I'm also curious what you think about the idea to store notifications that should be routed but can't be because there isn't a router connected to the module which sends the routeNotification. One module for example is routing some notifications to the log about what is happening in his initialization fase (in which he isn't yet connected...). As soon as the router will get connected, the stored notifications will be send along.
I am working on improving the documentation. I have added several pages to the wiki to get things rolling on this front. You can check out the below links.peace,darshan[2] : Getting Started
override public function execute(note:INotification):void { registerMediator(new HelloFabricationMediator(note.getBody())); sendNotification("now", new Date()); }