[Java] Is anyone writing custom GadgetFeatures?

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

This code seems overwrought at this point in time. John H originally wrote
this code under the assumption that extending the platform would best be
done by writing new java classes. In practice, that has proven unnecessary
for the most part since most features are implemented entirely in
javascript, and the stock js feature loading works pretty well for this.

I'd like to clean up and simplify this code by removing the processing here,
but if anyone's actually depending on it we'd need to approach it more
cautiously. Ideally I'd like to do two things:

- Simplify the primary task (loading javascript-based features)
- Provide easy access to <Params> so that the few features that actually
aren't pure javascript at this point (locked-domain and content rewriter)
can get access to data that they need more easily.

The first part is fairly straightforward, the second can vary in complexity
from a simple getParams(foo) (mirroring the javascript interface) to an
AOP-style plugin system. Guice helps a bit if the latter is necessary, but
at this point it doesn't seem to be.

Re: [Java] Is anyone writing custom GadgetFeatures?

[Paul Lindner <pl...@hi5.com>]

At hi5 we haven't felt the need to customize this layer.

Clean as much as you want..

On May 24, 2008, at 8:22 PM, Kevin Brown wrote:

> This code seems overwrought at this point in time. John H originally  
> wrote
> this code under the assumption that extending the platform would  
> best be
> done by writing new java classes. In practice, that has proven  
> unnecessary
> for the most part since most features are implemented entirely in
> javascript, and the stock js feature loading works pretty well for  
> this.
>
> I'd like to clean up and simplify this code by removing the  
> processing here,
> but if anyone's actually depending on it we'd need to approach it more
> cautiously. Ideally I'd like to do two things:
>
> - Simplify the primary task (loading javascript-based features)
> - Provide easy access to <Params> so that the few features that  
> actually
> aren't pure javascript at this point (locked-domain and content  
> rewriter)
> can get access to data that they need more easily.
>
> The first part is fairly straightforward, the second can vary in  
> complexity
> from a simple getParams(foo) (mirroring the javascript interface) to  
> an
> AOP-style plugin system. Guice helps a bit if the latter is  
> necessary, but
> at this point it doesn't seem to be.

Paul Lindner
plindner@hi5.com

Re: [Java] Is anyone writing custom GadgetFeatures?

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

Yes. There's lots of dead (untested, bug waiting to happen) code all over
because of it, and so far every new feature that isn't just javascript has
required a lot of custom work and hasn't been able to fit into the prepare /
process model at all. The code itself is useless for shindig proper, this
thread is just to determine whether anyone integrating shindig had found use
for it, and so far the answer looks like "no".

Even if the model is still desired, Guice's support for AOP would probably
be a lot cleaner way to get this kind of support. The natural "join points"
are in extending GadgetSpecFactory and in the content filters (Louis has
already been doing this for rewriting, and the locked domain code could
easily fit in here). Remaining functionality is mostly covered by standard
servlet filters.

On Tue, May 27, 2008 at 3:50 PM, John Hjelmstad <fa...@google.com> wrote:

> Well, I'm aware of several parties interested in building custom
> GadgetFeature functionality using prepare/process stuff. Is the added tax
> of
> GadgetFeature really that awful given JsFeature's existence and proven
> utility?
>
> John
>
> On Tue, May 27, 2008 at 3:32 PM, Kevin Brown <et...@google.com> wrote:
> On Tue, May 27, 2008 at 11:47 AM, John Hjelmstad <fa...@google.com> wrote:
>
> > I'm unclear on precisely what cleanups you plan to do here. The
> particulars
> > of what you mention sound fine to me - I'm always game for clearer code.
> > What, if any functionality would you be removing?
>
>
> GadgetFeature and all related processing code would be removed entirely,
> with JsFeature largely retaining its existing functionality.
>
>
> >
> > --John
> >
> > On Sat, May 24, 2008 at 8:22 PM, Kevin Brown <et...@google.com> wrote:
> > This code seems overwrought at this point in time. John H originally
> wrote
> > this code under the assumption that extending the platform would best be
> > done by writing new java classes. In practice, that has proven
> unnecessary
> > for the most part since most features are implemented entirely in
> > javascript, and the stock js feature loading works pretty well for this.
> >
> > I'd like to clean up and simplify this code by removing the processing
> > here,
> > but if anyone's actually depending on it we'd need to approach it more
> > cautiously. Ideally I'd like to do two things:
> >
> > - Simplify the primary task (loading javascript-based features)
> > - Provide easy access to <Params> so that the few features that actually
> > aren't pure javascript at this point (locked-domain and content rewriter)
> > can get access to data that they need more easily.
> >
> > The first part is fairly straightforward, the second can vary in
> complexity
> > from a simple getParams(foo) (mirroring the javascript interface) to an
> > AOP-style plugin system. Guice helps a bit if the latter is necessary,
> but
> > at this point it doesn't seem to be.
> >
>

