Personally, I don't like using CFCs for any output generation for
exactly the reasons you list.  It's nearly impossible to maintain
encapsulation in the CFC.  That being saidy, what you propose ought to
work, but seems really complex.  Is there a compelling reasons not to
render the HTML as part of your UI layer?  I'm not necessarily saying
move it out of the CFC.  If the CFC is considered part of your UI
layer, then you don't need to abstract out the fact that it's FB
dependant, or that you use ampersands, because that's something that's
common to the entire UI.

Depending on exactly what you're trying to do, here's two other suggestions.

First, don't write the links in your CFC, just use placeholders.  For
instance ${removePerson} or something, and then do some
post-processing in your UI layer that inserts the appropriate link. 
Obviously you'd have to pass in extra parameters, so it'd probably
look like this: ${removePerson:#person.ID#:#groupID#} or something.

Another alternative is to have your CFC render some
presentation-agnostic markup (i.e. XML) that then gets translated into
the appropriate format by your UI.  I've used this with great effect,
especially when I need a single "thing" to be displayed several ways. 
Generate the XML in the CFC, and let the UI layer apply whatever XSL
stylesheet it wants to get the specific HTML it needs.

I don't know if either of those ideas would work, but maybe it'll
trigger some idea or another.

cheers,
barneyb

On Fri, 5 Nov 2004 09:14:10 -0500, Patrick Mcelhaney
<[EMAIL PROTECTED]> wrote:
> 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
-- 
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/blog/

I currently have 0 GMail invites for the taking
----------------------------------------------------------
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]

Reply via email to