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