Hi,

I am trying to understand how pipes can solve my problem. I have read the available docs, but I still don't feel very comfortable with it to figure out how to use it on this case.

I have multicore application where I need to share some data between cores. Considering this minimalistic example:
- a core that is responsible for managing "categories";
- several cores that need data from the core "categories";

I can have the following scenarios:

- The user opens the "categories manager", and then the categories are loaded from the server. If the user moves to another module that needs those categories, that module should communicate with the "categories core" and ask for them;
- The user goes directly to another core without passing by the categories manager - so categories are not yet loaded. That core will need categories, so it has to communicate with the core "categories" that should load the data, and then retrieve it;

It seems that pipes is the solution to my problem, but I'm having some difficulties figuring out the best architecture to solve my problem using pipes. Can you give a brief explanation on the best practices for solving this case?

Thanks!

I like Delegates because I see them as a "copy" of the backend API. With delegates, our client side developers don't need to care about the complexity of the backend.
Also, you can use delegates to translate the backend data format to the client-side data format, if needed.

I am currently implementing the access to the delegates using the proxy, the first time some class needs to access the "data" property of the proxy. Also, I'm making a public function "refresh" to refresh the data if needed. This is way different of what I was used to develop in Cairngorm, where the view was binded to some property on the ModelLocator, and it needed to call some command to get the data on the server-side.
Let's see how it goes...

Cliff,

thank you a lot, once again.
All is clear, except number 2:

>2.
>If I have views inside other views, I am doing this to register the mediators on the StartupCommand:
>
>         facade.registerMediator(new LocalesModuleMediator(app))
>         facade.registerMediator(new LocalesManagerMediator(app.localesManager));
>         facade.registerMediator(new LocaleEditorMediator(app.localesManager.localeEditor));

>> 2. You are placing too much knowledge about the internals of the view component in the command.

So what do you propose? I don't see another way...

Thanks,

João Saleiro

Hi,

I am used to Cairngorm. In Cairngorm, commands use the serviceLocator to get a reference to a service delegate to call a remote procedure. When data arrives, the model is changed accordingly.

It seems that in PureMVC this is slightly different, since proxys should call directly the service delegates. In one hand, I was used to the Cairngorm methodology and I feel comfortable with it. In another hand, I will need less code, and less "confusion", by making the proxy call the service delegate directly.

Which one is the preferable practice?

Thanks,

João Saleiro

Hello,

I have several small questions on best-practices using PureMVC on a Flex/AS3 Application.
I am posting them on the same topic, but if you prefer next time I can create a topic for each of them.

1.
There are views that are only added to stage later, so I can't register their mediator on the StartupCommand. In this case, where do you recommend making the facade.registerMediator ?

2.
If I have views inside other views, I am doing this to register the mediators on the StartupCommand:

         facade.registerMediator(new LocalesModuleMediator(app))
         facade.registerMediator(new LocalesManagerMediator(app.localesManager));
         facade.registerMediator(new LocaleEditorMediator(app.localesManager.localeEditor));
[...]

Is this the best approach?

3.
On the sendNotification method, what the purpose of the third argument (type) ?

4.
I have a view with several components (buttons, etc). I have a button that will change the current section on the application. What's the best approach:
a) The view registers for the click event of the button, and it's handler will dispach an event that the mediator should listen an react to change the application state
b) The mediator registers for the click of the button on the view, so everything is handled on the mediator

5.
The mediator should act only as a gateway between the views and the framework, or it is supposed to act also as a ViewHelper? In another words, imagine that I have a button that when clicked, it changes the currentState of the view. There is no need to access the framework, since everything needed is accessible on the view. The code to react to the click and change the currentState should be put inside the view component (the mxml file) or on the mediator? When should I make "reaction" code on the mediator?

6.
On the multicore version of PureMVC the facade is only available on the mediator after the call to the initializeNotifier. Where should I put the "addEventListeners" for the components on the view: on the constructor of the mediator, or on the initializeNotifier method?

Thank you! BTW, we are loving the PureMVC multicore.

João Saleiro

Hello,

I am starting now with PureMVC. I was a Cairngorm adept (changed from ARP when Flex 2 appeared), but Cairngorm failed me when I started working more and more with Modules.

I studied PureMVC with the multicore examples, and both the architecture and workflow convinced me.  I am not 100% comfortable with PureMVC yet, but I'm already testing it on a real project.

I am trying to improve code reusability, and I need some advices to achieve a best-practices solution to the problem I'll describe below. This might be a common problem when someone starts building larger projects, while reusing code, and maintaining the smallest dependencies possible between modules. I'll try to explain with an example.

We have organized our workflow for reusing code between projects the following way:

- we have a folder where we put everything that's needed among several projects (our library);
- in each project we add the library to the classpath of the project.

For example, about 90% of our projects need a custom "LocaleManager " module. A LocaleManager is something composed with a view, a model and a controller, that allows users to add new languages to our RIAs. The functionality is 100% equal in every application. So we decided to create a Module that resides on our library path, and the Module has it's own MVC architecture based on PureMVC multicore.

The thing is that while the functionality is 100% the same in every application, the view might change. Not only in terms of (css) style, but also in terms of what and how things are shown to the user.

So I thought in removing the View from the MVC of the Module, putting it on the Main application, and when I load the Module I would inject the view.  I created an IViewReceiver that my Module implements, with a function inject(mediator:IMediator, addView:Boolean):void .
The implementation of this function would consist on registering the mediator on the facade of the Module, and making and addChild of the mediator.getViewComponent() if the addView flag equals true. If my module has more than one component, I have to call the inject method for each component I want to register with the Module' Facade.

I am implementing this right now, but I'm not sure if it's the best option, and even if it works. I wonder if there is a established best-practice out there for this case. Do you think that my solution will work? Is there a better one?

Summarizing, what I need is to have modules in a library shared between projects; Each module is almost a full application, without the view (it can have the view coded on the same packaged, but it's not included by default) so it's a MVC without the V; The guy who creates the Application that uses the module must have the possibility to create it's own view for that module; The modules must be independent of the applications where they are used, but the applications can be dependent on the modules.

Thank you,

João Saleiro