On Sep 30, 2009, at 6:21 PM, Evgeny Ryabitskiy wrote:
Without this option I have to variants: 1) Change #bind($....) to $... everywhere and every time pass our special mapping objects to parameters (I will die/be killed by colleges early...).
So this argument is based on the fact that people are using #bind() already. With the new approach they'd just need to optionally change the Java parameter code, and the alternative would be to change both template code as well as Java code. I am still not convinced that the second option is any harder or more confusing. To me the first option is confusing actually - when I pass a binding object, and the directive already has some properties, it is not immediately obvious which set of properties will take effect.
2) Use not general style in SQLTemplate, somewhere with #bind, somewhere not... Firstly it's confusing... Second Is potential errors when I forget where I should pass simple Object and where is special bind object.
Our current approach with Velocity templates is by definition error- prone, as there's no parameter type checking anywhere. IMO adding the new option won't make it better or worse in this respect.
Just like you in this case, I always look at the new API from the point of view of whether it is internally consistent and easy to explain to the end users. In this case I think having "$xyzSpecialObject" as an alternative to an "#XYZ" directive seems like a straightforward symmetrical replacement. At the same time using "#XYZ($xyzSpecialObject $p1 $p2 $p3)" as a way to override some parameters appears indeterministic to an uninitiated person.
Cheers, Andrus
