[Zope3-Users] url traversal and jsonserver

[Pete Taylor]

On 4/18/06, Jim Washington <jwashin at vt.edu> wrote:
> Pete Taylor wrote:
> > hi all,
> > i've been looking at jsonserver recently, and am very impressed.
> > however, my question doesn't really involve jsonserver functionality,
> > so much as it does a bit of url traversal indirection.
> >
> > i have a simple "dashboard" like approach to a particular user
> > interface design, where most of the content displayed to the user is
> > determined by content associated with her/his principal id.  like
> > principal annotations sorta, only I needed/wanted a little more direct
> > control.  also, all of the content for a user is held in a
> > registration utility, in ++etc++site.  i've been using viewlets and
> > formlib to give the users access to their data without actually having
> > it in the standard traversal path.  that way no smart user can think
> > "hmm, my url is some/path/my_user_id, let me ry some/path/johnsid"
> > etc.  to them my.site/Consumer" is all they need to see, which I like.
> >
> > what i would like to do is set up jsonrpc:view's for a number of the
> > different content objects that the user has access to in her/his
> > content directory.  the trouble, for me, comes in when i need to give
> > the javascript a ServiceProxy address.
> >
> > while i can probably figure out how to pass a particular url path to
> > the javascript through some tales construction, it occurs to me that
> > the object that jsonrpc view is actually providing a json-rpc view ON
> > is under ++etc++site.  i can't really pass that to the javascript,
> > since I don't think ++etc++site is going to let the javascript (with
> > the current principl's authority) connect.
> >
> > so what I'm wondering about is how to expose content held in a
> > traversal path like
> > "http://my.site/++etc++site/MyRegistrationUtility/ConsumerStuff/some_user_id/stuff"
> > to a json-rpc ServiceProxy.
> >
> > is it possible?  is there a way i could get at this more indirectly?
> > would principal annotations provide a better means of url exposure for
> > picking up a serviceproxy?
> >
> I would leave the jsonrpc view as a view of the content-space object
> (/Consumer).
>
> jsonrpc requests are in many ways just like other http requests.  In
> particular, request.principal is available to the view.
>
> Since the data you want is keyed to the user, you can do a utility
> lookup or an adaptation inside your view code using the principal object
> as a key to get (or set) the data.  Then you do not need to deal with
> troublesome urls at all.
>
> -Jim Washington
>


hmm, that's an excellent thought, i hadn't considered doing it that
way (obviously ;) ).  i was trying too hard to tie the jsonrpc view to
the objects i wanted to manipulate, rather than considering how to
expose the functionality from where i was.

thanks :)

--
"All guilt is relative, loyalty counts, and never let your conscience
be your guide."
  - Lucas Buck, American Gothic