OK. I think I'm beginning to digest it a bit more.
Thanks for all the input.
I still need to grasp the whole Getter's and Setter's concept.
I ended up making a DAO cfc that has the query function with the query name
in the var scope.
And I call by extending my products.cfc.
I am calling DAO in the super.init() method of my products.cfc like this.
<cfcomponent extends="DAO">
<cffunction name="init" returntype="products.detail">
<cfargument name="dsn" type="string" required="yes" />
<cfargument name="item" default="" required="yes" />
<cfset super.init(arguments.dsn)>
<cfset variables.instance = structNew() />
<cfset variables.instance.thisproduct = getdetail(arguments.item)>
<cfreturn this>
</cffunction>
<cffunction name="getDescription" returntype="string" output="false">
<cfreturn variables.instance.thisproduct.DESCRIPTION />
</cffunction>
</cfcomponent>
This way all the functions have access to the query in the variables scope.
Am I going in the right direction here?
Or am I just making it harder than it is.
I also need to figure out how to iterate over the query for product
attributes (there is more that 1 row in the query)
But I should be able to figure that out.
Thanks for all the knowledgeable input.
On 10/16/07, Aaron Rouse <[EMAIL PROTECTED]> wrote:
>
> I make the same mistake twice and then move on. The only time I do this
> syntax is when doing maintenance on a particular project that I inherited
> and I do it to mimic the existing style used throughout the application in
> order to maintain the same level of "confusion" Although honestly when I
> first saw it used all I thought at the time is why does that not throw an
> error. I knew what the intent was but probably due to the comments/hints
> within the code. Guess that is what through me off with reading that can't
> be done since it clearly works but just makes no sense to be done. Just
> would have been nice to know that it specifically causes XYZ problems and
> use that as a selling point to scrap it all and do a rewrite. ;)
>
> On 10/16/07, Dan Wilson <[EMAIL PROTECTED]> wrote:
> >
> > You are correct, Aaron. No one will pay for such an alteration. The
> > customers wouldn't understand what they were paying for and even if they
> > did, they would rather have the latest wizbang feature, than semantically
> > correct code. That being said, clarity is an ideal to be strived for.
> >
> > Don't misunderstand me, however. this veThere is plenty of code I've
> > written in the past that I am ashamed of. I am probably writing ry moment
> > and don't even know it.
> >
> > I do, however, make it a practice to not make the same mistake twice ;)
> >
> >
> > DW
> >
> >
> >
> >
> >
> >
> >
> >
> > On 10/16/07, Aaron Rouse < [EMAIL PROTECTED]> wrote:
> > >
> > > Ok, so it just should not be done because it might confuse other
> > > people. At least on this one, the hint attributes on the arguments say
> > > something to the effect of this is required but if not passed in it will
> > > default to whatever. Guess they were kind enough to explain their thought
> > > process, to some degree, in why they wrote it that way. It looks like it
> > > was
> > > just to know how the argument is referenced within the method, but I am
> > > purely speculating on that and heck maybe they just did it to avoid a
> > > error
> > > being thrown. Of course this still does not leave me with a valid reason
> > > to
> > > sell someone in changing the code since their argument back would be if
> > > everyone so far understood it then they are not going to pay someone to
> > > change it just in hopes of not confusing someone down the road.
> > >
> > > On 10/16/07, Brian Kotek < [EMAIL PROTECTED] > wrote:
> > > >
> > > > It has no impact on server performance. It just makes the API less
> > > > clear to anyone who needs to use the CFC: do I need to pass this in or
> > > > don't
> > > > I? Setting required="true" when I am actually not required to pass the
> > > > argument is misleading (in my opinion). I would argue that CF *should*
> > > > throw
> > > > an error if I specify an argument as required and then don't pass it in.
> > > >
> > > > On 10/16/07, Aaron Rouse < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > > And the downside to the confused API is? These particular CFCs I
> > > > > am thinking about have been in place for years and heavily used in a
> > > > > shared
> > > > > hosting environment, the current one being rock steady but I could
> > > > > not speak
> > > > > for the prior ones since that is before my time. So kind of curious
> > > > > beyond
> > > > > confusing a person when they look at it, what is the downside in
> > > > > regards to
> > > > > the server processing it since does not seem to have adverse or must
> > > > > be
> > > > > minimal effects with the API "confused".
> > > > >
> > > > > I actually seem to recall reading a thread about this quite
> > > > > sometime ago and thought in the discussion people were surprised that
> > > > > it
> > > > > worked one way vs the other. Maybe was on the BD list because I keep
> > > > > thinking something specific with that syntax involved BD perhaps it
> > > > > throws
> > > > > an error with BD but I long since slept since all of that.
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Aaron Rouse
> > > http://www.happyhacker.com/
> > >
> > >
> >
> >
> > --
> > "Come to the edge, he said. They said: We are afraid. Come to the edge,
> > he said. They came. He pushed them and they flew."
> >
> > Guillaume Apollinaire quotes
> >
> >
>
>
> --
> Aaron Rouse
> http://www.happyhacker.com/
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
