Class aliasing

by Nick Joyce :: Rate this Message:

I have been unhappy with the way pyamf handles strongly typed classes for a while now (pyamf.register_class). It can be cumbersome to have fine grain control over attribute handling (unless you want to subclass pyamf.ClassAlias but that is quite advanced and not really suitable for the general user) as well as having to have one register_class per class alias. I have never been quite sure how to improve upon the code without reducing functionality etc.

Today I added `register_package` which takes a module and registers all the classes in the module with the supplied package name. An example:

import pyamf

from myapp.mypackage import models

pyamf.register_package(models, 'com.myapp.mypackage')

I have been using this one a couple of personal Django projects I have been tinkering with for a while and it has reduced the LOC needed to get PyAMF up and running quite a bit. There is a number of params that can be supplied to the function. If you are interested, I suggest you take a look at the docstring [1]. Any further suggestions/improvements are welcome!

It would probably be worth pointing out that this helper function is not limited to Django. :)

Next, I would like to make a proposal. I have liked the way projects apply meta to the class definitions (GAE Datastore, SQLAlchemy ORM classes, Django models the list goes on ..) and that got me thinking. What if we could come up with a way to apply meta information to the class and have PyAMF introspect the class either pre-emptively or jit? Probably best to give an example of what I am thinking ..

A typical VO in Flex:

package samples.contact {

[RemoteClass(alias="samples.contact.Contact")]

public class Contact {

public var contactId:int;

public var firstName:String;

public var lastName:String;

public var address:String;

public var city:String;

public var state:String;

public var zip:String;

}

A class in Python with AMF meta applied:

class Contact:

class __amf__:

alias = 'samples.contact.Contact'

amf3 = True

class attributes:

static = ('contactId', 'firstName', 'lastName', 'address', 'city', 'state', 'zip')

exclude = ('foo', 'bar')

def __init__(self, **kwargs):

# do some work ..

This would remove the requirement for pyamf.register_class altogether.

If you do a lot of work with Django you will see a parallel with the Meta class attribute for their model definitions [2].

Hopefully this code snippet should be fairly self explanatory - if not let me know and I will try to explain the purpose of each of the attributes. The great thing about the __amf__ class attribute is that is it project agnostic. This means that if projects like AmFast implemented this feature, people could use either project without any integration problems!

Please let me know what you think! Is it useful or am I just burning brain cycles? If it is useful then perhaps everyone (including the developers from the two projects) could bang heads and come up with a formal definition that works for all?

Looking forward to your feedback!

Nick

[1] - http://pyamf.org/browser/pyamf/trunk/pyamf/__init__.py#L1371

[2] - http://docs.djangoproject.com/en/dev/ref/models/options/

_______________________________________________
PyAMF users mailing list - users@...
http://lists.pyamf.org/mailman/listinfo/users

« Return to Thread: Class aliasing