lazr-users team mailing list archive

[Martijn Faassen <faassen@xxxxxxxxxxxxxx>]

Hi there,

I'm having a hard time trying to integrate lazr.restful into Grok.
This is some feedback/random whining about my experiences.

The configuration to set things up is complex configuration even for
experienced Zope developers, and a demo Zope project would be
tremendously helpful to beginners. It also didn't help that it wasn't
easy to find out (from the documentation) what kind of URLs are
actually exposed by the application, so it was hard to determine
whether my test URLs were actually legitimate (I got a *lot* of
NotFound errors..).

Of course you can point out that there is an example:
lazr.restful.example. I think this serves too many purposes though -
it's there for testing purposes and for example purposes. As a result
it isn't a "this is how you get started quickly" example. It requires
a lot of digging to find out how to configure it to get it going. I'd
like to see something you can check out and run the buildout for that
just works, with some comments in the code to see what's going on and
some ideas about which example URLs can be called.

As an experiment, I took the code in lazr.restful.example and dumped
it into a Grok project. I turned the CookbookServiceRootResource into
a grok application so I could install it.

I had a problem with 'Cuisine' in interfaces, as it's an enumerated
thing of some kind and the system would report it is duplicated when I
copied over the class. This is behavior one usually doesn't expect
when copying a class..

The ftesting.zcml of lazr.restful also changes the security policy to
make the example work, and this is also easy to miss.

Integration wasn't made easier by the fact that Grok already defines
its own publication and request factory. I still don't know how to
resolve that properly.

After a lot of hunting around I figured I needed a skin that's in the
IWebServiceRequest layer to see anything at all, or at least some
exceptions; I believe I now resolved it by making my custom request
object implement this layer.

After a lot of digging I found out I should mix in these classes:

lazr.restful.publisher.WebServicePublicationMixin

into my publication.

lazr.restful.publisher.WebServiceRequestTraversal

into my request.

After a lot more hacking, I got something where at least the service
object returns some JSON. The individual resources didn't return JSON
though, so I hacked some more, disabling the whole
_removeVirtualHostTraversal logic, and now the individual bits (such
as dishes) return JSON, though the service object itself won't.

_removeVirtualHostTraversal is extremely sensitive to changes in the
URL space. It likes:

/api/1.0

and nothing else.

Things I tried were:

/service/api/1.0

where 'service' is the name of my root resource.

and:

/++skin++test/api/1.0

to place the request in the right skin.. but it's sensitive enough to
disregard both as legitimate requests. As a result, I don't like
_removeVirtualHostTraversal very much. It makes too many assumptions
about URLs. Even after I took it out, the URLs generated by the system
are still incorrect after my hacking, so this assumption is more
wide-spread in lazr.restful.

On the long term I don't think Grok's and lazr.restful
publisher/traversal hacking are sustainable. The Zope Toolkit approach
is already overly complex and we're only piling on the complexity.. I
hope we can find some better way.

Conclusions: I still like lazr.restful's approach. This hacking has
given me a grand tour of lazr.restful's codebase. To integrate it with
something like Grok I need to think very carefully about what should
be done - perhaps I use only bits of lazr.restful and write my own
publication integration for the time being..

Regards,

Martijn

P.S. This mailing list is not advertised anywhere as far as I can see.
Instead the lazr.restful HACKING document tells me that if I want to
discuss this package, I should join the team and mailing list here:
https://launchpad.net/~lazr-developers...