Eric Dobbs wrote:
> > given example in the howto is, well, simply wrong. So I think
> > there really should be a quick solution.
>
> Agreed.
> How does that strike you?
Just trying to argument you into taking my diff. This strikes me
in so far as I could be sure not to have to change things after
the next update.
But, of course, if there is a better solution there then,
and a well described one, it is OK too. What I am hoping to prevent is,
that for the next updates we always have to patch in this missing
functionality ourselves.
> Let the SimpleCriterion just represent a basic comparison, like
> 'a>1' or like 'b in (1,1,2,3,5)'. And let the CompositeCriterion
> Hold two Criterion (simple or composite) and a conjunction. I
> think that will provide a nice compromise between the solution
> you have offered and my original.
>
> An alternative would be to work with the existing Criterion. Let
> the 'or' and 'and' objects be renamed to 'left' and 'right'. Add
> a String property named 'conjunction'. A SimpleCriterion would
> have nulls for 'left', 'right', and 'conjunction'. A
> CompositeCriterion would have nulls for 'table', 'column',
> 'value', and 'comparison'.
>
> I think the former would more elegant, but the latter might break
> less existing code.
Both sound OK to me. With the latter, you might even manage to
do it without changing the interface, so without breaking any code
at all (and making code like in the example working correctly
after all). A call to and/or always would lead to creation of a
new composite version which is returned. (Not rethought in detail)
Florian Lindauer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
