Blog - A PureMVC Python / Google App Engine Demo

[Rhysyngsun]

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

[puremvc]

Nathan,

You rule! This works great, and knowing nothing about Python or Google App Engine, I was able to get the demo up in no time. I had neither the engine nor python installed, so I was expecting a big narsty process, but it was smooth.

For Pythoners wanting to see how easy it is to write PureMVC-based applications for Google App Engine take a moment to try this out and then check out the code.

Without having to kill my browser or reboot my Windows XP machine, I was able to quickly Install:

 * Python 2.5.2 http://www.python.org/download/releases/2.5.2/
 * Google App Engine at http://code.google.com/appengine/downloads.html
 * Nathan's Demo App (googleapdemo.zip attached to previous post) to C:\Program Files\Google\google_appengine\googleappdemo

Then opened a Command Prompt and did
C:\>cd C:\Program Files\Google\google_appengine
C:\Program Files\Google\google_appengine>dev_appserver.py googleappdemo

This runs the google app engine, which launches a lightweight webserver on port 8080 (unless there's something already running there, in which case it'll pick another port).

So then you just need to point your browser to this URL:
http://localhost:8080/

[puremvc]

So, what about adding this as a demo to a repository? I don't know if it needs to get much more complex but a modify or remove post might be the extent of it. Then it'd be actually usable as a rudimentary blog. Give the templates some love and you're off to the races.

I don't know Python yet, and I'm really glad. I can look at your source code and completely understand what you're doing. I'll take this opportunity to see if I can really follow it all.

I can see immediately how cool it is that google app engine is providing a database and how easy it is to use in model.py and vo.py. The PostProxy has very simple implementations for adding and retrieving posts. A post is represented by the PostVO which defines its types in terms of database field types defined by the app engine.

The HomeMediator and WriteMediator in view.py are managing templates for the Home and Write a Post pages (index.html and write.html). That's nice because it illustrates how the Mediator pattern remains appropriate for the server side, its just that the view component is a template and that the Mediator isn't really listening to that view component but will write the data into it in response to Notifications. This means the we're not stretching the mediator's responsibilities.

When the facade (defined in main.py) is instantiated, it initializes the controller, and all the command mappings, then triggers StartupCommand with the STARTUP notification which creates and registers PostProxy with the model.

Its a simple REST implementation.

'/' or index.html shows all posts and is handled by homeHandler.

It will only ever be requested by the HTTP GET method, so homeHandler triggers the HomeStartupCommand at its initialization, which creates and registers the HomeMediator. Then it triggers the GetPostsCommand which retrieves the PostsProxy and tells it to retrieve all posts. Then it sends the POSTS_RETRIEVED notification which the HomeMediator hears, retrieves the posts and writes them into the template pushing out the homepage.

'/write' or write.html is handled by writeHandler. '/'. On its initialization, it will trigger the WriteStartupCommand, which will create and register the WriteMediator.

If it was requested by HTTP GET, it will send the VIEW_WRITE_POSTS notification which the WriteMediator will respond to by rendering the write.html template page with the form for making a post.

If it was requested by HTTP POST then you filled the form and submitted, so it will send an ADD_POST notification, passing an object with the title and content key value pairs from the form post as members. This will trigger the AddPostsCommand, which will retrieve the PostProxy, tell it to add the post and then send the POST_ADDED notification. That will be heard by the WriteMediator, who will redirect us to '/' where the posts are displayed, including the new one.

YES!
-=Cliff>

[Rhysyngsun]

Glad to know my code was written well enough to understand easily.

The trickiest part is that when the server runs the script it continues to execute regardless of whether there are any requests from clients. I'm slightly worried how this will affect multiple concurrent client requests since they would theoretically share facade, mediator and proxy instances due to the singleton model. Mostly I'm worried about one client accessing a page and firing off a notification that other clients' request would then respond to.

It was just a quick demo so further testing is obviously necessary.

[puremvc]

True that, testing will be necessary. But I think it could certainly be put into a repository as 1.0, then add fixes from there. I can create that repository with this file structure, hook you up with the write access, etc. Sound good?

-=Cliff>

[Rhysyngsun]

Ok, sounds good to me.

[puremvc]

This demo illustrates techniques for creating a simple blog in a PureMVC-based Python application using the Google App Engine.

The demo is located at http://trac.puremvc.org/Demo_Python_GoogleAppEngine_Blog

The author is Nathan Levesque.

[amb]

there are any requests from clients. I'm slightly worried how this will affect multiple concurrent client requests since they would theoretically share facade, mediator and proxy instances due to the singleton

No threading in App Engine, so no concurrent requests. The main() business is just for AST caching, not for AST sharing.

But still, to be safe, you could add a global mutex.

If you are talking about persisting state *between* requests then you need sessions, no other way around it.

[puremvc]

No reason to keep state in this demo. And no reason to jump through hoops to try. As a demo it has a razor sharp focus of what it does and it gets it done with a minimum of effort.

In short, it's highly readable.

The Python community has only just begun to hear about the PureMVC framework so we want maximum approachability and understandability from demos.

-=Cliff>

[amb]

No reason to keep state in this demo.

It is necessary to keep state, though? I was hoping to use it in real life regardless of its demo status.

[puremvc]

The best way to keep state should be figured out in another demo.

This is a simple demo and it works. It's more advanced than spitting out 'hello world', yet still approachable and understandable.

Pushing the complexity of a demo up also raises the bar to entry; how much you're prepared to try and get your head around before moving on. Above a certain level, many people will simply walk away. One thing I've learned from the project so far is to keep the demos as focused and simple as possible.

There are a few ways one might go about keeping state, that would be in the headers of the request and response objects (cookies), or as key/value pairs (passed as hidden values in form submissions or on the query string). Both approaches have their merit. You'd probably need to manage a session table in the database, so that you could expire session keys after a time. And App Engine has a way of managing user login as well, which should be explored, and would presumably play a part in state-keeping occasionally.

Perhaps you could propose another simple demo that explores management of state with App Engine. It's the beginning of exploration into the usability of the two frameworks. Lets see what we find!

-=Cliff>

[Rhysyngsun]

The demo has been updated to version 1.1. This version includes:

• Edit/Delete post functionality.
• A few changes regarding the view and redirects(see version.txt for further information)
• Comments

It still remains a very simple demo.

amb, the updated demo deals with query strings which may help point you in the right direction. If you want to start a discussion about state in PureMVC Python and Google App Engine that would be great, but probably best for a dedicated thread.