Eric Dobbs wrote:
> That is a correct and well described assessment of the problem,
Thanks :-)
> I think the primary problem is in the structure of the Criterion
> object. There is a need to abstract the connecting conjunctions
> and to control the placement of parentheses. The current means
> of abstracting those is to hold two pointers, one for 'and' and
> one for 'or'. As you have nicely pointed out, there's no way
> to control the predidence.
Right. OK, I first thought of a quick solution to set a flag
whether the and- or or-chain binds stronger, with this you could
get the given example right. But by no means you have a generally
correct/usable solution with this for expressions of a
greater depth.
> I further think that the whole implementation
> should be hidden behind facade methods in Criteria. The .and()
> and .or() methods recently added to Criteria are a step in the
> right direction.
After seeing these methods we hoped the issue had been addressed
already and tried it with the new version. But, what these
methods currently do, is near to "nothing", it has nothing to
do with our problem. I think it will be difficult to get that
functionality in Criteria itself, as long at it is based on
a Hashtable. As I read it in the mentioned thread, you have
recognized this, too.
> In the thread I mentioned above, I attached
> incomplete but functional sample code which you can get here:
> http://www.mail-archive.com/[email protected]/msg00023.html
> What do you think of that?
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.
> That proposal has grown considerably in
> scope and I don't expect it to be resolved any time soon.
> I appreciate that you have attempted to make your changes without
> breaking existing code. But I think your solution makes an
> already ugly situation more so. Please don't take that wrong.
> My primary objection is to the existing code. I would prefer to
> deprecate the existing methods and replace them with a better (or
> at least less ugly) solution.
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.
With my code, there would be such a quick solution that
- works (again, no guarantee, but who gives such a thing..)
- preserves existing structures / compatibility
- only adds something one can use or not, and not too much of it
(less than 200 locs)
- allows real general expressions in the where-clause
- for the less complex applications like the discussed
example does not require noticeable more code:
crit.add(a1.and(b2).or(a5.and(b3)));
->
crit.add(crit.getNewConnector(a1.and(b2),a5.and(b3),Criteria.CONN_TYPE_OR));
Sure, the solution is kind of ugly, with respect to its
embedding into the existing situation. But on the other hand,
with respect to functionality and the general expressions you
can build with it, it seems not so bad to me (perhaps because
I did it ;-)
OK, please think about it again, it would be great if you could
add it.
As for a greater rewrite and deprecation: it probably is necessary
in the long run. Though as a user of turbine in a not-so-small
project we are not really keen on such things :-)
Thanks.
--
Florian Lindauer
_________________________________________
SecureNet GmbH * http://www.secure-net.de
Phone +49 89/32133-662 * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
