|
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] |
Title: Spam:RE: [CFCDev] Ad-hoc queries using Data Gateway objects
- RE: Spam:RE: [CFCDev] Ad-hoc queries using Data Gatewa... Duba, Phillip
- RE: Spam:RE: [CFCDev] Ad-hoc queries using Data G... Jason Daiger
- RE: Spam:Re: [CFCDev] Ad-hoc queries using Data G... Seth Johnson \(KW\)
- Re: Spam:Re: [CFCDev] Ad-hoc queries using Da... Cliff Meyers
