Received: by 10.68.231.202 with SMTP id ti10mr23429246pbc.5.1329950395766; Wed, 22 Feb 2012 14:39:55 -0800 (PST) X-BeenThere: coldspring-users@googlegroups.com Received: by 10.68.135.164 with SMTP id pt4ls3653202pbb.0.gmail; Wed, 22 Feb 2012 14:39:55 -0800 (PST) Received: by 10.68.241.37 with SMTP id wf5mr23435644pbc.4.1329950395167; Wed, 22 Feb 2012 14:39:55 -0800 (PST) Received: by 10.68.241.37 with SMTP id wf5mr23435642pbc.4.1329950395138; Wed, 22 Feb 2012 14:39:55 -0800 (PST) Return-Path: Received: from mail-pz0-f42.google.com (mail-pz0-f42.google.com [209.85.210.42]) by gmr-mx.google.com with ESMTPS id p7si36722946pbq.0.2012.02.22.14.39.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Feb 2012 14:39:55 -0800 (PST) Received-SPF: pass (google.com: domain of philhaeus...@gmail.com designates 209.85.210.42 as permitted sender) client-ip=209.85.210.42; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of philhaeus...@gmail.com designates 209.85.210.42 as permitted sender) smtp.mail=philhaeus...@gmail.com; dkim=pass header...@gmail.com Received: by mail-pz0-f42.google.com with SMTP id g27so601541dan.29 for ; Wed, 22 Feb 2012 14:39:55 -0800 (PST) Received-SPF: pass (google.com: domain of philhaeus...@gmail.com designates 10.68.243.197 as permitted sender) client-ip=10.68.243.197; Received: from mr.google.com ([10.68.243.197]) by 10.68.243.197 with SMTP id xa5mr94957065pbc.68.1329950395117 (num_hops = 1); Wed, 22 Feb 2012 14:39:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=Ju6PGpdLI3HVJf5axIavv8s7q5c6XwamZb2cwYHh6j4=; b=VjOzl4EzcDfZfnHTEttbwRxKE/9c53vtb/fi0lE4g3wh9tFNNkwhpKk2YkaJaKy3Sp xiK4dwwt03RgrjSxUbtWbhpOW976YqoW5FDi02Wi0fZ3n1xNSlBbfRa2Zq+jSEen/TaW jpopZ1l+xVpkyQS5ArwECRTC0kaEMuH/XRi3k= Received: by 10.68.243.197 with SMTP id xa5mr78042929pbc.68.1329950394948; Wed, 22 Feb 2012 14:39:54 -0800 (PST) Return-Path: Received: from Phil-Haeuslers-MacBook-Pro.local (ppp59-167-188-130.static.internode.on.net. [59.167.188.130]) by mx.google.com with ESMTPS id q3sm20065743pbc.63.2012.02.22.14.39.51 (version=SSLv3 cipher=OTHER); Wed, 22 Feb 2012 14:39:53 -0800 (PST) Message-ID: <4F456EB5.2000...@gmail.com> Date: Thu, 23 Feb 2012 09:39:49 +1100 From: Phil Haeusler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: coldspring-users@googlegroups.com Subject: Re: [coldspring-users] Enhancements to AbstractGateway References: <4F445C67.7040...@gmail.com> <4F44CE23.10...@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080109020803020401070808" This is a multi-part message in MIME format. --------------080109020803020401070808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I do think the GORM comparators are quite neat, particularly around supporting And and Or keywords to combine multiple comparators. Definitely not wanting to reinvent the wheel where we don't have to. The only thing that ColdSpring does differently is allow the sorting to be specified in the method name whereas GORM passes that in as a struct. My original idea was to also allow multiple comparators to be also passed in via a struct. There are benefits for doing it both ways - perhaps there a happy medium we could strike to support both formats. If you're building a dynamic querying capability, being able to pass in the comparators in a struct as well would simplify your calling code, but then supporting the same within the method name does create nice self-documenting code. Looking further, adding support for driving it via an argumentCollection would be another nice CF way of doing things also. What all this basically suggested to me is there are a heap of extension points here and perhaps a nice internal plug-in type architecture to allow the clean separation between the parsing and identifying of comparators and the execution of the resulting query. Then at least adding additional parsers in the future would be simpler and it opens up the possibility of picking and choosing the syntaxes you want to support. That's the direction i'll take with my code, and once i've tested it i'll make it available to Mark as a patch and he can do with it what he wants. Phil On 23/02/12 1:14 AM, Tony Nelson wrote: > If you're going to spend the time and effort, I would suggest creating > something similar to GORM rather than trying to define your own > conventions. > > I implemented something similar to GORM into my framework > (http://www.coldmvc.com/guide/models/orm). I've thought about > splitting it out into its own library so its not so coupled to the > rest of the MVC stack, but I haven't had the time, energy, or desire > to do so yet. > > A nice benefit of following GORM's lead is that (if you do it right) > people can refer to the GORM documentation for how things should > behave. Granted, there are some things in GORM that you aren't able to > fully support (closures, statics), but most of it is pretty > straightforward. > > > -Tony > > > On Wed, Feb 22, 2012 at 6:32 AM, Mark Mandel > wrote: > > I think it's useful - the question I have, is something more akin > to GORM's finder methods be more appropriate? > > What do you think? > > Mark > > > On Wed, Feb 22, 2012 at 10:14 PM, Phil Haeusler > > wrote: > > Hi Brian > > Completely understand and of course that is the approach > anyone should take. I guess what i'm really asking, what do > people think of such an extension to AbstractGateway is it a > useful addition to ColdSpring? > > Phil > > > > On 22/02/12 3:19 PM, Brian Kotek wrote: >> This is a more general comment that applies when using just >> about any framework: You'll make your life much easier later >> if you limit coupling to the framework. In this case, rather >> than having all of your gateways extend AbstractGateway, >> create your own abstract subclass of it and have your >> gateways extend that instead. This not only offers some >> protection if something were to change in the framework >> class, but gives you a place to put your own additions. I >> would NOT recommend altering the framework files directly, it >> will just cause you a ton of pain later when you want to update. >> >> The main exception to this rule is if you want to contribute >> to the framework. In that case, fork the repository, add your >> proposed changes, and send it back to Mark as a patch or pull >> request. :-) >> >> >> >> On Tue, Feb 21, 2012 at 10:09 PM, Phil Haeusler >> > wrote: >> >> Hi everyone, >> >> I've been using AbstractGateway as a base for my data >> access, but i want it to do more. I find there's a couple >> pieces of boilerplate code I tend to always wrap around >> listXXX() that seem right to move into AbstractGateway.cfc >> >> I'm planning on making these changes to at least my local >> copy, but i thought i'd run them past the group to get an >> idea if anyone else is doing something similar or has >> other thoughts as to how else this might be implemented. >> >> Initially, I want to be able to do a >> listXXXFilterByYYYOrderByZZZ(filterValue) against >> multiple filter and sort criteria. >> >> so i am planning to adding support for a method signature of >> >> listXXXFilteredOrdered(filtercriteria, sortorder) >> >> I know that essentially just proxies to EntityLoad() but >> it means i have a consistent mechanism to do all the data >> access i need. >> >> Then it would also support the forms >> >> listXXXFiltered(filtercriteria) >> listXXXFilteredOrderByZZZ(filtercriteria) >> listXXXFilterByYYYOrdered(sortorder) >> listXXXOrdered(sortorder) >> >> In all of these filtercriteria would be a struct that >> would be passed through to EntityLoad. Likewise >> sortorder would be a string passed through. >> >> Longer term, i'd love to add some smarts to support rule >> based filter criteria (i.e. 'price > 50' rather than just >> an ==), but i'll start small for now. >> >> My ultimate aim is to cut down the amount of code I have >> to write to do stuff in CF >> >> Thoughts? >> Phil >> >> -- >> You received this message because you are subscribed to >> the Google Groups "ColdSpring-Users" group. >> To post to this group, send email to >> coldspring-users@googlegroups.com >> . >> To unsubscribe from this group, send email to >> coldspring-users+unsubscribe@googlegroups.com >> . >> For more options, visit this group at >> http://groups.google.com/group/coldspring-users?hl=en. >> >> >> -- >> You received this message because you are subscribed to the >> Google Groups "ColdSpring-Users" group. >> To post to this group, send email to >> coldspring-users@googlegroups.com >> . >> To unsubscribe from this group, send email to >> coldspring-users+unsubscribe@googlegroups.com >> . >> For more options, visit this group at >> http://groups.google.com/group/coldspring-users?hl=en. > > -- > You received this message because you are subscribed to the > Google Groups "ColdSpring-Users" group. > To post to this group, send email to > coldspring-users@googlegroups.com > . > To unsubscribe from this group, send email to > coldspring-users+unsubscribe@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/coldspring-users?hl=en. > > > > > -- > E: mark.man...@gmail.com > T: http://www.twitter.com/neurotic > W: www.compoundtheory.com > > 2 Devs from Down Under Podcast > http://www.2ddu.com/ > > -- > You received this message because you are subscribed to the Google > Groups "ColdSpring-Users" group. > To post to this group, send email to > coldspring-users@googlegroups.com > . > To unsubscribe from this group, send email to > coldspring-users+unsubscribe@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/coldspring-users?hl=en. > > > -- > You received this message because you are subscribed to the Google > Groups "ColdSpring-Users" group. > To post to this group, send email to coldspring-users@googlegroups.com. > To unsubscribe from this group, send email to > coldspring-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/coldspring-users?hl=en. --------------080109020803020401070808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I do think the GORM comparators are quite neat, particularly around supporting And and Or keywords to combine multiple comparators.  Definitely not wanting to reinvent the wheel where we don't have to.

