We are in the middle or prepping 0.3.1 which will add more compatibility for frameworks like Google App Engine etc.

I still think pyamf is a better solution that json for this work. Specially considering that in json there is almost no support for circular references, and this is quite handy!

So that pyamf does not support right now google’s objects for serialization I think is a matter of time. I am sure these guys will be working on that. Then probably there will be no need for most VO and only for some specific classes where you really need a transfer object instead of the raw model objects.

In any case I have the impression we will have to change our mind a little bit from the java world and their relational persistence frameworks, as this is not the same as Big Table in Google.

Javier, you have the same idea. I want automatic deserialization on the raw object.

So, I’m not convinced on pyAMF yet. I’m currently working with JSON off a plain HttpService. That seems to be close. With the example Pet Model, I can do this Flex-side:

// result is a set of JSON serialized pets
var rawData:String = String(event.result);
var pets:Array = (JSON.decode(rawData) as Array);
for (var i:int=0; i<pets.length; i++) {
var pet:Object = pets[i];

// you gotta use object.fields, but at least it’s a real object
status_txt.text += “Name: ” + pet.fields.name + “\n”;
status_txt.text += “Type: ” + pet.fields.type + “\n”;
}

I’ll document that more fully if I get it all working.

Thanks for the discussion anyway. All cool work.

I would like to be able to do like with JPA in Java that I can just send objects to the client, modify them there, send them back and automatically reattached them to the persistence layer. In this case you have to make the work on the services, or DAOS if you have them, of reconstructing objects in order to persist them.

I am very interested on what other people are doing architecting their applications on the Python side.

By the way I have the AMFPHP Browser working with PyAMF and your GAESWF project. It is quite handy for testing the services.

Thanks Aral!

It’s coming :)

It’s just because I’m passing the raw user object from Python back and that’s how the properties are in it (you’re getting the response from the users.get_current_user() method in webapp.)

You can easily create a simpler object and return that (I’m doing that in several of the calls.) That a look at the login() method in /services/user.py (and also checkout the ProfileVO object in the updateProfile() method of the same module.

_User__email = myemail@xyz.com

Can that be used with something like “user.email”?