[Chicago] Help wanted: Python/JS Reflection library

[Brantley Harris]

I have something similar in this one Django app.  Firstly the
serialization process.  It's two step process: serialize a Python
object into a mix of Dictionary/Lists and basic types, and then JSON
serialize it and send it to the client.

It works like this (simplified):

def serialize(object, context):
     dict = {'__class__': object.__class__.__name__,
               '__str__': str(object),
               # Any other default properties...
               }
     object.serialize(dict, context)
     return dict

Then in the object:
class Object:
     ... stuff ...
     def serialize(self, dict, context):
           if (context == 'edit'):
                  dict['something'] = self.something

So it's very easy to define different "contexts".  Thusly serializing
for searching might be different from serializing for "editing".
There's also a deserialize that does the same thing.

Now, on the Javascript side I have this function "remoteMethod" that I
can use, it merely returns a function that acts as an AJAX caller.
Something like:
connectAJAX(object);
object.search = object.remoteMethod('search');

Then I can say "object.search(args);" and it will automatically call
it with a lightweight JSON RPC protocol, serializing as need be.  Then
on the Python side I just map a function to respond to the RPC call.
I'm as pleased as punch by it.  I even have errors that occur on the
server side RPC response pipe back through and into my Firebug
console.  You wouldn't know it wasn't a Javascript error except that
its clearly Python.

Anyhow, it doesn't act like a pure pass-through object, but it works
pretty damned close.  The idea, actually is to make it more seamless
on the Javascript side, as that's the more annoying one to program on.

On 4/4/07, Ian Bicking <ianb at colorstudy.com> wrote:
> Pete wrote:
> > {
> >   "__class__": "Foo",
> >   "color": "red",
> >   "size": 42,
> >   "quux": {
> >     "__class__": "Bar",
> >     "drink": "whiskey"
> >   }
> >   "when": {
> >     "__class__": "datetime.date",
> >     "day": 4,
> >     "month": 4,
> >     "year": 2007
> >   }
> > }
> >
> > This is done entirely via introspection/piggybacking on existing serialization
> > methods - there's no explicit support from Foo or Bar required.  The idea is
> > that some library in language L can take this data structure, which consists
> > solely of JSON datatypes,  and build a corresponding data structure in its
> > native types/user-defined classes. And vice versa.
> >
> > This isn't code shipping - I'm assuming the same person writes the code on
> > both ends.  If you forget to define a Foo in L, that's your bug, not
> > mine. ;-)  It's nothing more than a convention for getting object-oriented
> > data across language boundaries.  Maybe I'll call it Esperanto.[0]
>
> I think "class" is too overloaded a term.  Or perhaps "type" is a
> slightly less overloaded term that might be more applicable.
>
> >> Messages can work, which is what JSON is typically used for.  Messages
> >
> > 'Message reflection' might a better term than 'object reflection'.  The idea
> > is to provide some helpers that let you load up the message into an existing
> > class definition.  It's no more featureful than a bunch of functions that
> > operate on plain-old JSON data structure.  Just adds some sugar.
>
> Maybe a useful way of thinking about it is that you should really be
> communicating "value" objects.  There might be kinds of values beyond
> the basic JSON types (well, certainly there would be), but they feel
> somewhat similar.  That is, they don't really have behavior, and often
> they are immutable (or close to it -- perhaps immutable at least by
> convention).  So you might have a color object like:
>
>    {"type": "color", "r": 255, "g": 0, "b": 0}
>
> It means something other than just a dictionary, or even more than just
> an object that happens to have .r, .g, and .b attributes.  A date object
> is similar.  Python has a bunch of these kinds of objects; I think it
> tends towards the functional than many other dynamic languages.
> Functional languages are purely this kind of object -- especially when
> you start dealing with generic functions, where objects don't appear to
> carry around functionality with them.  I think pattern matching (which a
> bunch of functional languages have) also kind of acts like generic
> functions in the same way.
>
> Hmm... but what does "color" mean?  Seems kind of obvious, but clearly
> there could be other kinds of implementations (e.g., h/v/s, or even
> trivial stuff like red/green/blue).  You could kind of be like XML
> namespaces, and do:
>
>    {"type": "http://purl.com/color", ...}
>
> There's a kind of unambiguous nature to that, and conveniently
> self-describing.
>
> Now I'd say just implement pattern matching in Javascript and Python
> (and whatever else) based on this, along with some conventions for
> message communication (probably just built on HTTP), and have at it!
>
> Along these lines, you might find Roberto Almeida's projects
> interesting: http://dealmeida.net/projects/ -- specifically jsonstore
> and webskine.  I believe most of the UI is really in Javascript.
>
>
> --
> Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
>              | Write code, do good | http://topp.openplans.org/careers
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> http://mail.python.org/mailman/listinfo/chicago
>