I like the chaining stuff, I have always loved function composition, in 
computing also

Jacques

From: "Adrian Crum" <adri...@hlmksw.com>
Anything that makes Java/Groovy more fluent will get a big +1 from me.

-Adrian

On 12/8/2010 1:00 PM, Scott Gray wrote:
On 8/12/2010, at 4:29 AM, Adam Heath wrote:

I've deprecated findByAnd locally, replacing calls with a variant that
takes a boolean, which specifies whether to use the cache.

Initially, my replacement just added a new findByAnd.  However, I'm
now starting to lean towards replacing with findList instead.
However, in my opinion, I think that will make programming ofbiz more
difficult.

I'd like to add a findList variant, that takes a Map instead of an
EntityCondition.  Without this new variant, there would be ton of
variants that would only need to import EntityCondition, just to
create a condition.

There are also performance considerations to consider.

EntityCondition.makeCondition(Map) directly takes the map, doing no
processing.  However, EntityCondition.makeCondition(Object...)
eventually calls EntityUtil.makeFields, which does a little more than
UtilMisc.  In addition to the iteration over the array, it also does a
check on the value for Comparable/Serializable.  This latter check
seems a bit superfluous, as eventually the base condition classes
check the values against the model.

So, from a purist stand point, even tho findByAnd could be replaced by
findList, I think it is too useful; it saves enough code in
application layers, imho.


This reminded me of the query objects with method chaining that I suggested a 
while back so I threw them together this morning.

Here are some examples:
thisContent = delegator.findByPrimaryKeyCache("Content", 
UtilMisc.toMap("contentId", assocContentId));
// becomes
thisContent = EntityOne.query(delegator).from("Content").where("contentId", 
assocContentId).cache().find();

List productNodesList = delegator.findByAndCache("ProductAssoc", UtilMisc.toMap("productIdTo", productId, "productAssocTypeId", bomType));
productNodesList = EntityUtil.filterByDate(productNodesList, inDate);
// becomes
List productNodesList = EntityList.query(delegator).from("ProductAssoc").where("productIdTo", productId, "productAssocTypeId", bomType).cache().filterByDate().list();

List<GenericValue>  inventoryItems = delegator.findByAnd("InventoryItem", ecl, 
null, null, null, false);
// becomes
List<GenericValue>  inventoryItems = 
EntityList.query(delegator).from("InventoryItem").where(ecl).list();

// all this (long winded example)
EntityFindOptions efo = new EntityFindOptions();
efo.setDistinct(true);
efo.setResultSetType(EntityFindOptions.TYPE_SCROLL_INSENSITIVE);
if (maxResults != null) {
     efo.setMaxRows(maxResults);
}
eli = delegator.findListIteratorByCondition(dynamicViewEntity, whereCondition, 
null, fieldsToSelect, orderByList, efo);
// becomes
eli = EntityList.query(delegator).from(dynamicViewEntity).where(whereCondition).select(fieldsToSelect).orderBy(orderByList).distinct().cursorScrollInsensitive().maxRows(maxResults).iterator();

They aren't necessarily shorter, but they are easier to write, easier to read and would be easier to remember (for things like groovy).

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com




Reply via email to