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 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 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 >> >
