RE: Design Structure and cfinclude
-Original Message- From: Shannon Rhodes [mailto:[EMAIL PROTECTED] Sent: Saturday, September 20, 2003 9:54 AM To: CF-Talk Subject: Design Structure and cfinclude The only part I'm still hesitant about is the navigation. I really do wonder if I'm making it more complicated than it needs to be. My stock answer to this is to make things as complicated as your architecture needs them to be as long as your only making them complicated in one place. In other words your every-day use of (your interface to) the navigation should be simple - but the navigation component (module, tag, template, whatever) you're using can be as complex as you need. Jim Davis ~| Message: http://www.houseoffusion.com/lists.cfm?link=i:4:137801 Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
Re: Design Structure and cfinclude
5. Lastly, OnRequestEnd.cfm has cfinclude template=includes/design/footer.cfm which tests for url.print and delivers an appropriate footer based on this. The advantage is that I don't have to include a footer on each individual page; the disadvantage is that I can't use cflocation (since it doesn't call OnRequestEnd.cfm). I highly recommend using a css print stylesheet. I've just started using them, and I find that they significantly reduce complexity for our sites. It moves the display code away from the application code which means less application testing. Once it's there you can forget it because it doesn't have anything to do with your application. In fact, we've added it retroactively to CF sites without altering any applicatoin code. And for us, where we have lots of completely static html pages, it incorporates those as well with no additional work. -Kevin ~| Message: http://www.houseoffusion.com/lists.cfm?link=i:4:137803 Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Get the mailserver that powers this list at http://www.coolfusion.com
Re: Design Structure and cfinclude
One quick suggestion: put your CSS and javascript into separate .css and .js files that get called into the header. That way the browser should cache. If you just put code in the page header itself, yeah it has to download it fresh each time. I'm interested to see what other responses you get though because we're in the same boat looking for a better method that doesn't make it too complicated. -Kevin - Original Message - From: Shannon Rhodes [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:45 AM Subject: Design Structure and cfinclude We all know that cfinclude is perfect for design headers and footers, but now that I'm actually redesigning my site to take advantage of this, I'm running into some perplexing problems. (Please don't suggest FuseBox, that's way overkill for this site and I don't have the time for it). My initial thought was: set up an Application.cfm and OnRequestEnd.cfm in each major section, which would call a header/footer for that section. I would be able to pass a url variable to request a print-friendly version instead, or to request no display at all (for action only templates). Global variables would be cfparam'ed, and one page title and set of meta tags would be defined per section. Voila, new pages can be content-only without even a cfinclude line---everything would be called by the section's Application.cfm. As I'm getting into this, I'm finding that I don't like the loss of page-specific flexibility. I'm told that dynamically generated meta tags often are missed by search engines, for example, and I don't have a way to override the standard section page title for pages that really ought to have their own title. I'm also stuck with defining all CSS and JS in one long file, even if some style definitions and JS functions are only needed on one page, because I've made the header of my document standardized. Seems to me I'm adding all kinds of unnecessary download time. Plus, my section specific Application.cfm idea kind of forces me to model my directories after my site navigation, when I'd actually prefer to avoid a lot of third level directories and keep pages logically grouped instead (after all, navigation sometimes changes over time anyway, but who wants to move directories around). I think I need a balance between letting CF templates do it all for me, and the tedious work of writing in each page information that is probably the same 80% of the time in a given section. Can anyone suggest a best practices approach to using cfinclude for design elements? Should I hard code in most of the head area of documents, so I can put in page-level titles, meta tags, and page-specific styles JavaScript, followed by a cfinclude containing the remainder of the head with links to the master style sheet, and any design code that will not change, followed by another include for section-specific design images? Any suggestions are appreciated! ~| Message: http://www.houseoffusion.com/lists.cfm?link=i:4:137682 Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com
RE: Design Structure and cfinclude
Remove the include from your application.cfm and put it at the top of each template, that way you can pass in all your meta tags/titles with simply variables.title etc, I know that means it's not quite so clean, but it is only a few lines of code for each template and the footer can still be called from OnRequestEnd.cfm. Your other option is cfhtmlhead. And as Kevin says, I would deffinatley use .css files and .js files where possible. You could even use a sperate .css file for each section if needed. -Original Message- From: Kevin Graeme [mailto:[EMAIL PROTECTED] Sent: 19 September 2003 17:09 To: CF-Talk Subject: Re: Design Structure and cfinclude One quick suggestion: put your CSS and javascript into separate .css and .js files that get called into the header. That way the browser should cache. If you just put code in the page header itself, yeah it has to download it fresh each time. I'm interested to see what other responses you get though because we're in the same boat looking for a better method that doesn't make it too complicated. -Kevin - Original Message - From: Shannon Rhodes [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:45 AM Subject: Design Structure and cfinclude We all know that cfinclude is perfect for design headers and footers, but now that I'm actually redesigning my site to take advantage of this, I'm running into some perplexing problems. (Please don't suggest FuseBox, that's way overkill for this site and I don't have the time for it). My initial thought was: set up an Application.cfm and OnRequestEnd.cfm in each major section, which would call a header/footer for that section. I would be able to pass a url variable to request a print-friendly version instead, or to request no display at all (for action only templates). Global variables would be cfparam'ed, and one page title and set of meta tags would be defined per section. Voila, new pages can be content-only without even a cfinclude line---everything would be called by the section's Application.cfm. As I'm getting into this, I'm finding that I don't like the loss of page-specific flexibility. I'm told that dynamically generated meta tags often are missed by search engines, for example, and I don't have a way to override the standard section page title for pages that really ought to have their own title. I'm also stuck with defining all CSS and JS in one long file, even if some style definitions and JS functions are only needed on one page, because I've made the header of my document standardized. Seems to me I'm adding all kinds of unnecessary download time. Plus, my section specific Application.cfm idea kind of forces me to model my directories after my site navigation, when I'd actually prefer to avoid a lot of third level directories and keep pages logically grouped instead (after all, navigation sometimes changes over time anyway, but who wants to move directories around). I think I need a balance between letting CF templates do it all for me, and the tedious work of writing in each page information that is probably the same 80% of the time in a given section. Can anyone suggest a best practices approach to using cfinclude for design elements? Should I hard code in most of the head area of documents, so I can put in page-level titles, meta tags, and page-specific styles JavaScript, followed by a cfinclude containing the remainder of the head with links to the master style sheet, and any design code that will not change, followed by another include for section-specific design images? Any suggestions are appreciated! ~| Message: http://www.houseoffusion.com/lists.cfm?link=i:4:137684 Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Get the mailserver that powers this list at http://www.coolfusion.com
RE: Design Structure and cfinclude
Personally I dislike using includes this way for several reasons: 1) Eventually you will have a page that you DON'T want to have a header/footer on and will have to add kludgy code to get around it. 2) Since the includes run in the same memory space as the main page you have to worry about them when writing general page code (variable name contention, etc.) In general I find using a single CustomTag for this to be much more workable. This tag (I call mine Wrapper) will, on start, load the header do whatever else you want then, on end, load the footer and do whatever else you want. In my case this tag itself calls out to Header,Footer and navigation custom tags to display. This wrapper tag wraps every displayable page in site. Something like this: cfsilenthtmlheadtitleWelcome/title/head/html/cfsilent cfmodule Template=Wrapper.cfm Title = Welcome NavSetting = Entrance SecSetting = MetaKeyWords = MetaDescription = h1This is the body of the page/h1 /cfmodule Note that the CFSILENT at the top is essential if you'll be using Verity - Verity picks up the page title from there even tho' the real headtitle is in the Wrapper. In my case I pass NavSetting as a comma delimited list describing the hierarchical position of the page in the navigation scheme and the SecSetting as a comma delimited list of security groups able to see this page (at a gross-level) - page security is handled in Wrapper as well. MetaKeyWords and MetaDescription both populate the finished page's HTML meta information. You can add any attributes you like to maintain as much page specific flexibility as you like: CSS, navigation options (for example I have FullWidth and NoHeader options for some sites). Application.cfm and OnRequestEnd.cfm for me are then used primarily for user-information and metrics information gathering (in other words non-interface stuff). I'd be happy to send you some sample code if you like. Jim Davis -Original Message- From: Shannon Rhodes [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 11:45 AM To: CF-Talk Subject: Design Structure and cfinclude We all know that cfinclude is perfect for design headers and footers, but now that I'm actually redesigning my site to take advantage of this, I'm running into some perplexing problems. (Please don't suggest FuseBox, that's way overkill for this site and I don't have the time for it). My initial thought was: set up an Application.cfm and OnRequestEnd.cfm in each major section, which would call a header/footer for that section. I would be able to pass a url variable to request a print-friendly version instead, or to request no display at all (for action only templates). Global variables would be cfparam'ed, and one page title and set of meta tags would be defined per section. Voila, new pages can be content-only without even a cfinclude line---everything would be called by the section's Application.cfm. As I'm getting into this, I'm finding that I don't like the loss of page-specific flexibility. I'm told that dynamically generated meta tags often are missed by search engines, for example, and I don't have a way to override the standard section page title for pages that really ought to have their own title. I'm also stuck with defining all CSS and JS in one long file, even if some style definitions and JS functions are only needed on one page, because I've made the header of my document standardized. Seems to me I'm adding all kinds of unnecessary download time. Plus, my section specific Application.cfm idea kind of forces me to model my directories after my site navigation, when I'd actually prefer to avoid a lot of third level directories and keep pages logically grouped instead (after all, navigation sometimes changes over time anyway, but who wants to move directories around). I think I need a balance between letting CF templates do it all for me, and the tedious work of writing in each page information that is probably the same 80% of the time in a given section. Can anyone suggest a best practices approach to using cfinclude for design elements? Should I hard code in most of the head area of documents, so I can put in page-level titles, meta tags, and page-specific styles JavaScript, followed by a cfinclude containing the remainder of the head with links to the master style sheet, and any design code that will not change, followed by another include for section-specific design images? Any suggestions are appreciated! ~| Message: http://www.houseoffusion.com/lists.cfm?link=i:4:137688 Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe:
RE: Design Structure and cfinclude
Shannon, If you don't mind one level deep directories you can do a main Application.cfm in the root - which defines the main variables you are going to use (header file, css, meta tags etc.) and contains a cfapplication tag. Then, instead of defining different groups of variables for each section, go to each subdirectory and create an Application.cfm file that has cfinclude template=../application.cfm. DON'T include a cfapplication tag in these sub application.cfm files (don't worry - they will still run) and simply override the variables you are concerned about - header, meta tags, css etc. Think of it as inheriting from a super class and overriding properties and methods w. I do this in members only sections where I might have more than one security context so I want to display different navigation etc. You are right of course, there is a balance to find and a point of diminishing returns. A lot of what you have to overcome is simply the change in routine however. Once you get used to doing it a certain way virtually any change seems like a time waster - witness my aversion to DW and clinging love for cf studio (lol). -Mark -Original Message- From: Shannon Rhodes [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:45 AM To: CF-Talk Subject: Design Structure and cfinclude We all know that cfinclude is perfect for design headers and footers, but now that I'm actually redesigning my site to take advantage of this, I'm running into some perplexing problems. (Please don't suggest FuseBox, that's way overkill for this site and I don't have the time for it). My initial thought was: set up an Application.cfm and OnRequestEnd.cfm in each major section, which would call a header/footer for that section. I would be able to pass a url variable to request a print-friendly version instead, or to request no display at all (for action only templates). Global variables would be cfparam'ed, and one page title and set of meta tags would be defined per section. Voila, new pages can be content-only without even a cfinclude line---everything would be called by the section's Application.cfm. As I'm getting into this, I'm finding that I don't like the loss of page-specific flexibility. I'm told that dynamically generated meta tags often are missed by search engines, for example, and I don't have a way to override the standard section page title for pages that really ought to have their own title. I'm also stuck with defining all CSS and JS in one long file, even if some style definitions and JS functions are only needed on one page, because I've made the header of my document standardized. Seems to me I'm adding all kinds of unnecessary download time. Plus, my section specific Application.cfm idea kind of forces me to model my directories after my site navigation, when I'd actually prefer to avoid a lot of third level directories and keep pages logically grouped instead (after all, navigation sometimes changes over time anyway, but who wants to move directories around). I think I need a balance between letting CF templates do it all for me, and the tedious work of writing in each page information that is probably the same 80% of the time in a given section. Can anyone suggest a best practices approach to using cfinclude for design elements? Should I hard code in most of the head area of documents, so I can put in page-level titles, meta tags, and page-specific styles JavaScript, followed by a cfinclude containing the remainder of the head with links to the master style sheet, and any design code that will not change, followed by another include for section-specific design images? Any suggestions are appreciated! ~| Message: http://www.houseoffusion.com/lists.cfm?link=i:4:137691 Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
RE: Design Structure and cfinclude
One method we use is to create our pages as include files themselves. We then build the main display page with simple code to set Page specific information (like Title, template, etc.). We have a template file for the application that includes the specified files at the required point. So I might have a template like this: cfparam name=PageTitle default= cfparam name=IncludeFile default=no_includefile.cfm htmlheadtitlecfoutput#PageTitle#/cfoutput/title/head body table trtd colspan=2cfinclude template=myheader.cfm/td/tr tr tdcfinclude template=menu.cfm/td tdcfinclude template=#IncludeFile#/td tr trtd colspan=2cfinclude template=myfooter.cfm/td/tr /table and my main calling page would look like this: cfset PageTitle=Test Page cfset IncludeFile=main.cfm cfinclude template=mytemplate.cfm The main.cfm file would do anything required by that specific page. We've moved to this because it allows us to change our templates across the entire application with a change to a single file. It also for more modular code, which leads to code reuse (in terms of the template at least). This method also allows you to add javascript references or style references on a per page basis, or on a system wide basis. Hope this helps with your setup. Shawn - Original Message - From: Shannon Rhodes [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:45 AM Subject: Design Structure and cfinclude We all know that cfinclude is perfect for design headers and footers, but now that I'm actually redesigning my site to take advantage of this, I'm running into some perplexing problems. (Please don't suggest FuseBox, that's way overkill for this site and I don't have the time for it). My initial thought was: set up an Application.cfm and OnRequestEnd.cfm in each major section, which would call a header/footer for that section. I would be able to pass a url variable to request a print-friendly version instead, or to request no display at all (for action only templates). Global variables would be cfparam'ed, and one page title and set of meta tags would be defined per section. Voila, new pages can be content-only without even a cfinclude line---everything would be called by the section's Application.cfm. As I'm getting into this, I'm finding that I don't like the loss of page-specific flexibility. I'm told that dynamically generated meta tags often are missed by search engines, for example, and I don't have a way to override the standard section page title for pages that really ought to have their own title. I'm also stuck with defining all CSS and JS in one long file, even if some style definitions and JS functions are only needed on one page, because I've made the header of my document standardized. Seems to me I'm adding all kinds of unnecessary download time. Plus, my section specific Application.cfm idea kind of forces me to model my directories after my site navigation, when I'd actually prefer to avoid a lot of third level directories and keep pages logically grouped instead (after all, navigation sometimes changes over time anyway, but who wants to move directories around). I think I need a balance between letting CF templates do it all for me, and the tedious work of writing in each page information that is probably the same 80% of the time in a given section. Can anyone suggest a best practices approach to using cfinclude for design elements? Should I hard code in most of the head area of documents, so I can put in page-level titles, meta tags, and page-specific styles JavaScript, followed by a cfinclude containing the remainder of the head with links to the master style sheet, and any design code that will not change, followed by another include for section-specific design images? Any suggestions are appreciated! ~| Message: http://www.houseoffusion.com/lists.cfm?link=i:4:137692 Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
Re: Design Structure and cfinclude
Ah, good point. We manually include the header and footer into each layout and that's nice for changing it on a per-page basis. -Kevin - Original Message - From: Craig Dudley [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, September 19, 2003 11:10 AM Subject: RE: Design Structure and cfinclude Remove the include from your application.cfm and put it at the top of each template, that way you can pass in all your meta tags/titles with simply variables.title etc, I know that means it's not quite so clean, but it is only a few lines of code for each template and the footer can still be called from OnRequestEnd.cfm. Your other option is cfhtmlhead. And as Kevin says, I would deffinatley use .css files and .js files where possible. You could even use a sperate .css file for each section if needed. -Original Message- From: Kevin Graeme [mailto:[EMAIL PROTECTED] Sent: 19 September 2003 17:09 To: CF-Talk Subject: Re: Design Structure and cfinclude One quick suggestion: put your CSS and javascript into separate .css and .js files that get called into the header. That way the browser should cache. If you just put code in the page header itself, yeah it has to download it fresh each time. I'm interested to see what other responses you get though because we're in the same boat looking for a better method that doesn't make it too complicated. -Kevin - Original Message - From: Shannon Rhodes [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:45 AM Subject: Design Structure and cfinclude We all know that cfinclude is perfect for design headers and footers, but now that I'm actually redesigning my site to take advantage of this, I'm running into some perplexing problems. (Please don't suggest FuseBox, that's way overkill for this site and I don't have the time for it). My initial thought was: set up an Application.cfm and OnRequestEnd.cfm in each major section, which would call a header/footer for that section. I would be able to pass a url variable to request a print-friendly version instead, or to request no display at all (for action only templates). Global variables would be cfparam'ed, and one page title and set of meta tags would be defined per section. Voila, new pages can be content-only without even a cfinclude line---everything would be called by the section's Application.cfm. As I'm getting into this, I'm finding that I don't like the loss of page-specific flexibility. I'm told that dynamically generated meta tags often are missed by search engines, for example, and I don't have a way to override the standard section page title for pages that really ought to have their own title. I'm also stuck with defining all CSS and JS in one long file, even if some style definitions and JS functions are only needed on one page, because I've made the header of my document standardized. Seems to me I'm adding all kinds of unnecessary download time. Plus, my section specific Application.cfm idea kind of forces me to model my directories after my site navigation, when I'd actually prefer to avoid a lot of third level directories and keep pages logically grouped instead (after all, navigation sometimes changes over time anyway, but who wants to move directories around). I think I need a balance between letting CF templates do it all for me, and the tedious work of writing in each page information that is probably the same 80% of the time in a given section. Can anyone suggest a best practices approach to using cfinclude for design elements? Should I hard code in most of the head area of documents, so I can put in page-level titles, meta tags, and page-specific styles JavaScript, followed by a cfinclude containing the remainder of the head with links to the master style sheet, and any design code that will not change, followed by another include for section-specific design images? Any suggestions are appreciated! ~| Message: http://www.houseoffusion.com/lists.cfm?link=i:4:137705 Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Get the mailserver that powers this list at http://www.coolfusion.com
RE: Design Structure and cfinclude
FYI, another way to get Verity to read titles is by wrapping the title tags with CF comment tags: !--- titleMy Title/title --- I used to do that - but it doesn't seem to work any longer in MX (my guess is that it was considered a bug and was picking up really commented titles). The cfsilent approach was my replacement - it seems to work in all versions that I've tried. Jim Davis ~| Message: http://www.houseoffusion.com/lists.cfm?link=i:4:137710 Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com
Re: Design Structure and cfinclude
Shannon Rhodes wrote: I think I need a balance between letting CF templates do it all for me, and the tedious work of writing in each page information that is probably the same 80% of the time in a given section. Can anyone suggest a best practices approach to using cfinclude for design elements? Should I hard code in most of the head area of documents, so I can put in page-level titles, meta tags, and page-specific styles JavaScript, followed by a cfinclude containing the remainder of the head with links to the master style sheet, and any design code that will not change, followed by another include for section-specific design images? Any suggestions are appreciated! Shannon, Assuming that my previous email got bounced by the CF-talk bot for not recognizing my munged email address, I'm trying this one again. If not I apologise for the duplicate posting. First of all I'd avoid putting the header and footers in you application.cfm and onrequestend.cfm pages. Those should be used for code specifics. Here's what I do, create a template in Dreamweaver and where the content is to go, have a cfoutput, something like this: cfoutput#variables.ResultsOutput#/cfoutput Then on the pages with the processing and other cfcode, surround that code with a cfsavecontent. Then you use an cfinclude to get the template as in cfsavecontent variable = variables.ResultsOutput !--- whatever cf code goes in there --- /cfsavecontent cfinclude template=Display_template.cfm Alternatively you could set which particular template to use based on the processing results. This approach allows you to be very flexible in your template handling. Another advantage is that if you use Dreamweaver to design your templates, you can update or change the display template without having to worry about messing up your CF code. Assuming that the power has been restored at my former employer, you can see an example of this at http://www.totalsports.us. hth, larry ~| Message: http://www.houseoffusion.com/lists.cfm?link=i:4:137751 Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com
