Andrew, Have you every considered putting your property values into an XML file (or some other file format) and read the file in your CFC to populate it?
This would allow for better reuse of your component over multiple projects. You'd have the validation inside your componet to make sure that values are valid inside your XML, and use getters/setters to set your properties. Just a thought you may want to consider. Steve -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Stephen Bosworth Application Development and Integration Communication and Information Services The University of Newcastle, Australia Phone: 02 4921 6574 Fax: 02 4921 7087 Mobile: 0438 492518 Email: [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> [EMAIL PROTECTED] 07/01/04 11:59am >>> Spike, Thank you for your comments, I'll say it again I am aware of the dangers of using the this scope. I just feel that just because everyone is saying it is bad doesn't mean it is. Like I also said, our framework doesn't require this methodology approach, and I consider the CFC I develop to aid our development is not open to the same things if it was used in an unknown environment, or more to the point uncontrollable. The first example I gave was a function that we could use to create a control for displaying html tags to the screen and change certain properties to make it behave differently, now if this was used in a situation were the input for these CFC's were to come from user interaction with forms and data then I would totally agree with encapsulation. The second example was for a string to connect to a datasource, this could be numerical or alpha characters so can't really encapsulate there so that was very valid as I had a cftry/cfcatch in place anyway, and in that example it would not matter if it was encapsulated or not it would still error if the datasource couldn't be found and is a perfect example of putting extra code into place when you don't need too:-) and that is what I consider makes a good developer not because they adhere to using or not using the this scope! Regards Andrew Scott Technical Consultant NuSphere Pty Ltd Level 2/33 Bank Street South Melbourne, Victoria, 3205 Phone: 03 9686 0485 - Fax: 03 9699 7976 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Milligan Sent: Thursday, 1 July 2004 11:52 AM To: CFAussie Mailing List Subject: [cfaussie] RE: this Andrew, I'm curious. Given that you say this: > > I don't need to do encapsulation here, and again this one of many >examples in our framework were I don't need to worry about it... My >choice not yours, don't force anything onto me. Like I said I >understand the risks and the dangers and it is all taking into >consideration when I design my component. > Specifically the bit where you say "Like I said I understand the risks and the dangers" What exactly was it about this statement that you found so laughable? "Although putting data in the this scope is perfectly valid and will not cause any errors, it generally isn't seen as a good idea. The main reason being that you lose the ability to tightly control that data from within the CFC, so breaking the encapsulation. That leads to increased overhead when you try to maintain the code, because you can't just look at what's happening inside the CFC before making changes. You have to also look at where it is used and how it is used to make sure none of the data in the this scope is being added, modified or removed by external code." Regards Spike -------------------------------------------- Stephen Milligan Code poet for hire http://www.spike.org.uk Do you cfeclipse? http://cfeclipse.tigris.org --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
