The wrong with oQuery is related to its main intent. CF provides several data passing techniques currently:
- simple values - arrays - structures - queries - xml - custom components (like Person, AddressTO) The main intent of QueryIterator isn't data transfer. It just provides another interface to iterate over a query and also provides stateful iteration (remembers the position). Of course it can be used to transfer data, but this is not the main intent. However the main intent of oQuery is to provide a new object that holds data, so it will force us to use it to transfer data. To implement this, you are duplicating a query in the init method. This means it is an alternative of "query" object. I don't believe developers need this oQuery component since current data passing techniques are useful enough. If current solutions are useful, what may force me to use oQuery? Some methods like sort, filter? I can do them with QoQ. I can also develop a UDF library for them which is stateless so cannot be used to transfer data. I still don't see a real-world reason to use oQuery. To help developers, there are some other windows to open like O/R mapper tool, a more developer-friendly framework and maybe some code wizards like new Login Wizard of Dreamweaver. For example, I've developed a developer-friendly framework (MX Framework) which will help developers to develop n-tiered OO applications more easily. We can talk about it if you want. Murat. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > John Farrar > Sent: Tuesday, March 01, 2005 5:10 PM > To: [email protected] > Subject: Re: [CFCDev] query object CFC Beta > > I have gone a different direction with oQuery.cfc, but only slightly. > Here is my thoughts. SOHO business doesn't always have the time or > manpower to implement what is correct solutions for the perfect > programmer. If they are logging page execution speed... then they can do > second best solutions. I believe there are times where it is right to do > the second best solution. (Which puts me at odds with many of the main > stream thinkers on this list.) Funding and time often make it impossible > to do "best possible" solutions in SOHO situations. > > Goals with oQuery... > 1. add functions for development to eliminate the need for writting > additional functions for common recordset handler functions. (sort, > filter, iteration, etc.) > 2. make it easy for the "page coder" to use the oquery object... to keep > people out of the data who don't belong in the data... without making > them unable to consume the data in the form they need to consume it. > 3. teach them to monitor page execution speed on apps to see how load > and and individual pages run. > 4. let those who are learning how to do CF and Databases use the object > as a learning example of coding (how the language works / not perfect > practice) > 5. create a standard interface so they can do simular things with > arrays, lists... using one standard component for all variable type > interaction where there are multiples. > > This will allow newer developers to build more functional applications > earlier. It will allow developers who's skill is growing to read the > "open source code" and move the techniques as appropriate (which I > encourage) to an internalized single layer of data interaction in the > prime components. When we try to make everything ideal from the start > our motives are noble... but or project efficiency is usually very poor! > It's the classic tradeoff senario... since not all of us are as skilled > as the gurus... sometimes they tradeoff using data in the CFC by putting > queries right in the main page code! This will allow them to keep the > data tier seperate much more often as they learn! In my mind it is a > stepping stone and sometimes a good temporary solution when development > speed is critical! (Or when proofing a concept that we aren't ready to > move into the final code yet.) It would also be nice for some to have > all the common functions encapsulated. In the end... the fasted code is > code without any CFTags... and without any CFCs. We have learned that > the tradeoff is often appropriate. I have also heard many developers who > are clearly "PHOBIC" that a newcommer will learn a dangerous and > volitile technique. (That is why I suggest we teach them to time > pages... and help them learn what to expect... and how to tweak the > applications.) > > Sincerly, > > John Farrar > > > ---------------------------------------------------------- > 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]
