Update Interceptor

[geoffreywiseman]

This is possibly overkill, and the exact nature of what would be necessary here is unclear, so I'll only go down this path it becomes evident that it can't be solved with concrete feature additions (because then I'll have at least one clear example of what to implement here).

This would be a little like a Hibernate interceptor -- some piece of code that gets called before/after certain events (e.g. before update, after update, on lookup, etc.) that lets you do pretty much whatever you want.

I'd prefer concrete features to solve specific cases where that works, but it's entirely possible that there will be cases I don't see any other way to solve, or cases that would require concrete features I don't believe make sense for Moo.

[adrianshum]

Just a very simple background of mine: I have done something that feature-wise very similar to MOO, many years ago in my previous job. (Well, feature-wise similar but as I just made it as a little util in mind, the design is not as clean as Moo)

At that time I also provide something similar to an update interceptor. At that time it is mostly used for

1. Complicated transformation. Instead of using MVEL as in MOO, field mapping in my util was only making use of Apache Common Bean Utils for which allows complicated bean property navigation but not external object lookup. However it seems that such scenario can be handled by MOO now
2. Extra initialization of model. It is useful if some property is not available directly in the target DTO but can be derived. For example, in case of parent-child entities, we may want to setup the parent attributes for all child for which corresponding parent attribute is not available in the DTO.

I believe there are more cases that makes interceptor useful and here are only 2 cases that I have faced before :)

[geoffreywiseman]

It might be that the factory support in Moo v2 will help somewhat with the second item in your list, although I'd have to understand the specifics to really say.

It's not so much that I don't see the interceptor concept as being useful, as I don't want to paper over actual features that Moo needs by just using the interceptor to do everything. I'm afraid if I make the Interceptor too early and too powerful, I'll just end up using that to do complicated things in a complicated way instead of trying to find ways to make the complicated things easy using more concrete features.

I think in the long run, having Interceptors is probably a good idea even if I can't come up with a concrete case. In the meantime, I don't mind being forced to build concrete features to support things that come up as they come up.

That said, if someone was waiting on a particular features for Moo, having an option to extend it with the interceptor to build in support would be useful. That's something I can't address directly with features.