Attached is a *very* simple demo of a blog demo I wrote using PMVC Python and Google App Engine. This was more or less a proof of concept/test to see how PureMVC could integrate with the framework. I don't have a hosting account under App Engine yet, but you can download App Engine yourself and run the demo locally. Instructions on how to do so are in the install.txt file in the zip.

Right now it only includes basic post functionality and a home page that shows all posts. Also, undocumented right now but I will come back and fix that on the next update.

If you can understand the uncommented code, I'd certainly appreciate feedback on my integration here.

Update:

PureMVC Python Google App Engine Demo - Blog Announcement

The project has been moved to: https://github.com/PureMVC/puremvc-python-demo-gae-blog/wiki

You can check "Show Inaccessable Member Variables" in the expression panel too and it fixes the problem with the notification there as well because the notification's variables are all private. Still working on figuring out why you can't see the constants (I'm getting similar problems in my own projects). I think it may be because it is looking for a variable named "ApplicationFacade", instead of realizing it's just a class that you're trying to get a static const off of. I would guess thats just a FB3 bug.

I would load up the WebOrb console and take a look at the code generation section, it provides AS3 code for connecting to each of your services.

Also, be sure to make sure there are no errors in your Java code.

PureMVC's Proxy takes two arguments in the constructor: the name of the Proxy and the data object. When you subclass Proxy you have two choices:

1. Pass a new VO to the data parameter in the base class constructor:

public function LoginProxy () {
     super( NAME, new LoginVO() );
}

2. Pass it into you own constructor when you instantiate your Proxy (which is what you are doing).

I'm guessing that when you create your LoginProxy your code looks like this:

facade.registerProxy( new LoginProxy() );

In which case, the data parameter in your constructor defaults to null, and then gets passed to the base class constructor.

Could you post a snippet of your code, shizny?

The only thing I can think of that could be causing this is if your notifications are within a transaction block.

I've got the documentation working, just working through some bugs in the async code now.

Just thought I'd share this little tidbit of code I wrote tonight. It's mostly a helper class, but handles opening the files and running the appropriate functions you pass to it.

It allows for either synchronous or asynchronous read/write of data to local files on AIR using a FileStream.

If you go synchronous you simply pass a function that takes a FileStream as its only parameter and serializes your data to it.

For asynch, you need to create an object that implements either/both of IFileReadResponder or IFileWriteResponder and pass it to the asynch methods. Put the read/write code in the onComplete method, should probably rename it for clarity.

I've also attached a mini AIR app that tests the synchronous code (haven't yet fully tested the asynch code, but fairly sure it works).

You'll also have to excuse the lack of comments (will do at later date), but much of the code is pretty self explanatory.

In the command you use to create the new mediator, after it has been instantiated, send a mediator creation complete notification, which the original mediator listens for. When the original mediator receives this notification, send a new one with the VO which the new mediator listens for. It's a bit complicated for sending just a VO, but it keeps the mediators decoupled from each other.

Yes, I think it would be appropriate for you to take over as project lead since you've done most of the worst to getting the port running, it's more your baby than mine. I'll mention it to Cliff and he should be able to get you set up with the repository and other information.

Great job, btw!

I have re-written from scratch in conjunction with v 2.0.1

some issues:

At the moment  the facade class must always be imported using:

import *
NOT
from * import *

this means any references to constants in the AppFacade class must include the full package path which is annoying.

Best solution would be to use import as to define a local name for the module:

:

import com.dehavilland.test.app as app
then later:

:

app.AppFacade.TEST3

Also the Facade.getInstance and AppFacade.getInstance point to different locations in memory, does this matter? I was trying to think where this may break the application.

Not quite sure, but the best thing to do next would be to rewrite the unit tests (of course taking into account the differences in implementation). If the unit tests run fine then I believe we can commit the code to the repository and begin coding apps!

Thanks Toby, glad to have a strong Python programmer on the team!

Sounds good, I have source code updated to version 2, I'll upload it later so you don't have to spend time rewriting all the functions.

There is a circular import in the facade / notification area which unfortunately cannot be avoided.

The python port cannot simply be a modified version of the code, it needs to be completely re-designed into a python structure.

I will have a look at some options and see if i can find a new solution for the python port.

Yes, I believe that's where I had run into the problem before. I have read that using plain import can handle circular imports, but if I recall correctly, this raised other issues.

I guess that's my C language background working against me.

Hopefully we can find a workaround.

I have the Python port in a working state, i will upload asap.

Sounds good, I look forward to seeing it. Thanks a bunch :-)

I'm still working on it, hopefully I should be arriving at a conclusion one way or another in the next week or so.

You could always have a MEDIATOR_REGISTERED notification that you send each time after you call registerMediator. You could then pass the name of the mediator in the body so that when mediators get the notification, they can only respond to ones with their name in the body. Unfortunately, since if you remove them, they no longer receiver notifications, this solution will not work for notifying the Mediator that it has been removed.