You could go with either option.

If you chose to put everything under one Proxy, you would need to keep track of each tree. You could keep track of tress based on the value of _parent. Of course, you need to beware of Nodes accidentally being assigned null.

If you go with a Proxy per tree, you'll need to register each of these with the facade, remove them when you no longer need them, and have each instance return a unique value for the getProxyName function since this is how PureMVC identifies unique Proxy instances. This option has the benefit of keeping data access very narrow. Also, if you're looking for a specific tree, you'll potentially have to search through every proxy to find it.

I would go with the single Proxy option, mostly because all the data is in one place, and all you have to manage is the Node collection.

I think you've pretty much got it, the only thing I would do differently, is instead of creating a NodeProxy for every Node, create a single NodeProxy that keeps track of a collection of all nodes. This will make it easier to find nodes, since you would loop through the collection instead of through Proxies.

You would probably also want a reference to the node's parent. Root nodes would have the parent property set to null.

Also, you would want to approach this differently if you're dealing with something like a database.

I have been placing my assets withing the subdirectory of whatever components/code uses them. This has two benefits: cleaner code and if I ever decide to reuse the code, I only have one directory to copy. Although I would say that for a style for the entire application, you may wish to place this at the root instead of having it scattered about. It depends a lot on the relationship between your skins and your code.

If you have an application that is split up into multiple parts then I usually split it up into sub folders (i.e. com.puremvc.app.forum.view, etc. ). This way packages contain only code relevant to that particular piece of functionality.



A little digression; the package structure isn't usually named after the company/organization but rather the reverse domain name of your website:

Ex..: www.puremvc.org -> org.puremvc.....

The reasoning behind this is that only one individual/organization is associated with a domain name, this helps avoid package naming conflicts.

Of course, this mostly matters if you plan on reusing your code elsewhere/distributing it or are bringing in libraries that having naming conflicts with yours.

Here's a document on Adobe's site explaining it in more detail (it's for AS2, but most of it carries over, package details are near the bottom):
http://www.adobe.com/devnet/flash/articles/as_bestpractices_02.html

I think the biggest benefit (indeed, a feature) is that PureMVC is pure AS3. This means you can use it in Flex, AIR, or plain old Flash with no dependencies on other frameworks such as Flex or AIR.

Nice resource! Printed and in my cheat sheet binder.

Check it out! Flex Show interview with Cliff on PureMVC!

http://www.theflexshow.com/blog/index.cfm/2008/1/30/The-Flex-Show--Episode-33-PureMVC-Framework

I think mostly for the benefit of code generation in Flex Builder, because when you have the Generate functions inherited from interface checked in the New ActionScript Class dialog it generates function that you would typically override in that class. Take, for instance, ICommand, it generates the execute method. Other than that, as you mentioned, there's no absolute need to implement the relevant interface.

getProxyName is used internally in the view in the registerProxy method to get the name of the proxy, however, this functionality is defined in org.puremvc.patterns.proxy.Proxy. Take a look there and as long as you pass the proxy's name to the base class's constructor. The only time you would really need to use getProxyName is if you were implementing your own custom implementation of the Proxy class or aren't passing the proxy's name to the base class constructor.

I've been wrestling with some issues that have impeded me from releasing the initial version of the framework. I'm hoping someone has some experience that can shed some light on this:

The problem revolves around how Python's import operation works at runtime. I initially followed this methodology (for example):

from org.puremc.python.core.view import View

which imported the View class from the org.puremc.python.core.view module.

This method of importing works fine, until the import becomes cyclical. Meaning module A imports module B. Later down the line B imports A. this works fine in compiled languages, but in Python, the interpreter has yet to finish interpreting A because it has not finished with B.

After some research, it appears the best methodology is to just use a standard import and import the entire module. This solves the import problem, however now the classes need to be referenced by the entire package name and certain modules can't be found:

class MacroCommand( org.puremvc.python.patterns.observer.Notifier, org.puremvc.python.interfaces.ICommand, org.puremvc.python.interfaces.INotifier ):
AttributeError: 'module' object has no attribute 'observer'

The Python documentation is sparse at best at how import functions. I know there was a previous problem with cyclical import with the standard import, but it appears that "from _module_name_ import cls" was never checked or fixed.

This is a major roadblock and as far as I can see the only one at the moment.

The only immediate solution I know of is to break down the package structure and just have everything reside at a root level, possibly in a single file. I really don't like this solution as it breaks standards and file structure with the other PureMVC implementations.

I've attached the framework code as it is now (standard import implemented atm), but it's untested due to this import issue and I don't want to think of committing it to the repository until that is done.

Sounds interesting Joel, Are you thinking of using PyGame, or some other framework for your graphics?

So, I think it's a good idea to start throwing around some ideas for how to showcase the Python port. I think a few general things have been mentioned such as server-side applications and desktop applications running off 3rd Party GUI frameworks. I've mostly been looking into the desktop area, but I'd love to see any ideas anyone has.

As far as desktop development goes, wxWidgets uses classes similar to how MXML works (since MXML compiles down to AS3 objects, then down to swf) so I think this would be a good starting point, especially for people who may have programmed in Flex and are wanting to explore the Python code.

So far, the Python implementation is identical to the original AS3, syntax differences between the two languages aside. I'm finishing up the documentation (hopefully tonight). I will be running some unit test tomorrow to make sure everything works (my primary concern at the moment is the functionality of the singletons, but I will be posting detailed information on how I resolved this later on).

So, lets hear some ideas!

You could always store a setting on the user account as to whether that account has an associated email box. When the account creation is successful, you then run a command that checks to see if this option is enabled in the account, and then if it is it generates another notification to start the mail box creation command. This could also work in reverse, that when the user disables the email option, the system dispatches a notification to delete the associated email account.

Thanks Cliff, glad to be of service!

How is your database setup? Is it an object-relational database? It it is, I would have a VO to represent a data row from each table, then have a single Proxy handle the relationships between the related VO's. However, if you happen to have other tables in the same database that don't relate to these tables, they should be in another proxy. you should basically separate things by what type of service the Proxy is offering. Less is almost always more.

As far as the [Bindable] tag, you can only use it on either object variables or explicit get/set function pair. Since getData is just a regular function the[Bindable] tag won't work on it. At any rate, in PureMVC you want to do it a little differently.


This basic principle of all this is Proxy->Notification->Mediator->View->Datagrid. Hope that helps:

First you would have your concrete Proxy send a notification that the data has changed by passing the data in the body of the notification. In your Mediator's listNotificationInterests() function you have that particular notification listed in the returned array. Then in the Mediator's handleNotifications, you have a switch statement that switches through the values of note.getName(). when you handle the case that is your particular notification you simply get the data note.getBody(), cast it to the appropriate data type, and then assign this to a public property in your view.

This public property should be [bindable], which you then bind to the dataProvider property in your datagrid. When you set the public property through your Mediator, Flex detects this, and tells the datagrid to update because it is bound to it.

@Henk

(insert general disclaimer due to lack of rest and the fact that this is off the top of my head):

If you have a Macro command that needs to handle asynchronous events, you could break the command apart at the aasynchronous points, and have everything past that point be another macro command (and so on and so forth). You can then register each part of that original macrocommand (now macrocommands/simplecommands themselves) to certain notifications. Then you could simply have initial command activate whatever asynchronous Flex activity you're going to do in the proxies, then that particular command goes away since it's done executing. Once the proxy detects the asynchronous operation is done, it sends a notification that begins the next series of commands and so on until you are done.

In a way, the commands would be used as pseudo-delegates, they simply get executed when their notifications arrive. :-)