The only thing that ColdSpring does differently is allow the sorting to be specified in the method name whereas GORM passes that in as a struct.   My original idea was to also allow multiple comparators to be also passed in via a struct.

There are benefits for doing it both ways - perhaps there a happy medium we could strike to support both formats.

If you're building a dynamic querying capability, being able to pass in the comparators in a struct as well would simplify your calling code, but then supporting the same within the method name does create nice self-documenting code. 

Looking further, adding support for driving it via an argumentCollection would be another nice CF way of doing things also.

What all this basically suggested to me is there are a heap of extension points here and perhaps a nice internal plug-in type architecture to allow the clean separation between the parsing and identifying of comparators and the execution of the resulting query.  Then at least adding additional parsers in the future would be simpler and it opens up the possibility of picking and choosing the syntaxes you want to support.

That's the direction i'll take with my code, and once i've tested it i'll make it available to Mark as a patch and he can do with it what he wants.

Phil


On 23/02/12 1:14 AM, Tony Nelson wrote:
If you're going to spend the time and effort, I would suggest creating something similar to GORM rather than trying to define your own conventions.

I implemented something similar to GORM into my framework (http://www.coldmvc.com/guide/models/orm). I've thought about splitting it out into its own library so its not so coupled to the rest of the MVC stack, but I haven't had the time, energy, or desire to do so yet.

A nice benefit of following GORM's lead is that (if you do it right) people can refer to the GORM documentation for how things should behave. Granted, there are some things in GORM that you aren't able to fully support (closures, statics), but most of it is pretty straightforward.


-Tony


On Wed, Feb 22, 2012 at 6:32 AM, Mark Mandel <mark.man...@gmail.com> wrote:
I think it's useful - the question I have, is something more akin to GORM's finder methods be more appropriate?

What do you think?
Mark


On Wed, Feb 22, 2012 at 10:14 PM, Phil Haeusler <philhaeus...@gmail.com> wrote:
Hi Brian

Completely understand and of course that is the approach anyone should take.  I guess what i'm really asking, what do people think of such an extension to AbstractGateway is it a useful addition to ColdSpring?

Phil



On 22/02/12 3:19 PM, Brian Kotek wrote:
This is a more general comment that applies when using just about any framework: You'll make your life much easier later if you limit coupling to the framework. In this case, rather than having all of your gateways extend AbstractGateway, create your own abstract subclass of it and have your gateways extend that instead. This not only offers some protection if something were to change in the framework class, but gives you a place to put your own additions. I would NOT recommend altering the framework files directly, it will just cause you a ton of pain later when you want to update. 

The main exception to this rule is if you want to contribute to the framework. In that case, fork the repository, add your proposed changes, and send it back to Mark as a patch or pull request. :-)



