De : "David E Jones" <[EMAIL PROTECTED]> > On Oct 19, 2007, at 9:24 AM, Adam Heath wrote: > > > Adrian Crum wrote: > >> 2. Reduce all of the findByXxxx and findAll methods to a single find > >> method that takes a FindParameters class. A separate worker class > >> could > >> convert all of the various arguments currently being sent to the > >> myriad > >> findXxxx methods and condense them into a FindParameters instance > >> that > >> is passed to the single find method in the delegator. End result: +1 > >> find parameters worker class, -23 delegator methods. > > > > In effect, that's what already happens; most code eventually calls > > findByCondition. > > > > Additionally, this could simplify the sql generating parts too. > > My original thought was to review these (23? wow...) methods and > deprecate (and later remove) nearly all of them. The main ones I > think should remain are: > > 1. a findListIteratorByCondition method with all possible parameters > 2. a findByAnd method with all possible parms > > ... and I think that's about it for the finds. Both would have a new > parameter called "useCache". The findByAnd is just there for > convenience as that is a common use case.
+1, Yes I prefer that way, less name easier to understand with parameters in it. Actually, this is why the parameter concept is used for, isn'it ? > The idea of a query parameters object is interesting. If we do > something like that we should look at some ways of reducing the lines > of code required to use it. I think that's the only part of it I > don't like... lots of lines of code. +1. I found Adam's suggestion interesting but a bit verbose (or too near SQL rather). Maybe it was intended, since Adam suppose everybody know well SQL. Which is false, I'm really bad at it for instance. > Whatever the case, I think the most important thing is that we not > rush this. There are lots of less effective ways to do this (like the > one we have now...), so the key is to avoid introducing something > that is just as cumbersome/annoying. There are already good ideas, exchanging about them before implementing anything is reassuring. And maybe we will even find better or complementing ideas... Sorry I have none, just following for now Anyway it seems that Adam, who is the most active on this issue, will not have time for it in the next days (weeks, months ?). So we have gotten time to think, hoping we will not forget to do (I speak mostly for myself here :o) Jacques > -David > >
