- This component is a different thing from iterator component. It is an alternative of CF's query object.
- This component may does stateful and stateless iteration and it may contain all functions related to the queries.
- I think, however we should find good reasons to develop this component since CF already has functionalities which are really necessary. So what
I think splitting the notions of QueryIterator and QueryComponent is a mistake, and is seeming kind of like a procedural-coding answer to an OO question. The QueryIterator as it stands is more like "a bag of functions aimed at a query, which happens to remember which row it's at": more like a UDF library with variable. I dno't see any merit in it as purely an iterator (sorry John), other than as a discussion exercise.
What I'd more be aiming for is taking a query and treating it like an object.
The reason why one might want to do this is to define a standardised behaviour for using a query, and put it all in one place. Yes, anything that this component might do is already possible "elsewhere" in CF. This is sufficiently self-evident to not be worth pointing out. Following that argument denies the notion of encapsulation any validity: "anything one might put in a class can already be done by other mechanisms, so what's the point?". The point here is you make your query component, then anything you might want to do the "query" is done right there. It's object orientation. A lot of people are running with this as a good idea ;-)
My approach to a Query component is that a query is actually used as a collection of recordset rows, rather than a discrete object of itself. One hardly EVER uses a query as a complete entity. So any Query component should automatically have the mechanisms from QueryIterator project people are currently working on. But it should not stop there, because it's only part of the missions accomplished.
What would I add? (this list is not planned, I'm concocting it as I type)
init(query)
init(array)
init(struct)
init(sqlString, dsn) // some people might frown on this, I know. At the very least the component should offer a uniform mechanism for passing its data to some sort of storage controller
toString() // toWddx()
toStruct()
toArray()
clone()
equals()
isQuery()
isEmpty()
append(query)
append(struct)
append(array)
prepend(query)
prepend(struct)
prepend(array)
prepend(list)
insert(query) // at the current iterator location
insert(struct)
insert(array)
insert(list)
insertAt(query, index) // at the specified index
insertAt(struct, index)
insertAt(array, index)
insertAt(list, index)
delete() // current row
deleteAt(index) // specified row
deleteAt(list) // list of indices
deleteWith(sqlString) // as per SQL statement
deleteColumn()
addColumn(name, array)
addColumns(struct) // struct of arrays keyed on new columns name? Dunno
getColumns() // list or array of column names IN ORDER they were inserted (be it manually or via SQL)
getColumnType()
set(column=value) // current row
set(struct) // current row
set(query) // current row
setAt(columnName, index) // specified row
toArray(columnName) // just the column as an array
Ah, I'm sick of typing. There's stacks of stuff. I use *all* of those methods in various ways, shapes and forms (and frequencies). And yes, it can already be done via various other mechanisms around the place in CFML, or maybe other UDFs lying around cflib or my hard-drive, or whatever.
The *point* is that if you make a query component; then it's all *there*.
I'd also use something like this to encapsulate (not in the OO sense) a bunch of functions which use the undocumented methods exposed by CF's own query class to my heart's content. And then - yes - change it all, Macromedia, in the next rev of CF: I don't mind, because I've got the most out of your code for one version, and I've only got one place to update my code when you break it in a subsequent version ;-)
--
Adam
This email contains confidential information. If you are not the intended recipient of this email, please notify Straker Interactive and delete the email. You are not entitled to use it in any way.
---------------------------------------------------------- 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]