Delegator Helper class for groovy?

[Scott Gray-2]

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

[Scott Gray-2]

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.

[Jacopo Cappellato-4]

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
>

[Adrian Crum-2]

Or "Entity".


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

> From: Jacopo Cappellato <[hidden email]>
> Subject: Re: Delegator Helper class for groovy?
> To: [hidden email]
> 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
> >
>
>

[Jacopo Cappellato-4]

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 <[hidden email]> wrote:
>
>> From: Jacopo Cappellato <[hidden email]>
>> Subject: Re: Delegator Helper class for groovy?
>> To: [hidden email]
>> 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
>>>
>>
>>
>
>
>

[Adrian Crum-2]

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 <[hidden email]> wrote:

> From: Jacopo Cappellato <[hidden email]>
> Subject: Re: Delegator Helper class for groovy?
> To: [hidden email]
> 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 <[hidden email]>
> wrote:
> >
> >> From: Jacopo Cappellato <[hidden email]>
> >> Subject: Re: Delegator Helper class for groovy?
> >> To: [hidden email]
> >> 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
> >>>
> >>
> >>
> >
> >
> >
>
>

[Adrian Crum-2]

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 <[hidden email]> wrote:

> From: Scott Gray <[hidden email]>
> Subject: Delegator Helper class for groovy?
> To: [hidden email]
> 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
>
>

[Scott Gray-2]

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 <[hidden email]> wrote:
>
>> From: Scott Gray <[hidden email]>
>> Subject: Delegator Helper class for groovy?
>> To: [hidden email]
>> 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
>>
>>
>
>
>