Diez, thank you for taking the time to write that. I think it would be useful to have some of what you've written added to the json doc. =)
Iain > >> Most solid doc on this topic is: > >> > >> http://docs.turbogears.org/1.0/GettingStarted/JSON > >> > >> You can explicitly control how objects are converted to json using the > >> jsonify decorator. There's an example in the json.py file created by > >> quickstart. I have not fully explored jsonify (it was added during one > >> of my periodic breaks from TG), so I haven't written a reference > >> jsonify doc. > > > > What about docs or books ( non-gears too I mean ) on what the best way > > to do this kind of thing is, as far as the architecture and object > > implementation? > > > > I finally got the stuff working ok with an implementation of the cart as > > a session object that sub classes list. This *seems* to make it's json > > behaviour the closest to how I am using it in python code and js code, > > but I'm sure it's not the most elegant approach. > > The general problem you see here is known as marshalling. It means to > define ways how data is to be represented as a stream of bytes to move > it between two processes - regardless of where these processes live, on > one machine, or two connected via a network, or even separaded by time - > then its about persistence. > > The process of taking in-process data and producing a stream of bytes is > marshalling, the inverse is called unmarshalling. > > All inter process communication (IPC) standards like CORBA, COM, XMLRPC, > RMI, SOAP and so on minimally define a marshalling standard. > > JSON is such a standard too, albeit _not_ a IPC mechanism. And it lacks > quite a few things, like encoding specification, for which it relies on > the transport protocol HTTP. But it is simple and powerful, especially > in the context of javascript-to-server communication. > > Bob's SimpleJson knows how to produce correct JSON-formatted data from > python's built in primitives and standard collection types. Now this > leaves us with the need to convert our self-defined classes to a bunch > of objects that are understood by SimpleJson. > > But to do so, it is not necessary to subclass from the builtins, as you > seem to assume! > > There are two ways to accomplish this: > > 1) make an object perform the work itself. This is done in TG via the > means of the __json__-method. If an object has such a method defined, > and is returned from a TG controller, the method will be called to > obtain a jsonable representation. So you could accomplish what you need > like this: > > class ShoppingCart(object): > > def __json__(self): > return { > "number_of_items" : len(self.items), > "items" : self.items > } > > > This is certainly way cleaner than tayloring the implementation so that > it is implicitly representable. > > 2) Use a external method/code that gets an object and inspects it to > create a json-representable object. This is called a decortor or visitor > pattern - I'm actually not sure about these pattern stuff, it's all kind > of blurry and trivial to me, but that might well be my ignorance. > > In TG, this is accomplished using TurboJson. You should investigate into > the jsonify-decorator and related code. It is brought to use for your > projject in a file called json.py in your projects primary package > directory. If you use identity support, it will be prepopulated with > code like this: > > @jsonify.when('isinstance(obj, User)') > def jsonify_user(obj): > result = jsonify_sqlobject( obj ) > del result['password'] > result["groups"] = [g.group_name for g in obj.groups] > result["permissions"] = [p.permission_name for p in obj.permissions] > return result > > > As you can see, there is a test given as a string that will be evaluated > against an unknown object to see if the decorated method is to be > invoked to return the json-compatible representation of the object. If > so, it is invoked with the object in question. > > With these two approaches, you can fine-grained control, what and how to > serialize using JSON. I personally prefer the second approach, as the > first method makes an object know something about its usage that I > consider to specific. A e.g. model object could be used in a context > that is totally unrelated to web-programming - and thus it shouldn't > know how to represent itself in JSON. > > Diez > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