On Tue, Feb 21, 2012 at 10:09 PM, Phil Haeusler <philhaeus...@gmail.com> wrote:
Hi everyone,

I've been using AbstractGateway as a base for my data access, but i want it to do more. I find there's a couple pieces of boilerplate code I tend to always wrap around listXXX() that seem right to move into AbstractGateway.cfc

I'm planning on making these changes to at least my local copy, but i thought i'd run them past the group to get an idea if anyone else is doing something similar or has other thoughts as to how else this might be implemented.

Initially, I want to be able to do a listXXXFilterByYYYOrderByZZZ(filterValue) against multiple filter and sort criteria.

so i am planning to adding support for a method signature of

listXXXFilteredOrdered(filtercriteria, sortorder)

I know that essentially just proxies to EntityLoad() but it means i have a consistent mechanism to do all the data access i need.

Then it would also support the forms

listXXXFiltered(filtercriteria)
listXXXFilteredOrderByZZZ(filtercriteria)
listXXXFilterByYYYOrdered(sortorder)
listXXXOrdered(sortorder)

In all of these filtercriteria would be a struct that would be passed through to EntityLoad.  Likewise sortorder would be a string passed through.

Longer term, i'd love to add some smarts to support rule based filter criteria (i.e. 'price > 50' rather than just an ==), but i'll start small for now.

My ultimate aim is to cut down the amount of code I have to write to do stuff in CF

Thoughts?
Phil

--
You received this message because you are subscribed to the Google Groups "ColdSpring-Users" group.
To post to this group, send email to coldspring-users@googlegroups.com.
To unsubscribe from this group, send email to coldspring-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/coldspring-users?hl=en.

--
You received this message because you are subscribed to the Google Groups "ColdSpring-Users" group.
To post to this group, send email to coldspring-users@googlegroups.com.
To unsubscribe from this group, send email to coldspring-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/coldspring-users?hl=en.

--
You received this message because you are subscribed to the Google Groups "ColdSpring-Users" group.
To post to this group, send email to coldspring-users@googlegroups.com.
To unsubscribe from this group, send email to coldspring-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/coldspring-users?hl=en.



--
E: mark.man...@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast

--
You received this message because you are subscribed to the Google Groups "ColdSpring-Users" group.
To post to this group, send email to coldspring-users@googlegroups.com.
To unsubscribe from this group, send email to coldspring-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/coldspring-users?hl=en.

--
You received this message because you are subscribed to the Google Groups "ColdSpring-Users" group.
To post to this group, send email to coldspring-users@googlegroups.com.
To unsubscribe from this group, send email to coldspring-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/coldspring-users?hl=en.

--------------080109020803020401070808--