Guice configuration - setRenderer

[Abe Music <ab...@gmail.com>]

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

Re: Guice configuration - setRenderer

[Jasvir Nagra <ja...@google.com>]

On Fri, Aug 7, 2009 at 11:10 AM, Kevin Brown <et...@google.com> wrote:

> On Fri, Aug 7, 2009 at 10:10 AM, Abe Music <ab...@gmail.com> 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<et...@google.com> 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 <ab...@gmail.com> 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
> > >>
> > >
> >
>

Re: Guice configuration - setRenderer

[Kevin Brown <et...@google.com>]

On Fri, Aug 7, 2009 at 10:10 AM, Abe Music <ab...@gmail.com> 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.

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


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.


>
> 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<et...@google.com> 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 <ab...@gmail.com> 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
> >>
> >
>

Re: Guice configuration - setRenderer

[Abe Music <ab...@gmail.com>]

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<et...@google.com> 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 <ab...@gmail.com> 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
>>
>

Re: Guice configuration - setRenderer

[Kevin Brown <et...@google.com>]

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 <ab...@gmail.com> 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
>