On Thu, Jan 14, 2010 at 10:03 AM, Vidar Ramdal <[email protected]> wrote:
> > On Jan 14, 2010, at 7:30 AM, Vidar Ramdal <[email protected]> wrote: > >> I often write PostProcessors to catch a modification to a resource or > >> property based on certain criteria. > >> [...] > > On Thu, Jan 14, 2010 at 3:40 PM, Justin Edelson <[email protected]> > wrote: > > +1 to the registering PostProcessor for specific resource types. > > > > I'm less sure of registering by property name and modification type, > mostly > > because you'll still need to iterate through the modification list. > > Yes, but that iteration is often duplicated in postprocessors (in my > case, anyway), so it would be useful to centralize it. > > We could introduce a new method (in a new interface extending > SlingPostProcessor): > public void process(Modification modification, List<Modification> > allModifications>, SlingHttpServletRequest req); > The 'modification' param would be the actual modification that this > postprocessor is subscribed to. 'allModifications' would be the same > old modification list. I'm including it because I often inspect other > modifications when deciding what to do with the subscribed > modification. > Ah. I didn't realize you were talking about a new API method. In this context, property-based registration makes more sense. But if we're going to change the API, how about replacing List<Modification> with a more "intelligent" object so you could write code like this: if (changes.wasPropertyModified(MY_PROPERTY_NAME)) { // do something here } > > Also, it seems like there could be ambiguous cases, e.g. If I register a > > PostProcessor with modifiedPropertyNames = [ 'title', 'description' ], > does > > the PostProcessor get called when only one of those properties is called? > > We would have to define what to do in those cases. In your example, I > would say the PostProcessor gets called twice, once for title, and > once for description. > If you want your PostProcessor to get called ONLY when BOTH properties > are modified, you could of course just iterate through the > modification list just as before, and return early from process(). > But anyway, we need a clear definition. OK. This will just need to be well-documented (like everything else). > >> It strikes me that this would make registering a SlingPostProcessor > >> somewhat similar to registering a Servlet. Maybe there are some > >> synergies here. > > How about registering PostProcessors on paths, just like we do with > servlets? That would allow for fine-grained registering, like multiple > /postprocessors/resourceType/propertyName registrations, and even > /postprocessors/anyResourceType/propertyName. Somewhat like Servlets, it seems you should be able to register a PostProcessor for a particular (resource) path using, say, sling.postprocessor.paths OR a particular resource type using, say, sling.postprocessor.resourceTypes, but not both at the same time. I don't think it makes sense to use an artificial path structure like /postprocessors/foo/bar. resourceType="foo/bar" is much cleaner and more intuitive. Unlike Servlets, however, if you want a PostProcessor to apply to *all* resources, you don't need an "anyResourceType" (or sling/servlet/default) identifier. Simply not having either sling.postprocessor.paths or sling.postprocessor.resourceTypes set should indicate the global behavior. This is necessary for backwards compatibility. Justin
