Enhancements to AbstractGateway

[Phil Haeusler]

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

[Mark Mandel]

This sounds interesting!

I'm also looking at GORM's dynamic finders as well, as they may be nice to haves:

http://grails.org/doc/latest/guide/GORM.html#querying

To c/p:

The possible comparators include:

• 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)

e.g.:

Book.findByReleaseDateBetween(firstDate, secondDate)

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

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

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

2 Devs from Down Under Podcast

http://www.2ddu.com/

[Brian Kotek]

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. :-)

[Phil Haeusler]

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

[Mark Mandel]

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

[Tony Nelson]

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

[Phil Haeusler]

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

[Mark Mandel]

Cool! Let's see what you end up with :)

Mark