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

Show Posts

* | |

  Show Posts
Pages: [1]
1  PureMVC Manifold / MultiCore Version / Re: Best place to handle module loading on: August 27, 2008, 04:43:07
Ok - interesting. I'll give it some more thought ;o)

I still kind of like them sitting in a Proxy, although I agree they don't form part of the Domain model. I think I just need to do a little more thinking about it all.

Thanks for input.
2  PureMVC Manifold / MultiCore Version / Re: Best place to handle module loading on: August 27, 2008, 02:53:35
I take your point, but it still feels a little wrong to me as the ModuleLoader Mediator wouldn't actually be mediating anything, it's just providing a way to create the modules from the IModuleInfo object's factory. It feels almost more like a data store.

The approach I've taken seems strangely similar to one mentioned very recently in another thread on this forum. I have a ModuleLoaderProxy which handles the physical loading of the modules. When myModuleLoaderProxy.load (someUrl) is called, I make a call to ModuleManager.getModule (someUrl) and store the returned IModuleInfo in a lookup. If the module is loaded for a second time, I've already got that IModuleInfo object and I just call "load" on it again, sending out a Notification when the ModuleEvent.READY event is received. This'll work the same way whether the module is loaded the first time, or on subsequent attempts.

Interested parties can then listen out for this Notification, and if they then want to create an instance of the module they can get access to the IModuleInfo object (and therefore the Module's factory) through the ModuleLoaderProxy and then do what they want with it.

I'm treating the loaded modules in the same way as I would any data that's loaded in from the server. I store it in a Proxy and then anyone who wants access to it can retrieve it from there. All load / IOError handling is handled within the Proxy (just as it would be if I were loading an XML file, or calling a webservice).

It's working well so far (although I only coded it yesterday and haven't fully tested all my use cases yet) - I'm more than open to adjusting my thinking if it can *click* for me for the module loading process to be part of the view, not the model, but as yet I'm not fully convinced.

Do you think it can make sense to treat the loaded module data in the same way as any other data loaded from the server?

3  PureMVC Manifold / MultiCore Version / Best place to handle module loading on: August 26, 2008, 11:21:50
ello,

Just a quick question - in an app using Pipes for dynamic module loading, where do you reckon is the best place to handle the loading of the module (integrating with ModuleManager, listening for progress / setup / ready events etc).

Off the top of my head, it seems like this should go in a Proxy which can handle loading of modules, with each load triggered by a Command. The Proxy can handle the loading of the module, then when loading is complete, a notification is sent out (perhaps with the module's factory in the notification body). Any interested parties can then do what they want with the module once they know it's loaded.

I think this makes more sense than putting it in a Mediator or Command.

I'd appreciate any insight or thoughts.

Cheers!
Toby
4  PureMVC Manifold / Demos and Utils / Re: PipeWorks- a PureMVC AS3 MultiCore Demo on: August 17, 2008, 05:46:27
Just wanted to say that the best piece of advice here was to look into the Unit Tests. I've never actually looked at any Unit Test code before, and always avoided using it in my apps (as ever, mistakenly believing it was more complicated than it is). Not only have these classes helped me work out what's going on with Queues and Filters, but I've also learnt a lot about Unit Testing. Nice one Cliff!
5  PureMVC Manifold / MultiCore Version / Re: Facade becomes available in initializeNotifier NOT constructor on: August 17, 2008, 05:24:00
ello,

I wrote a bit more about this issue here - http://lowpitch.com/blog/2008/07/23/puremvc-multicore-vs-standard-singlecore/ . I guess it's a sign of a well designed system that so few changes have to be made to port from singlecore to multicore.
6  PureMVC Manifold / Demos and Utils / Re: PipeWorks- a PureMVC AS3 MultiCore Demo on: August 15, 2008, 04:02:47
Thanks for the advice Cliff... I'll take a peek over the weekend and post a link to whatever I end up writing here :o)

7  PureMVC Manifold / Demos and Utils / Re: PipeWorks- a PureMVC AS3 MultiCore Demo on: August 15, 2008, 08:30:08
ello,

I'm currently writing up a Pipes tutorial to force myself to understand it. I've found that writing about something makes me understand it far more than simply skimming over some docs etc.

Anyway, I'm wondering if there are any resources anywhere talking more about Queues and Filters. The only info I've found so far is within the source code of the Pipes demo. Anyone know if there's any more information floating around about either of them?

Cheers,
toby
8  Announcements and General Discussion / Architecture / Where to put the various constant names for Notifiers on: July 29, 2008, 08:55:59
Hi there,

After recently getting to grips with PureMVC and building a couple of test apps, I'm diving in to using it for a larger application. It'll be a Flex app with multiple modules (using Pipes), and I've got the structure worked out quite nicely as I'd like it.

In my test apps, I've tended to create a class which purely exists to define all the Notification name constants, so that any class that needs to send a notification, or react to one, can gather the constant name from this one class. I decided not to put them in the ApplicationFacade to keep that class nice and simple. This has been working pretty well for me, but I'm wondering if it's 'Best Practice'?

Obviously, I'm gonna need one of these constant-storing classes per Module, and the fact that I'm using Modules is really irrelevant to my question. I'm interested to know what people have done when building larger apps with the framework - are you tending to keep everything inside ApplicationFacade? Are you creating a class just to store all the constant names? Are you doing something else which I hadn't considered?

Any info would be much appreciated.
Cheers,
toby
9  Announcements and General Discussion / General Discussion / Re: How to get configuration data to proxies/delegates on: July 13, 2008, 03:58:41
Nice idea - that'd fit nicely into my implementation. Thank you.
10  Announcements and General Discussion / General Discussion / Re: How to get configuration data to proxies/delegates on: July 13, 2008, 12:21:45
Hi Cliff,

Just a little question to add here... I have multiple proxies which all need to retrieve data from the same XMLRPC service (each one calling different methods of that service). I'm going to shift the calls to the service out into a Delegate to avoid a bit of repetition, but I'm hitting a minor stumbling block here.

The config data which defines the URL etc of the service is loaded into a ConfigProxy before anything else happens.

Obviously, the delegate needs to get access from the ConfigProxy, but doesn't natively have access to the facade. It seems my two options are...

1. From within my delegate, I could do something along the lines of ...
ApplicationFacade.getInstance (blahblahblah).retrieveProxy (ConfigProxy.NAME) as ConfigProxy;
... to access the config info.

2. Each Proxy which instantiates an instance of the delegate to perform some kind of server call could pass the config data into the Delegate. This seems a bit messy, as I was hoping to avoid constantly passing the config data around.

How would you handle such a situation? Where would your Delegate get its config data from - would it retrieve the ConfigProxy itself, or have the data passed in from whatever Proxy was invoking it?

Interested in your thoughts.

Many thanks,
Toby
Pages: [1]