[Grok-dev] Re: shortcut to methods

[Martijn Faassen]

Hey Tim,

[Tim forgot to cc the list, I cc-ed for him]

On 3/19/07, Tim Terlegård <tim at se.linux.org> wrote:
> On Mon, Mar 19, 2007 at 03:40:20PM +0100, Martijn Faassen wrote:
> > Christian Theune wrote:
> >
> > Tim wrote:
> > > > The implementation is almost already there as the xmlrpc grokker
> > > >  uses this approach.
> >
> > >Our XMLRPC view class already does this. Maybe you can take a look at
> > >that implementation to get something for json?
> >
> > Please do note that a few months ago I tried exactly this and got
> > terribly lost in the zope publishing machinery, and gave up. I do really
> > want such a feature for JSON though, and perhaps you can come up with an
> > approach that makes it work.
>
> You don't need to hassle with the publishing machinery. The easy way is
> just to register every method as a view. The xmlrpc grokker does this
> for xmlrpc.

While there may indeed be an easier way than where I ended up, I
obviously did look at the xmlrpc grokker and *still* ended up in the
publishing machinery. The XMLRPC grokker has the benefit of Zope 3's
XMLRCP support already being
there, but the JSON grokker does not.

> > Note also that instead of 'MethodViews' I think you should go all the
> > way, and have a grok.JSON view instead, analogous to grok.XMLRPC. This
> > would take care of serialization of return values to JSON automatically,
> > instead of you having to write simplejson.dumps(self.json) in every
> > single method.
>
> Great idea. I guess it's ok to depend on a specific json package. I
> guess simplejson is _the_ json library for python?

Yes, I think so. It's what TurboGears is using. Just make it an egg
dependency and we should be fine.

> > If you have other use cases besides JSON for MethodViews, please share
> > them with us.
>
> Well, xmlrpc would be one.

XMLRPC is already covered, though.

> REST might be another. Maybe one can factor
> out the "make every method a view" part so it's reusable.

Sure, that would be fine. I just don't see a reason to expose this
directly, at least not if we can expose more helpful stuff like
grok.JSON instead. Of course you
could also expose the infrastructure for those writing new grokkers, too.

> I'll see what I can do.

Great!

Regards,

Martijn