On Fri, Aug 7, 2009 at 11:10 AM, Kevin Brown <[email protected]> wrote:
> On Fri, Aug 7, 2009 at 10:10 AM, Abe Music <[email protected]> wrote: > > > This goes back to a previous message about wanting to supply a new > > servlet that I can hit via XHR that will produce only the cajoled code > > for a given gadget XML file. As it stands now, the > > GadgetRenderingServlet is hit via /gadgets/ifr and will build the > > entire HTML file so that the rendering can be handed off to an iframe. > > What I would like is a new servlet to be hit via /gadgets/inline that > > will only give me back the cajoled gadget code (no HTML, no support > > code, etc) This new servlet will also need to be able to support new > > parameters such as whether to use valija mode and it will also need to > > be set aside from existing code so I don't mess anything up with the > > current GadgetRenderingServlet's workflow. > > > > I have this all working so far with a custom > > InlineGadgetRenderingServlet (a copy of GadgetRenderingServlet) > > except I've had to modify bits of the existing Shindig code to do > > certain things. This is (obviously) unacceptable to the Shindig > > community and would like to do it the right way so I can give this > > code back. This assumes that the community would like to have a > > working implementation of inline gadgets versus iframe gadgets. Where > > I'm getting hung up is how Guice handles the injection of various > > objects and how to make it use my new objects only when hitting my > > custom rendering servlet. > > > > The particular bits of code I speak of are: > > > > 1) Various XML files to point /gadgets/inline to my custom rendering > > servlet > > 2) RewriteModule - comment where the RenderingGadgetRewriter object > > gets added to the list so as not to include the HTML and support code > > to the output > > > > You probably shouldn't modify RewriteModule, and instead just use a custom > module to do the bindings. If you want /gadgets/ifr and your new servlet to > work in the same server, you'll also need to sub class HtmlRenderer so that > you can take separate rewriters for each variant. > > That said, I don't think a new servlet is the right way to go about this. > It > would make more sense to modify the meta data servlet to return cajoled > code > along with other meta data so that the container only needs to make one > request. This code has gotten a little crufty (I don't think it's been > touched in over a year now), but it was always the intended way to get data > about a gadget. Can you elaborate a bit on this - I am not sure I follow how this would work. In the design you're outlining, what would the container request and what get returned? > > see > > http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/RpcServlet.java?revision=751260 > > > > > > 3) CajaContentRewriter - rw.setValijaMode(false) - to produce cajita > > code instead of valija...a flag should be used to determine what type > > of cajoling you want > Note this flag controls only what the input language is considered to be not what is produced as output - a cajoled gadget will be isolated from another cajoled gadget irrespective of the mode it is cajoled in. > > I'd be very cautious about this. The implications of using valija instead > of > cajita are substantial, and I suspect most people deploying won't > understand > the nuances. I'm a little skeptical about the number of gadgets that will > actually work without valija, though I'm sure the caja developers have more > specific numbers. > A ballpark figure from Codesearch would suggest most javascript written without specifically targeting cajita would of course not work. If container you're building Abe is specifically to develop cajita gadgets, your needs are different. But yes this ought to be a flag. In the absenceof such a flag - a function can declare itself to be in cajita by included a ES5 style directive by including the following statement at the top of the function: "use cajita"; Similarly an entire gadget opt-in to cajita by including "use cajita" as its first line. > > > > > And that's about it....maybe going the rendering servlet way is > > overkill, but I'm not sure how best to provide this new functionality > > in such a way that people could use either iframe or inline gadgets > > and with exposing new GadgetContext parameters. Basically, I don't > > want to be the cause of breaking anything :) > > > > Any ideas? > > > > On Fri, Aug 7, 2009 at 11:40 AM, Kevin Brown<[email protected]> wrote: > > > Servlets are special, and can't use constructor injection because > they're > > > not constructed by guice (they're instantiated by the servlet engine). > In > > > order to get an injectable servlet, you need to extend InjectedServlet, > > and > > > use method injection. > > > > > > Are you sure you want a custom servlet? GadgetRenderingServlet doesn't > do > > > much but delegate to Renderer. It's fairly straight forward to do this. > > You > > > can probably start by just copying GadgetRenderingServlet. > > > > > > On Fri, Aug 7, 2009 at 6:04 AM, Abe Music <[email protected]> wrote: > > > > > >> I've recently been trying to learn and understand how Shindig > > >> leverages Guice to handle its dependency injection and for the most > > >> part I'm getting it all. The two parts where I'm failing to understand > > >> is in GadgetRenderingServlet's setRenderer method and HtmlRenderer's > > >> constructor. Somehow Guice is handling setting the initial renderer in > > >> the servlet as well as the various arguments for the HtmlRenderer's > > >> constructor. The reason I am asking is I want to implement my own > > >> custom rendering servlet that provides new functionality and will not > > >> be able to use the supplied Renderer, HtmlRenderer, etc., and rather > > >> than modifying Shindig code directly I would rather create my own or > > >> extend the functionality of the existing objects. If anyone can help > > >> me make the connection I would greatly appreciate it. > > >> > > >> Thanks, > > >> > > >> Abe > > >> > > > > > >
