- see footer for list info -<
Not at all. It is perfectly reasonable to use both. Presumably, if you
are writing a component, you are creating an object. If you want to
write objects well, then it would be good to write it OO. The rest of
your code that might use the object from time to time does not
neccessarily have to be.
CFCs allow easier OO in CF. You don't have to use them in an OO way, but
to get the best of them I think you do.
And it is not that it is bad, it simply makes things harder to maintain,
read, reuse, etc. Same reasons people care about scoping variables.
Snake wrote:
- see footer for list info -<
That is of course presuming you currently code in a similar way without
CFC's.
You could equally say that putting data in request scope or using the caller
scope from custom tags is bad practice for the same reason.
I think if your going to actually care about whether or not using the THIS
scope is bad, the rest of your code needs to follow the same process and be
encapsulated, otherwise what is the point.
Russ
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of dominic watson
Sent: 29 December 2005 14:40
To: Coldfusion Development
Subject: Re: [CF-Dev] The THIS scope in CFCs
- see footer for list info -<
As to the reasons for using the 'this' scope being bad practice I've just
figured how to put it (though it's hard to put in words). As I said before,
it is only bad practice in terms of writing Object Oriented components, but
afterall, that is what they are for.
Taking your example, lets say you are an outside developer using the object
and you want that query that the method populates. If the query is stored as
a property in the 'this' scope, you will need to open up the component and
view its code to see the property name, where it is set, etc in order to
know how to get at it.
If the query is returned by a method, all you need to know is the method
definition (in the case of CFCs, this can be automatically generated and
viewed using a component browser, download my static CFC documenter here
<http://www.greenhouse-design.co.uk/downloads/greenDoc.zip>).
This is a rough description of encapsulation: the outside coder can only get
and set data through the interface that the object creator allows.
The outside coder just needs documentation of the interface (i.e. the
methods) and he is set to go. The outside coder should never have to look
into the code. With this in mind, you should always set the 'hint'
attributes of CFFUNCTIONs, CFARGUMENTs and CFCOMPONENTs with useful
documentation.
By using the 'this' scope for component properties, you bypass the whole
idea of the object interface and the object loses its encapsulation.
This is why it is 'bad' practice. It may sound like a lot of hassle, but
once in the swing of writing encapsulated objects you find programming them
far more enjoyable and manageable.
Dominic
dominic watson wrote:
- see footer for list info -<
Using the this scope is 'bad' practice only in terms of O-O. Have a
look at some decent descriptions of O-O, and in particular
encapsulation Heres one that relates to java (which implements O-O
very well):
http://javaboutique.internet.com/articles/ITJ/part02/index.html
In other languages, the problem of returning multiple values is dealt
with in ways which CFCs cant handle (pointers). I would think the most
straight forward way to do it in CF is to return a STRUCT of all the
different return values. I think this is a more elegant solution as
there is one less line of code:
<cfset st_result = myObject.myMethod("argument")> <cffif
st_result.b_success>
<cfloop query="st_result.q_records">
<!--- etc. --->
</cfloop>
</cfif>
In the above example, the struct return contains two values, a success
or failure flag and the query.
In my opinion, objects and cfcs should be written so that the code
that uses them uses as little and as readable code as possible. The
code inside the objects can be as complex as you like as long as the
/interface/ that uses them is clean. The extra cfset line that
accesses the produced query seems a little ambiguous to me and would
be harder to document than a method that returns a structure that
contains the query and the other return variable.
My tuppence worth
Dom
Gary F wrote:
- see footer for list info -<
I posted a similar message on Ray Camden's Ask a Jedi blog but it
created more questions than answers. I need to return at least 2
complex objects
(queries) from a CFC. The CFRETURN function only lets you return a
single object/variable so I started using the THIS scope.
Example: from within the CFC
<CFSET this.myquery=myquery>
Now myquery is exposed to the parent page so I can grab it like so:
<!--- use createobject to initiate the cfc ---> <CFSET
objCFC=CreateObject("component","myCFC")>
<!--- collect a varible that CFReturn would usually return from a cfc
--->
<CFSET getReturnedData=objCFC.myFunction("optional arguments go
here")>
<!--- get the var/object that was explosed using the This scope --->
<CFSET myquery=objCFC.myquery>
I found this is the quickest and most effecient way to return
multiple vars/objects from CFCs without storing them in arrays or
structures which seems like a waste of code when This works with
total simplicity.
Someone
told me using the This scope is bad practice but failed to give a
reason. I honestly don't see what's wrong with this, but I'd like to
hear the thoughts of experienced CFC users? (I've only been using
CFCs for a few months).
Thanks,
Gary.
_______________________________________________
For details on ALL mailing lists and for joining or leaving lists, go
to http://list.cfdeveloper.co.uk/mailman/listinfo
--
CFDeveloper Sponsors:-
- Hosting provided by www.cfmxhosting.co.uk -<
- Forum provided by www.fusetalk.com -<
- DHTML Menus provided by www.APYCOM.com -<
- Lists hosted by www.Gradwell.com -<
- CFdeveloper is run by Russ Michaels, feel free to volunteer your
help -<
_______________________________________________
For details on ALL mailing lists and for joining or leaving lists, go
to http://list.cfdeveloper.co.uk/mailman/listinfo
--
CFDeveloper Sponsors:-
- Hosting provided by www.cfmxhosting.co.uk -<
- Forum provided by www.fusetalk.com -<
- DHTML Menus provided by www.APYCOM.com -<
- Lists hosted by www.Gradwell.com -<
- CFdeveloper is run by Russ Michaels, feel free to volunteer your
help -<
_______________________________________________
For details on ALL mailing lists and for joining or leaving lists, go to
http://list.cfdeveloper.co.uk/mailman/listinfo
--
CFDeveloper Sponsors:-
- Hosting provided by www.cfmxhosting.co.uk -<
- Forum provided by www.fusetalk.com -<
- DHTML Menus provided by www.APYCOM.com -<
- Lists hosted by www.Gradwell.com -<
- CFdeveloper is run by Russ Michaels, feel free to volunteer your help
-<
_______________________________________________
For details on ALL mailing lists and for joining or leaving lists, go to
http://list.cfdeveloper.co.uk/mailman/listinfo
--
CFDeveloper Sponsors:-
- Hosting provided by www.cfmxhosting.co.uk -<
- Forum provided by www.fusetalk.com -<
- DHTML Menus provided by www.APYCOM.com -<
- Lists hosted by www.Gradwell.com -<
- CFdeveloper is run by Russ Michaels, feel free to volunteer your help -<
_______________________________________________
For details on ALL mailing lists and for joining or leaving lists, go to
http://list.cfdeveloper.co.uk/mailman/listinfo
--
CFDeveloper Sponsors:-
- Hosting provided by www.cfmxhosting.co.uk -<
- Forum provided by www.fusetalk.com -<
- DHTML Menus provided by www.APYCOM.com -<
- Lists hosted by www.Gradwell.com -<
- CFdeveloper is run by Russ Michaels, feel free to volunteer your help -<
