On Thursday, May 31, 2001, at 03:56 AM, Florian Lindauer wrote:
> I think it should be working, from what I can say after reading the
> code.
> Though, it seems not completely "elegant" to me, if it is to be used
> as a base for a greater rewrite of code (Ok, you spoke of using it
> as an interim solution). The concept of the connector
> to be "in front of" the SimpleCriterion is somewhat "unnatural". Think
> of a Criterion you create. You might want to use it in two different
> contexts (the same object). You cant do such a thing with this, as
> as soon as it gets connected with another criterion, the connector
> for the connection of those two gets set in the second criterion.
> Naturally, a connector should be part of a Connector object that
> holds only references to the objects to be connected. Well, just
> like its done in my proposal ;-)
> But really, this would correspond to the nature of expressions as
> hierarchical tree-structures much better.
I agree the original suggested code is not elegant enough. The
part I care about is being able to interchange simple criterion
with complex criterion. So Criterion is an abstract class,
SimpleCriterion and CompositeCriterion are subclasses. All
client code can be programmed to the api provided by Criterion.
I think it's important for the simple and complex cases to
present the same interface, even for the short term solution.
Your comments, along with a review of Fedor's counterproposal,
have given me another idea. In my original design I was trying
to support cases like this: '(a>1 and a<=5 or b=10 and c=1)'.
But it makes sense to build our api to require us to disambiguate
the conjunctions, like this:
((a>1 and a<=5) or (b=10 and c=1))
or this:
((a>1 and (a<=5 or b=10)) and c=1)
With that in mind...
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.
>> That proposal has grown considerably in
>> scope and I don't expect it to be resolved any time soon.
>
> Above you say "not any time soon"... But, the current
> state does not allow any complex where-clauses, and even the
> 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?
-Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
