You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Scott Gray <sc...@hotwaxmedia.com> on 2010/04/18 23:23:03 UTC

Delegator Helper class for groovy?

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


Re: Delegator Helper class for groovy?

Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 19/04/2010, at 9:23 AM, Scott Gray wrote:

> Query.new()."Product".where(expr).orderBy("productId").useCache().list();

Ignore this one, I forgot to remove it.

Re: Delegator Helper class for groovy?

Posted by Adrian Crum <ad...@yahoo.com>.
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 <ja...@hotwaxmedia.com> wrote:

> From: Jacopo Cappellato <ja...@hotwaxmedia.com>
> Subject: Re: Delegator Helper class for groovy?
> To: dev@ofbiz.apache.org
> 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 <ja...@hotwaxmedia.com>
> wrote:
> > 
> >> From: Jacopo Cappellato <ja...@hotwaxmedia.com>
> >> Subject: Re: Delegator Helper class for groovy?
> >> To: dev@ofbiz.apache.org
> >> 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
> >>> 
> >> 
> >> 
> > 
> > 
> > 
> 
> 


      

Re: Delegator Helper class for groovy?

Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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 <ja...@hotwaxmedia.com> wrote:
> 
>> From: Jacopo Cappellato <ja...@hotwaxmedia.com>
>> Subject: Re: Delegator Helper class for groovy?
>> To: dev@ofbiz.apache.org
>> 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
>>> 
>> 
>> 
> 
> 
> 


Re: Delegator Helper class for groovy?

Posted by Adrian Crum <ad...@yahoo.com>.
Or "Entity".


--- On Sun, 4/18/10, Jacopo Cappellato <ja...@hotwaxmedia.com> wrote:

> From: Jacopo Cappellato <ja...@hotwaxmedia.com>
> Subject: Re: Delegator Helper class for groovy?
> To: dev@ofbiz.apache.org
> 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
> > 
> 
> 


      

Re: Delegator Helper class for groovy?

Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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
> 


Re: Delegator Helper class for groovy?

Posted by Scott Gray <sc...@hotwaxmedia.com>.
The problem is that the result type is the actual execution method, the query has to have a way to know when to fire.

Regards
Scott

On 19/04/2010, at 6:27 PM, Adrian Crum wrote:

> Using Entity instead of Query and putting the result type after the entity name might be more fluent.
> 
> Entity.Product.One.where(Map);
> Entity.Product.List.where(Map);
> Entity.Product.Iterator.where(Map);
> Entity.Product.List.where(EntityCondition).orderBy(String|List);
> Entity.Product.List.where(EntityCondition).orderBy(List).useCache();
> 
> 
> --- On Sun, 4/18/10, Scott Gray <sc...@hotwaxmedia.com> wrote:
> 
>> From: Scott Gray <sc...@hotwaxmedia.com>
>> Subject: Delegator Helper class for groovy?
>> To: dev@ofbiz.apache.org
>> Date: Sunday, April 18, 2010, 2:23 PM
>> 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
>> 
>> 
> 
> 
> 


Re: Delegator Helper class for groovy?

Posted by Adrian Crum <ad...@yahoo.com>.
Using Entity instead of Query and putting the result type after the entity name might be more fluent.

Entity.Product.One.where(Map);
Entity.Product.List.where(Map);
Entity.Product.Iterator.where(Map);
Entity.Product.List.where(EntityCondition).orderBy(String|List);
Entity.Product.List.where(EntityCondition).orderBy(List).useCache();


--- On Sun, 4/18/10, Scott Gray <sc...@hotwaxmedia.com> wrote:

> From: Scott Gray <sc...@hotwaxmedia.com>
> Subject: Delegator Helper class for groovy?
> To: dev@ofbiz.apache.org
> Date: Sunday, April 18, 2010, 2:23 PM
> 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
> 
>