Ben Rogers wrote: >>If I remember correctly, doesn't cfmodule create a whole new memory >>block for every call, where as the cfinclude will only use the existing >>memory space and be part of the normal page cache? >> >> > >Yes. In fact, that's at least part of the point. cfmodule -- and custom tags >in general -- provide encapsulation. I would only use cfinclude only if you >really want the included tag to be able to step all over your variables and >vise-versa. > > You are quite correct. However, using cfmodule and custom tags is potentially is server killer because it is EVERY call to the cfmodule/tag and not just the first call that grabs additional memory. So for every page call for every site visitor more memory is allocated for each cfmodule. Showing my age a bit now...... cfmodule and cf in general used to have a few problems with letting go of and reusing of allocated memory, so I've become acustom to using cfincludes rather than cfmodule, because of low resources in the memory department years back and a need to make stable applications that didn't require me to restart the server every couple of hours. (A slight exageration, but that did used to happen with one of the sites I built back in 1997. It used to get extremely high peeks of traffic at certain times of the day and it used to take the server down by taking all the available memory. We eventually worked out what the problem was, reworked a load of stuff in the site and then site was rock solid - so solid that our poor old 128kb line used to get topped out)
With regards "step all over your variables". Never had a problem. All it takes is a little care, attention to detail and meaningful variable names. >>Even if this isn't true for CFMX any more, personally, I'd probably lean >>towards the cfinclude method, because >> a) thats what I'm used to, >> b) I find it visually easier to read >> >> > >My preference is to use custom tags. I keep all the tags having to do with the >look and feel of a site in a directory called /tagLibs/layout. I then use the >cfimport tag to import them with the prefix "layout". It ends up >looking something like this: > What's CFIMPORT? ~joke~ Most of my clients are still on CF5 (don't fix what aint broke). >Personally, I find that much easier to read. More importantly (almost as >important as encapsulation), it also affords me the ability to pass in >parameters via the tag attributes. The tags have corresponding cfparam tags >which check to ensure that parameters have been passed and supply defaults if >necessary. > > Personal feelings. Don't rag on mine just because I don't agree with you. > > >>c) I feel like can tinker with the header and footer dynamically with a >>cfinclude than a cfmodule. >> >> > >I assume by using the phrase "I feel like" you mean that there isn't a >practical difference? I would agree that the use of includes establishes less >of a contract between the caller and the tag/template. However, I think that's >a very bad thing. You, on the other hand, seem to prefer a less >formal interface between your cfm templates. > > In a sense yes that is correct. By "tinker dynamically" I mean I can replace the headers much more easily dynamically with cfinclude than I can with cfmodule. I can have a directory full of different headers for different occasions (images of Wurzel Gummage come to mind). I can easily switch between headers by changing a single variable. Using a CFMODULE, I have to pass some information into the tag that tells the logic in the tag which bit of html to use. That html is either hard coded into the module (yak!) or you cfinclude it (pointless call to cfmodule). >>and d) Easier to get to the header and footers if I need to change them or >>simply replace them. >> >> >I'm not sure I understand this. Why would you have to put your cfm template >anywhere different if you're using the cfmodule tag as opposed to cfinclude? >As far as I know, the path attribute of both tags obey all the same rules. > So you've never had a client ask you to re-skin a site? "Here's a new design now go implement it." I'm not talking about simple CSS changes here. We're talking structural changes. If you have display code embedded inside logic, which happens the second you use a cfmodule or a call to custom tag, you would have to fiddle on changing the HTML buried in the logic or take the html out of the logic and replace it with the new html. Both of these methods are prone to simple time consuming mistakes - one slip and away goes a bit of logic you didn't want to remove. Seperate your html into individual files that can be included, set up a few standard variables for things like page titles etc and you can hand it off to a designer and let them get on with it with no fear that they are going to break anything more disasterous than the page title. >>What goes on inside the the cfmodule? Is the header and footer actually >>inside the cfmodule template or does it include the header and footer >>templates? If it includes them, then it'd be a bit of a pointless call to >>the cfmodule, if its in the cfmodule template, then refer to my point (d) >>above. ;) >> >> > >You're ignoring several key points, all mentioned above. In brief, though, >tags afford you 1) a degree of encapsulation; 2) specify parameters in a more >formal way; 3) the ability to enforce whether or not the end tag has been >specified (thisTag.hasEndTag); and 4) the ability to control the naming of >your tags (cfimport prefix attribute) and, by extension, their color coding >and such in your editor of choice. > > You can quite happily encapulate, formalise and colour code without using custom tags. Michael has posed a personal opinion question - there is no right or wrong way - just different points of view. Next time respond to the question and do not rag on someones personal opinion because you don't agree. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Silver Sponsor - New Atlanta http://www.newatlanta.com Message: http://www.houseoffusion.com/lists.cfm/link=i:4:185816 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
