Mosh Teitelbaum wrote: > > Concerning the points you mentioned, other than point (a), all of this > > can be accomplished via constructive use of Application.cfm and > > OnRequestEnd.cfm.
Sean A Corfield wrote: > True, and for some folks, that will be the right choice. In general, I > hear folks saying that HTML / layout should not be handled by those two > special files tho'... I was think more in terms of including the appropriate display file from App.cfm rather than actually embedding the HTML code directly in the file. But, as you said, personal preference. > > I would think it'd be a better idea to simply merge > > the old data with the new (preferably via automation if available). > > Yes, it would. You're welcome to help me. So far my ISP has not > provided any feedback on why the blog broke. If I only had the time 8^). > > Otherwise, you have to maintain 2 separate systems, regardless of how > > similar they look. > > Nope. The old stuff is a static archive now. No maintenance needed. No plans to add features and functionality? No plans to change the look and feel? etc. > > 1) Some search engines will not be able to index your site, or more > > than a few pages of your site. For example, if I recall correctly, > > Google will only index dynamic pages that are linked to from a static > > page. How does > > it do with a site that is so obviously dynamic vs. site's where dynamic > > pages get non-assuming, unique URLs (/blog/index.cfm -> /blog/entry.cfm?ID=5)? > > Er, rubbish! Google, along with most other search engines these days, > has NO PROBLEM WHATSOEVER with 'dynamic URLs'... I'm surprised this old > chestnut is still being trotted out! Google has no problems searching > and indexing my Fusebox-based site. Sorry, but I really think this is a > myth based on how things used to be... I didn't say that Google has problems with dynamic URLs, only that it will not index dynamic URLs beyond a certain point. This, at least, is my understanding of the situation. I did a quick search on Google (http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=google+index+dyn amic+pages+site%3Agoogle.com) and got the following: http://www.google.com/webmasters/2.html 1. Reasons your site may not be included. * Your pages are dynamically generated. We are able to index dynamically generated pages. However, because our web crawler can easily overwhelm and crash sites serving dynamic content, we limit the amount of dynamic pages we index. and http://www.google.com/webmasters/guidelines.html Design and Content Guidelines: ... * If you decide to use dynamic pages (i.e., the URL contains a '?' character), be aware that not every search engine spider crawls dynamic pages as well as static pages. It helps to keep the parameters short and the number of them small. I'd love to hear that I'm wrong. And, in fact, Google doesn't prove me correct, but it does seem to somewhat validate my concern. > Sorry but I think this is a perfectly acceptable overhead - it reflects > the real-world difference between the URL API structure (the public > face of the site) and the file system structure (the private > implementation of the site). The bigger the site, the more important > this issue is and the more important the distinction is. I deal with a > 45,000 page website every day that has thousands of "go" URLs and > thousands of server-side redirects that support the public URL API - > juggling the contrasting requirements of the public interface and the > implementation is a necessary part of my job. So, as you said earlier, it's really a trade-off. You can go the non-controller route and save yourself the added work of managing public and private file systems. Or you can go the controller route and enjoy the benefits if you find them worthwhile. > > You can accomplish this by including header/footer files from > > App.cfm > > ...which a lot of people seem to consider bad practice... Yeah, I've never understood that, but we can save that for another thread. I'm still recovering from this one 8^). > > However, what if you want to display the common header/footer but only > > on certain pages > > Sure, "what ifs" always complicate matters and there are a number of > options and solutions. As soon as you get into 'custom' solutions, you > start to stray from a framework and more into bespoke development. I was simply pointing out a downside of using the controller to apply global design elements. I would think that any good framework modeled around controllers would allow for exceptions since, in practice, many sites have this kind of need. > > And finally, concerning the central controller, I actually prefer using a > > central controller for logic. But I'm questioning the usefulness for a > > *REQUEST* controller. The difference is that the request controller > > receives all HTTP requests and passes control to another file or files. > > But you actually already have one - your web server. You can build > logic there or delegate to your app server (or, it seems in your case, > delegate control to multiple files). OK, yes, the web server is in fact a Request Controller but I was speaking more at the app server level. Many site owners don't have access to the web server and their ability to control their applications begins and ends with the app server. Thanks for the replies Sean. -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
