|
I
guess a config file would work, but I've been playing with Ruby recently and I
really do like the "convention over configuration" approach.
I
would rather use introspection on the bean to determine what properties are
available, even prevent the Filter from accepting invalid
criteria.
For instance, assume the Filter object has an
addCriteria() method that accepts two arguments: the property name to filter on
and the value to filter by. We could add an argument to its init() method
that accepts a bean CFC. Then, on all subsequent addCriteria() calls the
filter would examine the bean to see if the property is valid before adding it
to the filter.
Example: Customer.cfc has a customerType property
and therefore a getCustomerType() method. If I pass a Customer.cfc into a
GatewayFilter, and then call filter.addCriteria("customerType", "foo") the
filter will examine the customer bean, see that a getCustomerType method exists,
and let the addition take place. However, if I call
filter.addCriteria("someBogusField", "bar") the filter will examine the bean,
see that a getSomeBogusField() method does NOT exist, and throw an
exception.
This avoids subclassing the Filter for each bean AND
ensures that the filter contains valid data. The Gateway object would also
use this convention to map the data in the filter to which object property the
filter is for.
But we can't be the first people to ever want to do
ad-hoc queries using a DataGateway or TableGateway... has anyone else done this
before?
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Duba, Phillip
Sent: Wednesday, January 11, 2006 11:21 AM To: [email protected] Subject: Spam:RE: Spam:RE: [CFCDev] Ad-hoc queries using Data Gateway objects I would imagine either
specialized filter classes or specialized functions within a generic filter
class are probably the two best options. I’d put the mapping in a config file of
some sort that’s loaded in on the gateway filter’s instantiation. This way
form/filter mapping is done in one place and then standardizing form names for
data elements across the board would be the next thing, I guess. No matter what
way you do it, there’s probably going to be some kind of mapping, it’s just a
matter of where to put it. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Johnson (KW) > As for the filter
method, wouldn’t this be a good place to pass in > a structure and
loop through that structure to create the dynamic > where
clause? ... The difficulty would be in synching the structure
> items with the
fields in the database. That's exactly the line of thinking
that lead me to where I am right now. I envisioned accepting a form post,
wrapping the name/value pairs into a struct and then passing that into the
Gateway object as my filter. However, this smells a bit funny to
me because if I programmatically loop over the struct to build the query I am
coupling the form and the data model together. The form would have to
know how the database field names are spelled (or perhaps the spelling of the
bean's private data members) so that it could build the proper keys in the
struct. Then I thought about having the
Gateway object provide a mapping service that maps the struct keys to their
corresponding database fields. In other words, my Gateway might have logic
that whenever a key is called "customerType" the value of that key is applied
against the "customer_type" database field. But I don't really like THAT
approach either, because now I have to find a way of documenting what keys the
Gateway object recognizes so that the clients of the Gateway know how to build
the filter objects. Another idea I've been playing with
is subclassing GatewayFilter to provide class-specific filtering options.
For instance, I might have a CustomerGatewayFilter that has a well defined
interface for defining search options for Customer data. The
CustomerGateway object would then be responsible for creating the dynamic search
query based on the specialized filter object. I think that final option is the
cleanest implementation, but it adds yet another class to my system.
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ok, that makes sense
since I thought the getById() method took a single id value not a list of them.
My DAOs have something similar to your read() method and they always return a
singular object whether it’s read or saving data. As for the filter method,
wouldn’t this be a good place to pass in a structure and loop through that
structure to create the dynamic where clause? I figure whatever you may be using
as a controller can construct the structure and pass it into the method this way
you don’t have to worry about StructKeyExists() or IsDefined() or default
checking. That’s the tact I would probably take. The difficulty would be in
synching the structure items with the fields in the database.
Thanks, Phil From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Johnson (KW) Phillip: my getById() method accepts a LIST of
data, not a single value, and therefore can return a multi-row query. For
this reason (and the fact that the resulting data is a query, not an object) I
put it in the Gateway object. My DAO already has a read() method that
accepts a single value and returns a fully constructed
object. Jason: I like the idea of naming the filter object
Filter, not Criteria. I'm kinda embarrased to admit I thought long and
hard for a good name for that object and "filter" never occured to me
:) Nando: I use the same distinctions you do: DAOs
synch up the database and singular objects, while Gateways return queries.
My main question was: in my ad-hoc query method, is it better to have an
argument for EACH field that can be searched, or is it better to construct the
filter as a separate object and then pass a SINGLE argument (that filter) into
the Gateway's ad-hoc query method? Basically, if I have a table with 20 searchable fields I
don't want to have to deal with 20 method parameters. I'd rather construct
the entire filter as an external object and then pass it into the search method,
but I wasn't sure if anyone else was using the same approach (or had something
better to suggest). Thanks everyone for your
comments! Seth ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected] |
Title: Spam:RE: [CFCDev] Ad-hoc queries using Data Gateway objects
- RE: [CFCDev] Ad-hoc queries using Data Gateway objects Seth Johnson \(KW\)
- RE: [CFCDev] Ad-hoc queries using Data Gateway ob... Seth Johnson \(KW\)
- RE: [CFCDev] Ad-hoc queries using Data Gatewa... Jason Daiger
- RE: [CFCDev] Ad-hoc queries using Data Gateway ob... Seth Johnson \(KW\)
- RE: [CFCDev] Ad-hoc queries using Data Gatewa... Jason Daiger
- Re: [CFCDev] Ad-hoc queries using Data Gateway ob... Cliff Meyers
- RE: [CFCDev] Ad-hoc queries using Data Gateway ob... RADEMAKERS Tanguy
