I agree with you. I have absolutely no problem generating HTML and
returning it from a CFC. I noticed no performance differences. I think
it all boils down to a user's preference.
Here is my actual dilemma...
My intranet should allow the public, as well as logged-in users, the
ability to see some content depending on the authorization.
I keep session variables for my logged-in users. Public users do get a
session, but only the basic sessionid. In the CFCs that need it, I
always pass in a reference to the Session.objUser instance. Then,
within my CFCs, I can use Arguments.objUser and call its methods. I'm
fine with that.
I tried to create a method this morning that would show the header
(html/body/title) and log bar of a page. The content would change based
on if the user has authenticated or not.
If the user authenticated, I could easily pass the Session.objUser to
the display CFC and use it to build the HTML. However, if no user was
logged in, I would receive an error, rightly so, saying the
Session.objUser variable didn't exist.
I then had three solutions (only three because I'm tired):
1. Write a method to generate HTML for public and write a separate
method to generate HTML for authenticated users.
2. Break encapsulation by letting the CFC "see" the Session scope within
itself and using IsDefined("Session.objUser") to determine what content
to show.
3. Use a custom tag and let it see all the scopes just as I would in the
body of a plain web page.
I could also, I guess, assign default values to the Session.objUser,
therefore, it would always exist when passed to a CFC. However, I
didn't take the time to look over all the rest of my code to see if it
would break anything.
One other reason, and some may disagree, is that the code is easier to
read on the main page.
<cf_renderpage>
Content goes here
</cf_renderpage>
Or
<cfoutput>#Application.Objects.SiteService.GetHeader("Page Title",
Request.IsLoggedIn, Session.objUser)#</cfoutput>
Content goes here
<cfoutput>#Application.Objects.SiteService.GetFooter()#</cfoutput>
Thanks
-----Original Message-----
From: Brad Howerter [mailto:[EMAIL PROTECTED]
Sent: Friday, August 29, 2003 4:06 PM
To: '[EMAIL PROTECTED]'
Subject: [CFCDev] Display in CFCs
I'd like to have a religious war on whether to use CFCs or Custom Tags
for display. I tried to start one on CF-Talk a few weeks ago, but it
didn't get much of a response. I've never seen this fleshed out very
well anywhere.
What are the reasons for NOT having methods that return HTML strings as
a result? All I ever read is "It's stupid" or "It's bad". To me it
makes sense to do it in a CFC as opposed to a tag, because then you have
self documenting methods (instead of poorly documented tags). And I
don't see a downside to it. If I have, say, a person object, why
shouldn't it know how to display itself? It's probably not as clean a
solution as having xml and xslt, but to me it seems better than having a
custom tag displaying the html.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word '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 word '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]
