Pedr,

Commands should be stateless, and caching them would encourage giving them state, a pitfall that often caused problems in Cairngorm back in the day.

Pascal,
I suppose I've just been living on the bleeding edge with MacAdobe products for too long. It really comes as a surprise to hear that folks are still clammoring for AS2 apps. I'm sure the handheld industry will for a while. Hmmm... I'm really starting to think about this now...

-=Cliff>

True that.

I remember Cairngorm used to instantiate all the Commands up front and cache them in the same way we typically eagerly create Proxies and cache them with the Model. It was only later that they went to lazy creation.

We could do that here. In the initializeController method, we could pass in not class names but instances to be cached.

I understand the problem with MacroCommands, what specifically about the Facade would be affected?

-=Cliff>

Pedr,

The idea of trying to backward-port PureMVC to AS2 has crossed my mind more than once. The primary reason is that I think it would be perfect for doing Flash games for phones and other portable devices since it is so lightweight.

But then I keep thinking surely Adobe will get AS3 in FlashLite soon. And we get further and further away from the days of AS2, and it gets harder to remember what fatal flaws and gotcha's I might run into if I tried.

Since you are being immersed in an AS2 project at the moment, any thoughts you might have on the subject of a potential port would be extremely useful.

-=Cliff>

Hi Pedr,

1) It's an accepted collaboration pattern for a Mediator to retrieve a Proxy and access it's data, and in fact this is the usual way that the Model data makes it into the View Components in a PureMVC app. If there is some complicated transformation of the Model data or it is being assembled from multiple Proxies, then we would usually call that 'Business Logic' and push it into a Command.

2) In the Architecture 101 demo, the DeleteUserCommand must perform several operations before the user can be considered deleted. It must remove the RoleProxy reference to the user and the UserProxy reference. Once both operations are completed, then we can send the Notification, and that's why it's done from a Command and not a Proxy.

Now on this second point, it could be argued (strongly in fact) that the operations being executed by the Command are 'Domain Logic' and therefore belong in a Proxy, as you suggest, and not in a Command.

In fact for funzies, you could refactor the app to do this, drop the Command and do it all inside the UserProxy. This means that the UserProxy must retrieve a reference to the RoleProxy and do the removal of the Role reference before sending the Notification. You'd need to invoke the method from the Mediator that received the original DELETE event from the user.

In the Architecture 101 course, this demo comes from a Unit where we eventually refactor the entire Model into its own package, so that it can be used across multiple applications. An administration app, (the demo) and an IntranetShell app, where the user can log in and see stuff that is related to their Role.

In that set of applications, we only do user deletion in the maintenance application, and nowhere else. So it made sense to handle this Domain Logic with a Command rather than bog down the Model tier with code that won't be used elsewhere.

When Mediator to Proxy communications are simple, then there is rarely a need for a Command to be involved. However if there were multiple UI gestures that might lead to deletion, and at some point you decide to insert a 'Are you sure?' popup into all use cases leading to deletion, then you might be glad that you implemented it as a Command that responds to a Notification from the View. Otherwise you'd find yourself visiting each Mediator and adding the popup logic (or, more likely refactoring to a Command).

Both of your questions center around the question: 'What is Business Logic and what is Domain Logic, and where do they go'? Keep in mind we generally want Business Logic in Commands and Domain Logic in Proxies, but there are exceptions to every rule.

-=Cliff>

Hi Oscar,

In most cases, the Mediator is not instantiated multiple times, and so the getMediatorName method may simply return the value of the Mediator's static constant NAME.

However if multiple instances will be created and registered, then the getMediatorName method of the Mediator must return a unique id for that instance.

Examine the code for the HelloFlash demo. In particular View the Source for the HelloSpriteMediator.

In the HelloFlash demo all the sprites that get created get a unique ID, and consequently the HelloSpriteMediator's getMediatorName method looks like this:

:

        /**
         * Get the Mediator name
         * <P>
         * Called by the framework to get the name of this
         * mediator. If there is only one instance, we may
         * define it in a constant and return it here. If
         * there are multiple instances, this method must
         * return the unique name of this instance.</P>
         *
         * @return String the Mediator name
         */
        override public function getMediatorName():String
        {
            return helloSprite.id;
        }

Hope this helps,
-=Cliff>

PureMVC was written to be a pure ActionScript implementation. MXML data binding is Flex-centric and therefore was considered verboten for framework functionality. When PureMVC is ported to Tamarin (or even to non-Actionscript OOP platforms like J2ME), if MXML data binding were core to the PureMVC implementation, we'd have to rethink the thing entirely.

But obviously, use of PureMVC should not keep you from using all that wonderful data-binding goodness that Flex gives us! Frameworks should play well together, thats the way synergy happens.

Although internally, a PureMVC application 'wires' itself up by way of communications between Commands, Mediators and Proxies, the View Components themselves frequently make heavy use of data-binding. For a good example, simply pop over to the Architecture 101 Demo here on the PureMVC.org site, click View the Source, and in the view.components folder, have a look at the UserForm.mxml class. Lots of data-binding going on there.

