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.
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
- InList - In the list of given values - LessThan - less than a given value - LessThanEquals - less than or equal a give value - GreaterThan - greater than a given value - GreaterThanEquals - greater than or equal a given value - Like - Equivalent to a SQL like expression - Ilike - Similar to a Like, except case insensitive - NotEqual - Negates equality - Between - Between two values (requires two arguments) - IsNotNull - Not a null value (doesn't take an argument) - IsNull - Is a null value (doesn't take an argument)
One thing that is missing from the listXXX() methods, is the ability to pass in the options struct as the last argument, so you can do pagination and caching (which is bad).
Thoughts?
Mark
On Wed, Feb 22, 2012 at 2:09 PM, Phil Haeusler <philhaeus...@gmail.com>wrote:
> 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
> 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.
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:
> 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
> 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.
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?
> 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 <mailto: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
> 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 > <mailto:coldspring-users@googlegroups.com>. > To unsubscribe from this group, send email to > coldspring-users+unsubscribe@googlegroups.com > <mailto:coldspring-users%2Bunsubscribe@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.
> 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
>> 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.
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.
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
>>> 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.
> -- > 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.
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.
> 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 > <mailto: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 <mailto: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 <mailto: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
>> 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 >> <mailto:coldspring-users@googlegroups.com>. >> To unsubscribe from this group, send email to >> coldspring-users+unsubscribe@googlegroups.com >> <mailto:coldspring-users%2Bunsubscribe@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 >> <mailto:coldspring-users@googlegroups.com>. >> To unsubscribe from this group, send email to >> coldspring-users+unsubscribe@googlegroups.com >> <mailto: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 > <mailto:coldspring-users@googlegroups.com>. > To unsubscribe from this group, send email to > coldspring-users+unsubscribe@googlegroups.com > <mailto:coldspring-users%2Bunsubscribe@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 > <mailto:coldspring-users@googlegroups.com>. > To unsubscribe from this group, send email to > coldspring-users+unsubscribe@googlegroups.com > <mailto:coldspring-users%2Bunsubscribe@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.
> 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
>>>> 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.
>> -- >> 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.
