On 26.10.2013, at 09:49, Justin Edelson <jus...@justinedelson.com> wrote:
> Why does the workflow engine have to make that decision itself? Can't > that decision be expressed declaratively? They are, after all, being > defined declaratively by the administrator, so it should just be a > matter of mapping the administrator's selections to a filter > expression and then letting the EventAdmin implementation handle the > filter. For example, you could have a workflow launcher expressed as a > listener with a filter of > "(&(resourceType=nt:file)(path=/content/dam/*/original))". Yes, but someone needs to be able to implement that - this would include more, not only a resource type check, but any property, e.g. (someProperty!=somevalue). Whether this is in the workflow or in the event admin doesn't matter for my POV, both are above Oak in the stack. Even firing the event admin in OSGi would be wasted resources if you can know upfront - while you have access to the content being changed - that you don't need to fire the event at all. > NOTE - I'm not necessarily saying that everything in CQ's workflow > engine is supported by Sling Resource events *today*; there might be a > need to add new event properties, but that's far from impossible. > > My point is that it is in large part the lack of good filtering (which > is available in EventAdmin and JMS) is what leads to having multiple > dispatching systems in the same applicatio and that good filtering is > already available in Sling applications *because* of the > Observation/EventAdmin bridge. We are talking about performance and scalability, and I think for that it is best handled as early as possible. Cheers, Alex
