> 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.
I think you're casting this as a discussion about object oriented design when it isn't inherently so. All good software design is predicated on modularity, encapsulation, orthogonality, etc. These concepts are not unique to object oriented programming. In particular, the premise behind modularity is that you build many small apps which each have a clearly defined interface and purpose. Consequently, building a component which just iterates over a query is, by definition, a more modular design. I would also argue that it's a *theoretically* better design. John, however, has stated that he's not trying to build the *theoretically* best solution. He's trying to build something more all-purpose, something he believes will be easier for unseasoned programmers. That's a fair enough trade off. > 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. Actually, it's nothing like that. Have a look at the code I posted yesterday. The process of iteration is completely encapsulated in the base Iterator component. The collection specific iterator components define initialization, collection size, and data access. The actual process of iteration is completely encapsulated in one Component. More to the point, an Iterator's sole purpose is to store state. That's the exact opposite of a UDF library. There's no state with UDFs. They are utilities which perform one off operations. Technically, you could approximate state with global variables, but I don't think that's what you were talking about. > 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. I can't speak for John, but defining a standard interface for iterators definitely has merit in my situation. In just about every site I develop, I have to display paged data (previous/next type of results). Sometimes, I'm looping over a query (search results). Sometimes I'm looking over an array of objects or just a plain old structure of data. I manage this with a Pager component. The Pager has methods like getCurrentPage(), getPageCount(), getStartRow(), getEndRow(), getMaxRows(), getRecordCount(), etc. The Pager handles all the logic. I have custom tags which handle the basic looping and display. Within those custom tags, I display the actual data. Without a standard Iterator interface, I'd have to have separate ArrayPager and QueryPager components. If they defined the same interface, then I could use the same set of custom tags for looping. Granted, I'm going to end up with more components my way, but they will be far more modular. I'll be able to use the Iterators in many places (anywhere I loop over a collection, in fact). ArrayPager and QueryPager, on the other hand, would not be any more useful than a generic Pager class. Ben Rogers http://www.c4.net v.508.240.0051 f.508.240.0057 ---------------------------------------------------------- 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]
