The specific problem that lead me down this path is that I have a page
with a couple of loops and lots of conditionals. I have to make a
change that will introduce yet another conditional, and I don't want
to do that to the already complex and fragile code. I would rather
that page be a CFC.
You may be thinking that using FB4 or Mach-ii I could break the page
up into smaller parts, etc. But the problem is the app is currently
FB3. My goal is to move it to Mach-ii at some point. That's why I want
the solution to be independent of the framework.
> 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.
Is it a good idea to have the entire UI depend on FB?
> 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.
Isn't that just a different implementation of the same concept?
> Another alternative is to have your CFC render some
> presentation-agnostic markup (i.e. XML) ...
It's asking too much of my team to learn XSLT right now. We're already
bogged down learning Mach-ii. It may be something to look into in the
future, however.
Patrick
--
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]
