Was not delegator methods thought to hide SQL code ? I think that David meant
to prune not to replace. In both case such a changes
implie
major tedious refactoring. Though using deprecated concept it could be carried
on carefully in time...
I like the idea of replacing the cache avatars by a parameter. It implies a lot
of tedious refactoring too...
For the idea below, I like it as enhancement (compiled query being a must) not
a replacement, which is a paradox because this
thread was about to prune.
Jacques
PS : I added David's initial message a bottom to not lose the thread
+1 for the "less is more" concept. I guess deprecating is the way, no time to
fill the list yet...
> David mentioned recently that the delegator has quite a number of
> methods in it; this can be daunting to new users.
>
> If it could handle sql natively, then this could be reduced.
>
> EntityCondition condition = new EntityConditionList(
> UtilMisc.toList(
> new EntityExpr("firstName", EntityOperator.LIKE, "%Adam%"),
> new EntityExpr("lastName", EntityOperator.LIKE, "%Heath%")
> ),
> EntityOperator.AND
> );
> List people = delegator.findByConditionCache("Person", condition, null,
> UtilMisc.toList("firstName", "lastName"));
>
> ... or ....
>
> Query query = delegator.compileSql("SELECT * FROM Person WHERE firstName
> LIKE $firstName AND lastName LIKE $lastName ORDER BY firstName, lastName");
> query.setParameter("firstName", "%Adam%");
> query.setParameter("lastName", "%Heath%");
> List people = delegator.runQuery(query);
>
> The compiled query could be cached, or created during an init phase;
> this would speed things up. Additionally, views could also be done with
> this sql code. And the sql string could be generated by a template;
> meaning that whole parts of it might be conditional, using
> freemarker/velocity conditions, both on joins, and regular group
> by/order by/select fields/conditions.
>
De : "David E Jones" <[EMAIL PROTECTED]>
>
> This has been discussed before, but I thought it might be a good time
> to bring it up again based on Adam Heath's recent additions to the
> GenericDelegator (in revs r585808, r585803, r585802, r585759).
>
> One of the issue with the Entity Engine that has been getting worse
> over the years is method bloat. There are WAY too many variations of
> different methods, IMO. These have been added for convenience, but
> the net effect (that I don't think was expected or even considered)
> is that when looking at the massive list it is tricky to figure out
> which methods to use for what. This is a big problem for people new
> to the Entity Engine, but also a problem for experienced EE users.
>
> In short lately I'm thinking that having so many methods is worse
> than the convenience they offer to make life easier for "lazy"
> coders. Actually, with a decent IDE having lots of parameters isn't
> such a big deal.
>
> This does have the down side of requiring changes to lots of existing
> code to use the fully featured methods instead of the simplified ones
> (most of which just call the full featured ones with default values).
>
> The up side is we end up with a really happy and clean
> GenericDelegator class with only maybe 10-15 methods for different
> general operations, and perhaps even less than that, like 5-10...
> (aside from the cache maintenance methods, and other utility methods,
> many of which we might want to make private, the general goal being
> to simplify the class).
>
> In shorter I think this is getting to be one of those cases where
> less is more...
>
> Any thoughts? Should we start mass-marking methods as deprecated?
> Which ones and in what forms of the methods should we leave?
>
> -David
>
>
