On Thursday, Jul 17, 2003, at 21:41 US/Pacific, Mosh Teitelbaum wrote: > So first, as has been stated to death in this thread, there are tons of > different ways of accomplishing the same thing. I recognize this, > agree > with it, respect it. What I'm really asking is, why is *this* a > better way > of obtaining these benefits then any other way?
Trade offs. Everything is a trade off. Sometimes the quick, unstructured 'hack' is the right solution... > Concerning the points you mentioned, other than point (a), all of this > can > be accomplished via constructive use of Application.cfm and > OnRequestEnd.cfm. 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'... > As far as hiding the file structure goes, I'm not sure I find it a > truly > useful benefit given what I perceive to be its downsides. Your mileage may vary, as they say. > Your instance in > which you had to merge your blogs shows it can be useful but -- and no > offense intended here, Sean -- it sounds like more of a short term > hack than > a long term solution. I'd be only too happy for someone to figure out why, after upgrading my Hurricane Electric account to new software revs, I can no longer access the old blog database files. It's true that creating a new blog is a 'hack' but it was either that or stay 'off the air' for longer while I try to migrate the old data. I, personally, don't care how the problem is resolved... My point was that I can wrap the blog in standardized URLs and provide a more consistent user experience no matter what happens under the hood. > 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. > 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. > But the downsides of hiding the file system by way of a Request > controller > are pretty hefty, IMO: > 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... > 2) Static "sounding" URLs are easier to remember. They shouldn't be, > but > they > are. Most likely, this is because people are used to seeing a URL > like > "/Products/SuperApp.cfm" instead of > "index.cfm?go=Products.SuperApp". OK, I'll buy that. But that's why Macromedia (for example) has "go" URLs and some server-side redirects for 'obvious' URLs. It's also why, for example, my site has these URLs: http://www.corfield.org/coldfusion/ http://www.corfield.org/cplusplus/ http://www.corfield.org/weddings/ http://www.corfield.org/sean/ http://www.corfield.org/java/ etc Adding shortcut URLs is perfectly reasonable. > 3) Additional overhead from the architect's perspective. I had > mentioned > this > earlier in the thread; basically, the architect(s) must now define 2 > hierarchical structures, the physical file system, and the "virtual > file system" (regardless of you agree with the specific > terminology). 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. > Concerning a single source for controlling a site's presentation, this > (a) > can be done any number of other ways (obviously) and (b) can have it's > own > issues. Trade offs. > You can accomplish this by including header/footer files from > App.cfm ...which a lot of people seem to consider bad practice... > 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. > 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). Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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 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 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
