I should change this sentence to make it clear: > I can also develop a UDF > library for them which is stateless so cannot be used to transfer data.
to this sentence: We or I (any developer) can develop a UDF library or an object whose main intent is to manipulate query not a wrapper for queries to data transfer. > How come you don't apply this sort litmus test to the queryIterator? Yes, I saw that. True, the reasons for QueryIterator are weak. I cannot say that it is a perfect solution for a certain issue. However one point is important: QueryIterator is not a data holder. It's not an alternative of query object. It just provides additional looping mechanism implicitly. So it's harmless, you can easily plug into your existing code. On the other hand oQuery transfers and encapsulates both query and functionality. Let's think on a MVC application. You may need oQuery in model, because you probably want to manipulate data in there. However when you need to use data in your view, do you really need the oQuery in view? You probably want to pass only query object not the whole oQuery instance. If you separate data and some functions like QueryIterator, you can use both query and manipulater object (QueryIterator) separately. For example I can iterate over a query in my model using QueryIterator or simply cfloop and pass it to view to display it... Do you see any problem? However oQuery forces to use only itself. So with oQuery there is no query object; you should use only oQuery for manipulation and display which will make oQuery a very big object to deal with all possible needs in all layers. It is similar to ASP's RecordSets. I may want some helper objects whose intent to make easy some operations using CF's objects, this is normal and this helps my codes. But to tend to develop an object like ASP's RecordSets is a different thing. The start point of it is not normal, its intent is not purely help my codes and it significantly changes my codes for almost nothing. Hope that I success to describe my opinions (my native language is not English). Murat. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Adam Cameron > Sent: Monday, March 07, 2005 1:46 PM > To: [email protected] > Subject: RE: [CFCDev] query object CFC Beta > > >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. > > How come you don't apply this sort litmus test to the queryIterator? The > same thing applies: it's not doing anything new you can't already do. But > it's a pointless benchmark anyhow, as it kind of misses the point that the > object of the exercise is to encapsulate the functionality in one place, so > that it happens to already exist in other places is beside the point. > > -- > 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] ---------------------------------------------------------- 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]
