On 4/18/06, Jim Washington <[EMAIL PROTECTED]> 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 _______________________________________________ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users