Kevin, Thanks for the reply! It sounds like this is something you've thought about before :) Hopefully a few more questions is all I need to ask and I can get underway with some code. I'm looking into some code that extends the GadgetContext that you recommend (HttpGadgetContext, OAuthGadgetContext, and JsonRpcGadgetContext) and I'm just struggling with understanding the overall architecture of Shindig and how everything plays with each other. Is there a wiki or some documentation that details how GadgeContexts work with Renderers and everything? If not that's OK too, but just trying to get up to speed as fast as possible.
One other thing...It looks as though the GadgetRenderingServlet is what takes advantage of the HttpGadgetContext....I probably shouldn't replace that GadgetContext with my own right? I'm thinking that I need to "call" my custom GadgetContext from my container somehow, but not sure how to invoke it. Any suggestions or point in the right direction would be much appreciated. Thanks again! -- Abe On Thu, Jul 30, 2009 at 12:29 PM, Kevin Brown<[email protected]> wrote: > If you're using java shindig, you can do this pretty trivially: > > 1. Create a custom GadgetContext and have getParameter("caja") return "1". > 2. Feed this into the "Renderer" class. > 3. The result is a cajoled gadget. > > Now, there are a few caveats: > > - In the current shindig setup, caja is very expensive. This is because we > parse, serialize, parse, serialize, and parse again when cajoling. The caja > developers have promised a change to their interfaces that will eliminate > this overhead, but it's not in yet. > > - Many gadget libraries are not tamed, so you'll want to tread carefully > when it comes to which gadgets you choose to render in this manner. Stick > with gadgets.io, gadgets.util, and opensocial.* and you'll be fine. osapi, > and most "legacy" features aren't tamed yet, though you could do this work > yourself if you need to support them. > > - gadgets.rpc won't work out of the box. You could probably just replace it > with a simple implementation that calls the same domain. > > - Many gadget libraries assume that they are the only library in the page. > It might be easier to just cajole the shindig libraries along with the > gadget rather than trying to tame them. > > On Thu, Jul 30, 2009 at 8:53 AM, Abe Music <[email protected]> wrote: > >> Hello all, >> >> I'm new to the list, but have been using shindig for a while, however, >> my involvement up to this point has only been writing gadgets and >> handing them off to shindig for rendering. I have recently been tasked >> with creating a "secure" container using the Caja project with >> Shindig. I've started messing around with the caja feature and have >> verified that it works enough for us to get started with our project, >> but I have a few architecture-related issues I need to get clarified >> before moving forward. >> >> I understand that Shindig renders gadgets in their own iframes for >> security reasons, however, since we will be leveraging caja to provide >> "virtual sandboxes" we would like to remove this iframe dependency and >> stuff the gadget content directly into HTML elements instead. The >> overall look and feel to the container page would be exactly the same. >> It should also reduce the overhead of the containing page and assuming >> that Caja lives up to its name the iframe shouldn't be required any >> longer. So, here I am trying to wrap my head around the idea of using >> shindig to supply rendered gadget content to my container page. I >> anticipate that this will require changes to both the server and >> client aspects of Shindig as well as the caja feature, but I wanted to >> pose my thoughts to the group before moving forward. >> >> I'm thinking the workflow for my project would go like this: >> >> 1) Build an HTML page that defines all gadgets that need to be >> rendered and kickstart the rendering process through XHR?. This page >> would need to have the Valija runtime to support cajoled gadget code >> and somehow make the runtime aware of all gadgets as they are >> rendered. >> >> 2) For each gadget to be rendered I would somehow have Shindig supply >> the DHTML of the rendered gadget directly instead of in an iframe >> >> 3) Using that DHTML I would somehow leverage the Valija runtime to >> build out the cajoled gadget in separate containers in the HTML page >> >> 4) We now have a secure container page? Yeah, that sounds about right... >> >> Now then, #1 I believe is trivial, but #2 and #3 are where things >> start getting hairy. For #3 we no longer stuff the content into an >> iframe by supplying the src parameter and having shindig build out >> rendered gadget code on the fly for the iframe to present. Instead the >> rendered gadget code would have to be stuffed into the containing html >> elements manually at runtime on the containing page. It can't possibly >> be as simple as asynchronously requesting rendered gadget code (via >> the /gadgets/ifr URL ???) > > > /gadgets/ifr would have a bunch of other stuff that you definitely wouldn't > want. Try my steps above and you should be good, though. > > >> from shindig and stuffing the response >> (DHTML) into a div via setting its innerHTML property? The rendered >> gadget content using the caja feature bakes all required code into the >> content (domita, valija , etc), therefore, a lot of the supporting >> feature code would need to be modified to produce only the code that >> should be dumped in the html element and leave Caja-runtime tasks up >> to the containing page. Also, does anything on the server side need to >> change? Shindig, to my knowledge, is not responsible for creating any >> iframes or handling anything special on behalf of the client side, but >> I really don't know. >> >> General questions: >> >> 1) What needs to be done on my part? I'm perfectly fine with knocking >> out some code to support my efforts, but I really need to be pointed >> in the right direction. >> >> 2) If I am to modify the caja feature to support what I'm trying to do >> would it be best to only have the gadget renderer cajole the gadget >> and only return the JS as a script and asynchronously load those in >> the containing page? I'm thinking something along the lines of: >> <script src="/gadgets/ifr?url=..."></script> >> >> 3) Anything else I need to be aware of? I would really like to get a >> good discussion going so that we (Shindig, Caja, and my project) can >> start hashing out what it's going to take to get where we need to be. >> I can't possibly think that my questions are original (in fact I found >> a few threads on this very thing), but I would really like to help >> move things along so everyone can benefit. I think that both Shindig >> and Caja are both great projects and would love to see something like >> what I've described start coming to fruition. If there are projects >> out there doing similar work that anyone knows of please let me know! >> >> Thanks for the help! >> >> -- Abe >> >