Data-binding is a wonderful tool for doing the 'internal wiring' of View Components. It really helps us to achieve a nice 'black-box' encapsulation of our implementation. Rather than having a Mediator set data down into the actual controls of a View Component, we have the component expose a property, which we then bind our controls to. So when the Mediator sets the property, the controls are updated automagically, and the Mediator didn't need to know very much at all about how the component was implemented.

-=Cliff>

At the moment, yes. mx.collections.ArrayCollection is a Flex class. I recently I saw something about a Flash CS3 add-in that lets Flash use Flex components, but I don't know the details yet.

-=Cliff>

When working with Flex and AIR, we have data structures (ArrayCollection/XMLListCollection) which already handle this communication for us.

Consider this scenario:
A Proxy holding an ArrayCollection of ValueObjects as its data property. A handle to the ArrayCollection is retrieved from the Proxy by a Mediator, who then sets it as the dataProvider for a DataGrid on its own View Component.

In this case, the ArrayCollection already has the ability to communicate the changes to any View Components that use it as a dataProvider. Therefore, there is often very little reason for us to duplicate that in PureMVC. For this reason, many Proxies end up being little more than bags of data, retrievable by name from the Model.

But that's not to say that you might not find the need to add these notifications from the Model. Aside from these built in Flex view updates, we may need for some business logic to be executed after the update as well.

Instead of the Proxy just allowing anyone to add something to its ArrayCollection, we may give it an addItem method, which adds the new item to the ArrayCollection, and then sends an itemAdded notification. Other parts of the View that need to react, may do so by expressing interest in this notification. Send deletedItem and changedItem notifications as well if need be. The Proxy then takes a more active role in managing the data it holds so that it can coordinate these changes with the rest of the application.

-=Cliff>

You might eliminate the ApplicationMediator if you're accessing the parameters from Application.application.

Just have a Command answer the first notification from the AccountProxy. It needs to see if the token is present in the parameters, and if not, alert the user.

You might even go as far as to send the user a link and the token standing alone. So if they didn't follow the link, they could just key in the token. Maybe they popped the email with their blackberry and can't follow the link on the public computer in the airport lounge or something.

So the Command could use the Flex PopupManager to popup a custom dialog to collect the token.

Either way, the Command gathers the token and sets it on the AccountProxy, who has a setter for that property that makes the confirmation service call with the token.

-=Cliff>

You rock, Rock.

I am sorry to say that I have been so swamped I haven't even had time to look into the previous example. I was waiting till I could clear a good amount of time to look into it.

It sounds like you've nailed the problem on the head, which is that you've got to set up a sort of 'master/slave' relationship between a module and the app that loads it.  The IPureMVCAware interface seems like a reasonable approach to the problem.

I really look forward to testing this out and seeing how it works. Can the loaded module also be written to run as a standalone application as well, following its own startup process depending upon whether its been loaded by another app or not?

-=Cliff>

With a large number of rows, either choice is a compromise.

One way to approach this is with a a paging scheme.

Depending on your server-side tech, you may already have support for paging.(Flex Data Services, now LiveCycle Data Services ES) has this support built in when communicating with Flex.

But let's say your building a Flash client to talk to a custom Perl service and you have to roll your own paging scheme.

Essentially the service needs to filter the query to a range of rows based upon a given page size an page number starting point supplied by the client.This is how most public APIs work, like google for instance.The query also needs to return the total number of results as well, so you know how far you can page.

Then, on the client, you need to use this info to allow the user to page thru as if the data were all there to begin with.

-=Cliff>

Kohinoor

It does diverge from the goal of keeping the view components transportable by keeping them ignorant of PureMVC classes. But whether to take or leave such a goal is entirely up to the implementor.

By building the component in this way, you have simply accepted that A) you're only ever going to use this component with PureMVC, OR B) if you do decide to use it outside of a PureMVC app, you're going to have to modify it to run elsewhere.

The key is being conscious of these decisions when you make them. And, if you're in an enterprise or otherwise writing code someone else will maintain, documenting the fact and why the decision was made to go against the best practice. Maybe it was a time constraint. Too long to figure out the solution that fits with the practice. Maybe there was some other extenuating circumstance. Whatever it was, capture it early so that future generations get a clue why things are the way they are.

-=Cliff>

I removed a misleading statement (and response) from the thread made very late while muzzy. Facade.removeMediator is in fact there (there was a time when it was not).

Your error:

:

facade.removeMediator(LoginFormMediator.NAME);
but this gives me error message

:

Error #1009: Cannot access a property or method of a null object reference.

was most likely caused by the removeMediator issue that caused the 1.6 revision. See the Version 1.6 notes in the version.txt file in the current PureMVC distribution zip file.

Younes,

PureMVC is intended to adapt components to an ActionScript application. I can't really think of a useful role for it in the definition of the components themselves.

-=Cliff>

Hi Pascal,

The first thing I'd do is get the Flex source code and examine Adobe's ViewStack implementation for ideas.

One thing to keep in mind is that this Flash Viewstack that you might create, like any View Component, should be something that does not require PureMVC to operate.

-=Cliff>