cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Passing null values in parameters, part 2 )
Date Sat, 03 Oct 2009 11:52:21 GMT
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.


View raw message