Don't get me wrong, I've abstracted my code to an extreme, if there is one. I have six separate components that each do their own thing. Some of them pull from others, but never is there any code reuse among them. My site is quite simple and I can easily wrap up the commonly-used display code in about 50 lines of HTML. I use a single custom tag for this. For individual content elements, I created another custom tag "RenderContainer" that lets met put a "block" of content in it and it takes care of displaying. My plans are to have probably less than five custom tags that perform some sort of display of HTML. I don't think I can, nor do I want, to get less than that. Since I did so well with laying out the components, if I do change the design next year (probably will), it may take me several days. However, most of that time will be designing, waiting for approval and checking against browsers. I would be able to change the actual code in about an hour or two. Again, there still is a point of customization that must take place if my site is to look different than other sites. No one should use my logo, no one would probably use my page layout, etc. I was lying in bed this morning knocking a few ideas around and came to the conclusion, at least in my mind, of the main differences of CFCs and CTs. All I did was compare and contrast the "Variables" scope between CFCs and CTs. CFCs have their own variables scope and can't see other's. CTs can see and change variable scopes that affect the caller and other CTs in the same request. This has been a great discussion, and I'm sure it will continue, but this is my rule, for myself, only: * Use CFCs for business logic and data access. CFCs will only know what has been passed to them. * Use Custom Tags for display. CTs will have access to any scope they need. Thanks MAD
-----Original Message-----
From: Barney Boisvert [mailto:[EMAIL PROTECTED]
Sent: Fri 8/29/2003 7:52 PM
To: [EMAIL PROTECTED]
Cc:
Subject: RE: [CFCDev] Encapsulation Or Not In Custom Tags
Don't plan for now, it's already too late. You have to plan for the future,
when there might be multiple developers working on the project. And just
because something's so custom, doesn't mean that abstracting reusable parts
is foolhardy. Just the opposite, in fact. The more custom something is,
the harder it is to maintain, and having those discrete pieces makes it
easier. Just think how pissed you'd be if you had to redesign the interface
next year, and you had to wade through a few MB of CF to do it. Much nicer
to only see the HTML, with a few KB of CF in there to glue it to the next
tier. There's always a point where the ROI becomes negative, but I've found
it's usually further towards a good multi-tiered design that most people
(including myself) think, even for fairly small projects.
cheers,
barneyb
---
Barney Boisvert, Senior Development Engineer
AudienceCentral
[EMAIL PROTECTED]
voice : 360.756.8080 x12
fax : 360.647.5351
www.audiencecentral.com
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Dawson, Michael
> Sent: Friday, August 29, 2003 3:44 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFCDev] Encapsulation Or Not In Custom Tags
>
>
> 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]
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/2003
----------------------------------------------------------
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]
<<winmail.dat>>
