Using AOP to allow developers to add logic in the pointcuts handlers (or aspect in AspectJ) should be interesting approach. If not mistaken some other projects like Tuscany already support AOP with AspectJ to allow extension with developers code via the custom logic on some published pointcuts.
Another way is maybe to introduce some kind of lifecycle with some predefined phases to the gadget rendering request. Shindig then could allow developer to register before/after handlers for each phase via Guice modules. Just my 2 cents. - Henry On Thu, May 13, 2010 at 12:37 PM, Paul Lindner <[email protected]>wrote: > On Thu, May 13, 2010 at 12:16 PM, John Hjelmstad <[email protected]> wrote: > > > On Thu, May 13, 2010 at 12:01 PM, Paul Lindner <[email protected] > > >wrote: > > > > > hrm.. > > > > > > Due to the ordered magic of ImmutableSet we do get things injected in > the > > > correct order: > > > > > > > I sort of figured that to be the case, though I'm still a bit loath for > > important behavior to depend on quasi-magic (Guice :)) combined with > what's > > arguably an accident of implementation details rather than a prescribed > > API. > > > Okay, let's change the signature to List<String> so it's explicit then (as > you describe in the paragraph below). This also allows one to override > the > provider in another module using Guice 2.0 Override mechanisms. > > In our particular case, we'd be reasonably well-served by simply > @Inject'ing > > > a List<String> into FeatureRegistry constructed via the two Sets > > (String.split and Set<..> extended), guaranteeing at least relative order > > of > > those two (and order of the features provided by the comma-delimited > > String. > > > > Since this gives users flexibility to guarantee order when they _really_ > > need to do so, and to perform one-time extensions past that, this seems > > generally reasonable, if not totally ideal. > > > > > > > > > > > > > So I believe this is safe to apply as-is. Still it seems like there > > should > > > be a better way to do this. The use cases I can see that we might need > > to > > > address: > > > > > > * Override default features (works by insuring that we add user > features > > > last). > > > > * Removing features from the default. Trickier... Currently you have to > > > copy features.txt and remove the ones you don't want. Might make sense > > to > > > have a blacklist of features you don't want to support. > > > > > > > The former case here seems pretty common; the latter isn't possible > today, > > so I'd bucket it as a "new feature" once it's demanded. > > > Okay. > > > > > Agreed that Set/Map injection via contributor style is a laudable goal, > and > > I appreciate you/we are moving toward it. But I'm a bit loath to invent > > some > > kind of ordering-fu (Comparator for instance) as an especially-magical > > implementation requirement for ordering... hmm... > > > > > Another simpler option is to have separate sets for each rewriter phase, > ala > Apache Httpd modules > > http://httpd.apache.org/docs/2.0/developer/request.html > > This could be done with multibindings or AOP pointcuts... >