Re: [Java] Is anyone writing custom GadgetFeatures?

[John Hjelmstad <fa...@google.com>]

Well, I'm aware of several parties interested in building custom
GadgetFeature functionality using prepare/process stuff. Is the added tax of
GadgetFeature really that awful given JsFeature's existence and proven
utility?

John

On Tue, May 27, 2008 at 3:32 PM, Kevin Brown <et...@google.com> wrote:
On Tue, May 27, 2008 at 11:47 AM, John Hjelmstad <fa...@google.com> wrote:

> I'm unclear on precisely what cleanups you plan to do here. The
particulars
> of what you mention sound fine to me - I'm always game for clearer code.
> What, if any functionality would you be removing?


GadgetFeature and all related processing code would be removed entirely,
with JsFeature largely retaining its existing functionality.


>
> --John
>
> On Sat, May 24, 2008 at 8:22 PM, Kevin Brown <et...@google.com> wrote:
> This code seems overwrought at this point in time. John H originally wrote
> this code under the assumption that extending the platform would best be
> done by writing new java classes. In practice, that has proven unnecessary
> for the most part since most features are implemented entirely in
> javascript, and the stock js feature loading works pretty well for this.
>
> I'd like to clean up and simplify this code by removing the processing
> here,
> but if anyone's actually depending on it we'd need to approach it more
> cautiously. Ideally I'd like to do two things:
>
> - Simplify the primary task (loading javascript-based features)
> - Provide easy access to <Params> so that the few features that actually
> aren't pure javascript at this point (locked-domain and content rewriter)
> can get access to data that they need more easily.
>
> The first part is fairly straightforward, the second can vary in
complexity
> from a simple getParams(foo) (mirroring the javascript interface) to an
> AOP-style plugin system. Guice helps a bit if the latter is necessary, but
> at this point it doesn't seem to be.
>

Re: [Java] Is anyone writing custom GadgetFeatures?

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

On Tue, May 27, 2008 at 11:47 AM, John Hjelmstad <fa...@google.com> wrote:

> I'm unclear on precisely what cleanups you plan to do here. The particulars
> of what you mention sound fine to me - I'm always game for clearer code.
> What, if any functionality would you be removing?


GadgetFeature and all related processing code would be removed entirely,
with JsFeature largely retaining its existing functionality.


>
> --John
>
> On Sat, May 24, 2008 at 8:22 PM, Kevin Brown <et...@google.com> wrote:
> This code seems overwrought at this point in time. John H originally wrote
> this code under the assumption that extending the platform would best be
> done by writing new java classes. In practice, that has proven unnecessary
> for the most part since most features are implemented entirely in
> javascript, and the stock js feature loading works pretty well for this.
>
> I'd like to clean up and simplify this code by removing the processing
> here,
> but if anyone's actually depending on it we'd need to approach it more
> cautiously. Ideally I'd like to do two things:
>
> - Simplify the primary task (loading javascript-based features)
> - Provide easy access to <Params> so that the few features that actually
> aren't pure javascript at this point (locked-domain and content rewriter)
> can get access to data that they need more easily.
>
> The first part is fairly straightforward, the second can vary in complexity
> from a simple getParams(foo) (mirroring the javascript interface) to an
> AOP-style plugin system. Guice helps a bit if the latter is necessary, but
> at this point it doesn't seem to be.
>

Re: [Java] Is anyone writing custom GadgetFeatures?

[John Hjelmstad <fa...@google.com>]

I'm unclear on precisely what cleanups you plan to do here. The particulars
of what you mention sound fine to me - I'm always game for clearer code.
What, if any functionality would you be removing?

--John

On Sat, May 24, 2008 at 8:22 PM, Kevin Brown <et...@google.com> wrote:
This code seems overwrought at this point in time. John H originally wrote
this code under the assumption that extending the platform would best be
done by writing new java classes. In practice, that has proven unnecessary
for the most part since most features are implemented entirely in
javascript, and the stock js feature loading works pretty well for this.

I'd like to clean up and simplify this code by removing the processing here,
but if anyone's actually depending on it we'd need to approach it more
cautiously. Ideally I'd like to do two things:

- Simplify the primary task (loading javascript-based features)
- Provide easy access to <Params> so that the few features that actually
aren't pure javascript at this point (locked-domain and content rewriter)
can get access to data that they need more easily.

The first part is fairly straightforward, the second can vary in complexity
from a simple getParams(foo) (mirroring the javascript interface) to an
AOP-style plugin system. Guice helps a bit if the latter is necessary, but
at this point it doesn't seem to be.