I was using configure() because of init() because I am using the mach II
framework.
Yes, I figured as much. Ben only recently changed that because he has an 'init()' constructor for Listener objects but extensions to the framework shouldn't need to know about it. However, that's a specific exception, imposed by the framework - especially since the objects *do* have an 'init()' method.
So I could switch back to init() instead on objects not extending the framework.
I would advise that - then your non-framework components can be easily reused elsewhere since they'll conform to the more popular 'init()' interface.
The thinking behind the Store_auction is that right now it grabs data
from a MS SQL db, but in the future depending on configuration, it could
grab from an xml file, some webservice or even an OO DB. Is there
another way you would achieve this minimizing the footprint if any on
your object layer? Should I simply return a query object to my auction
object and do the assignment there?
Since the low-level persistence object is returning 'packets' of data but doesn't really care about what's in the packet, it makes more sense in many ways to return an opaque query with known column names rather than create an object that seems like it has a specific API with getX() methods. ColdFusion is very good at handling query objects and they're easy to create so they make a great ValueObject for passing data around. You can easily convert XML to a query (I bet there's a UDF out there already for this!).
As for the getX setX, I implemented it this way, because I was under the
impression that I should not access data or set data directly whether
from another cfc or within a cfc. Am I mistaken?
No, you're correct but you need to consider whether the public interface of your CFC really includes all of those getX()/setX() methods.
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive." -- Margaret Atwood
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
