Continuing that idea...

Service.CreateWidget(Map);

Response.Send(String);

etc...

Or whatever syntax we can agree on. The cool think about Groovy is we can make 
up our own language.

-Adrian



--- On Sun, 4/18/10, Jacopo Cappellato <[email protected]> 
wrote:

> From: Jacopo Cappellato <[email protected]>
> Subject: Re: Delegator Helper class for groovy?
> To: [email protected]
> Date: Sunday, April 18, 2010, 11:07 PM
> On Apr 19, 2010, at 8:04 AM, Adrian
> Crum wrote:
> 
> > Or "Entity".
> > 
> 
> Yes! "Entity" is better than what I proposed ("Data" or
> "Select") for sure!
> 
> Thanks Adrian,
> 
> Jacopo
> 
> 
> > 
> > --- On Sun, 4/18/10, Jacopo Cappellato <[email protected]>
> wrote:
> > 
> >> From: Jacopo Cappellato <[email protected]>
> >> Subject: Re: Delegator Helper class for groovy?
> >> To: [email protected]
> >> Date: Sunday, April 18, 2010, 10:47 PM
> >> Very nice idea.
> >> 
> >> What about "Select" instead of "Query"?
> >> Or, if you plan to also use the "Query" class also
> to
> >> create/update/delete records, we could name it
> "Data" or
> >> similar.
> >> 
> >> Jacopo
> >> 
> >> On Apr 18, 2010, at 11:23 PM, Scott Gray wrote:
> >> 
> >>> How about we create a new Query class that
> simplifies
> >> using the DelegatorInterface?
> >>> Mostly for groovy but we could use it in java
> as
> >> well:
> >>> Query.Product.where(Map).one();
> >>> Query.Product.where(Map).list();
> >>> Query.Product.where(Map).iterator();
> >>> 
> >>
> Query.Product.where(EntityCondition).orderBy(String|List).list();
> >>> 
> >>
> Query.Product.where(EntityCondition).orderBy(List).useCache().list();
> >>> 
> >>
> Query.Product.where(EntityCondition).having(EntityCondition).orderBy(String).useCache()
> >>> 
> >>> 
> >>
> Query.new()."Product".where(expr).orderBy("productId").useCache().list();
> >>> 
> >>> Basically you start with
> Query.<EntityName> and
> >> finish with one(), list() or iterator()
> >>> Every method except for those last 3 return
> the Query
> >> object so you can continue to build it out by
> chaining
> >> method calls.
> >>> 
> >>> Query building methods:
> >>> where(Map | EntityCondition)
> >>> having(Map | EntityCondition)
> >>> orderBy(String | Collection<String>)
> >>> useCache()
> >>> range(Integer start, Integer size)
> >>> range(Integer size)
> >>> 
> >>> Should cover most of the use cases and I think
> it
> >> would be more intuitive than trying to deal with
> the
> >> delegator's huge API.  Any thoughts?
> >>> 
> >>> Thanks
> >>> Scott
> >>> 
> >>> HotWax Media
> >>> http://www.hotwaxmedia.com
> >>> 
> >> 
> >> 
> > 
> > 
> > 
> 
> 



Reply via email to