In my specific instance, I happen to be the only developer building the
site, so I don't really worry about other developers needing a black
box.

Also, the display portion of my intranet will be so custom, that it
wouldn't make sense to spend the time to make it very reusable.  At one
tier or another, everything becomes custom.  I don't feel the need to
keep making layers.  I could just as easily put all my code directly in
the base page, but I like to wrap up the commonly-used stuff in a custom
tag wrapped around the page's unique content.

I tend to see the contrast of custom tags and CFCs as:
CFCs are closer to OO development than are custom tags.  Therefore, it
makes sense to follow the "rules" of encapsulation and what-not.  As
Matt mentioned, they can have instances related to them.

Custom tags are very close to the actual HTML that is output.  They
don't have the concept of instances and all scopes are easily available
to them.  (I will step back and say that CFCs can "see" all scopes as
well, however, they can't/shouldn't see data in other CFCs that haven't
been passed to them or inherited to them.)  Custom tags can see
variables set in other custom tags.  That tends to be the breaking point
of "why bother to encapsulate custom tags?" for me.

-----Original Message-----
From: Adam Wayne Lehman [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 29, 2003 4:52 PM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] Encapsulation Or Not In Custom Tags


What about the advantage of reusing your custom tag in other
applications?

Adam Wayne Lehman
Web Systems Developer
Johns Hopkins Bloomberg School of Public Health
Distance Education Division


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Matt Liotta
Sent: Friday, August 29, 2003 5:40 PM
To: [EMAIL PROTECTED]
Subject: Re: [CFCDev] Encapsulation Or Not In Custom Tags

Because there are zero advantages to passing in data to a custom tag  
that already has access to the data anyway.

-Matt

On Friday, August 29, 2003, at 05:26 PM, Adam Wayne Lehman wrote:

> Pass the attributes. If you've done so well to follow encapsulation,
> why
> stop now?
>
> Adam Wayne Lehman
> Web Systems Developer
> Johns Hopkins Bloomberg School of Public Health
> Distance Education Division
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Dawson, Michael
> Sent: Friday, August 29, 2003 4:50 PM
> To: [EMAIL PROTECTED]
> Subject: [CFCDev] Encapsulation Or Not In Custom Tags
>
> Well, this list has been very quiet lately!
>
> I've built all of the logic for my intranet site in my components and 
> now I'm getting ready to build the output using custom tags.
>
> My components follow pretty-good rules of encapsulation in that they 
> don't assume to know of "exterior" data such as other scopes, caller 
> variables, etc.  I pass everything thru the arguments.  I'm pleased
> with
> the results.
>
> Now that I'm working on the display using custom tags, I find it a bit

> of a relief to "break some rules" of encapsulation.  At least, that is

> where I'm heading...
>
> I'm interested in other's opinions on whether custom tags should be 
> allowed to call any scope and know any variable that is visible to
them
> (Example 1), or should everything be passed through the attributes
> scope
> (Example 2)?
>
> I don't really want a religious war on using CFCs or Custom Tags for 
> display.  I'm just curious if people tend to let custom tags "know it 
> all" within the body of the tag.
>
> Example 1 
> <cf_myTag><cfoutput>#Session.firstName#</cfoutput></cf_myTag>
>
> Example 2
> <cf_myTag 
> firstName="#Session.firstName#"><cfoutput>#Attributes.firstName#</
> cfoutp
> ut></cf_myTag>
>
> I'm leaning toward Example 1 since I already did the hard work
building
> my components.
>
> Thanks
>
> M!chael A. Dawson
> Group Manager, Programming and Software Development
> Office of Technology Services
> University of Evansville
> 1800 Lincoln Avenue
> Evansville, IN 47722
> 812-479-2581
> ----------------------------------------------------------
> 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]
>
>
Matt Liotta
President & CEO
Montara Software, Inc.
http://www.MontaraSoftware.com
(888) 408-0900 x901


----------------------------------------------------------
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]
----------------------------------------------------------
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]

Reply via email to