lazr-users team mailing list archive
-
lazr-users team
-
Mailing list archive
-
Message #00007
Re: integrating lazr.restful into Grok
On Jun 22, 2009, at 2:30 PM, Martijn Faassen wrote:
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..).
Hi Martijn. While I don't have much experience with Grok, I have been
using lazr.restful in Mailman 3. The idea is to provide an
administrative interface to the system using REST.
I'll agree that it's fairly complex and difficult to do right now.
Gary, Leonard, and Francis have all been very helpful, but it should
be much more apparent from the package's documentation about what you
need to do to use it. I think Leonard is thinking about how to make
many of these things easier and I hope to help him with that if
possible.
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.
Very true. If you want a working, albeit limited example you can
check out this branch:
https://code.launchpad.net/~mailman-coders/mailman/3.0
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.
Yep.
lazr.restful.publisher.WebServiceRequestTraversal
into my request.
Yep.
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.
I got around this by cleverly crafting my Configuration object. I set
path_override to None and service_version_uri_prefix to '3.0' and now
my urls look like http://localhost:8001/3.0/system
for one of the objects in my root.
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.
I don't think so, but I'm also not crazy about _rVHT(). It does make
things more complicated.
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.
Me too! I think there should actually be less Zope and more WSGI, but
I'm not at all an expert on how to do that.
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..
There some really excellent things about lazr.restful. I think the
warts are mainly due to the history of the package. It grew out of
stuff Leonard et al did to add the REST interface to Launchpad. As
more third party and non-Zope applications try to use it, more things
can be generalized and simplified. You should be able to just
annotate your interfaces, define in a simple way your object traversal
scheme, and that's about it.
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...
Right. lazr-developers is the team that controls the official
branches, lazr-users is the discussion team/list. This changed
recently, and I've updated the parent lazr package to reflect this,
but I think Leonard, Francis, or Gary will update lazr.restful the
next time it's released.
-Barry
Attachment:
PGP.sig
Description: This is a digitally signed message part
References
