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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > On Tue, May 27, 2008 at 11:47 AM, John Hjelmstad <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. > > >
