On Tue, Jul 5, 2022 at 11:27 AM Andrus Adamchik <aadamc...@gmail.com> wrote:
> I would agree if we had a superclass that includes *all* callbacks as > empty methods with fixed names (which we don't for performance reasons). > What we have instead is user-defined (in the Modeler) callback methods with > custom names. Two problems with it: > > 1. Logical: Most callbacks are meaningless in the context of the mapping. > So arguably this is the wrong place for them. (The only case I know of > where a callback belongs in the model is setting defaults in PostAdd. Which > points to the need to simply add "default" value to ObjAttribute and not > use callbacks for this. > 2. Practical: When I am adding a callback, I am usually in the midst of > coding some application function, and don't even have the Modeler open. I > have to (1) open the modeler, (2) declare a callback method, (3) regenerate > Java classes and (4) override the method in subclass and implement it. > Looks wasteful, as I can simply do #4 with annotations. > Well, there IS a common superclass... If using a convention-over-configuration event-name scheme (like Tapestry), you could have onPostAdd(), onPrePersist(), etc, in the superclass. 1. Commonly used PostAdd to "repair" schemas from year-to-year. Say the schema changed between 2014 and 2015. The UI/app only supported year 2015, but needed to load in prior years. The PostAdd would then update the objects on the fly to be compatible with 2015 so you could view, copy, edit, save, etc. As the schema evolved, the PostAdds would dynamically repair the objects. Worked well and didn't require even more complex DB migration updates. These updates could be far more complex than simple default values. 2. I can't believe you don't have the modeler open! :-)
