Hmmm, I wouldn't bother with the XFA's you find in the switches - there are *probably* more fundamental problems to tackle than these small details. OO's guiding statement on encapsulation, one that i keep coming back to to try and make sense of this, is to encapsulate what varies. So i tend to try to think more abstractly first in object oriented terms: "Is this a "thing" that varies in my app? In what way is it related to other "things" that vary?
I don't know where you're at with OO - if you just want to use CFC's as a coding construct or you want to use them as objects, or maybe the distinction is somewhat blurred at the moment, but as you mentioned Mach-ii, it seems you're thinking in an OO direction. You might also be fully up on OO programming and i'm misreading the situation :) I've fully encapsulated the navigation for the application i've been working on in objects, and do generate what i call "NavXFA's" for those points on pages where a link can be embedded using the app - but this is a CMS, so it makes sense to encapsulate it the nav generation in an object, because it varies within the app. It also made sense to me to encapsulate the HTML generation, because that varies within the world that the app models too. But only in this particular application. For myself, i decided i wanted to focus on understanding OO as best i can and I'm still using FB3 as "the framework" - but it's importance has withered as the object oriented model i've been developing and learning how to use has slowly taken center stage in the app. My reasoning was that learning OO was more important than learning to use another framework. My experience has been that the dependence on FB3 as a framework withered as i've gotten my model worked out and functioning. There still is some, i don't think you can get around that if you're using a framework, but it's minimal. The more important questions for me have been around designing the model for an app, and at that, i'm still pretty green, but enjoying the process very much. I think i might have it to the point where i'm ready to move it into Mach-ii, sometime in the coming months, but i wanted to get the OO part really down first. Nando -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Patrick Mcelhaney Sent: Friday, November 05, 2004 3:14 PM To: [EMAIL PROTECTED] Subject: [CFCDev] A More Object-Oriented XFA? Hi Folks, I have a CFC that writes HTML code including some anchor tags. I don't want the CFC to know how to write the links. That decision really belongs to the layer that calls it. I don't want the CFC to be coupled to: 1. The Fusebox framework 2. The name and location of the controller page (/index.cfm) 3. The fact that there is a controller page at all 4. The fact that I'm using "&" to delimit parameters (not search-engine-safe) 5. The names of the fuseactions that relate to each exit point 6. The names of the URL parameters Using a variable called "self" instead of hard-coding "index.cfm" takes care of #2. Hal's XFAs take care of #5. These are both old ideas from circa CF 3.1. I'm sure that we can fully abstract the way links are written using CFCs. I'd be surprised if a lot of people aren't already doing that. I just don't know where to look. This morning in the shower I brainstormed a "ExitPoint" component that would keep track of a set of exit points and how to write the links for those exit points. First initialize the exitPoints object and tell it to write links Fusebox-style. exitPoints = createObject("component", "ExitPoints"); writer = createObject("Component", "FuseBoxExitPointWriter"); writer.init("/index.cfm", "fuseaction") exitPoints.setWriter(writer): Then define the exit points. exitPoints.add("createPerson", "ppl.newPersonForm"); exitPoints.add("selectPerson", "ppl.editPersonForm", "personID"); exitPoints.add("removePerson", "groups.dropPerson", "personID", "groupID"); The first argument of the add method is the name of the exit point. The second argument is the name of the action. (In this case it's a fuseaction, but it could be an event, page name, etc.) The rest of the arguments are paramters that must be passed out of the exit point. Here's how the exit points would be used: <a href="#exitPoints.write('createPerson')#">Create Person</a><br> <cfloop query="people"> <a href="#exitPoints.write('selectPerson', people.id)#">#people.name#</a> <a href="#exitPoints.write('removePerson', people.id, groupID)#">[remove]</a> <br> </cfloop> Here's what the resulting HTML would look like: <a href="/index.cfm?fuseaction=ppl.newPersonForm">Create Person</a><br> <a href="/index.cfm?fuseaction=ppl.editPersonForm&personID=1">Bob</a> <a href="/index.cfm?fuseaction=groups.dropPerson&personID=1&groupID=4">[remove] </a> <br> <a href="/index.cfm?fuseaction=ppl.editPersonForm&personID=2">Larry</a> <a href="/index.cfm?fuseaction=groups.dropPerson&personID=2&groupID=4">[remove] </a> <br> Again, I won't be surprised if something like this is already a common practice. I would appreciate if someone would point me in the right direction. -- Patrick McElhaney 704.560.9117 http://pmcelhaney.blogspot.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words '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] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words '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]
