Mosh Teitelbaum wrote: > > Since you bring it up, I was wondering what everyone else thought > > about all requests having to come in through an application spine?
Sean A Corfield wrote: > Well, it's an approach I've gradually drifted into even without > Fusebox. MVC operates that way, for example, with all requests going > through the controller. (yeah, sometimes there are multiple controllers > in an application but the point is that usually one controller handles > a lot of different requests) Just to point out again, I wasn't actually asking about Fusebox so much as I was asking about the pros and cons of using a controller for all HTTP requests. That's why I started a new thread with a different topic. > it just happened to be a convenient way to wrap very simple > HTML pages in a common layout and common navigation. It's an > abstraction that (a) hides the actual file structure (b) allows me to > control layout in a single file (c) provides a central controller for > any logic in the site. 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? Concerning the points you mentioned, other than point (a), all of this can be accomplished via constructive use of Application.cfm and OnRequestEnd.cfm. And, in case you couldn't tell from that last observation, I don't belong to the camp that believes these files should be as empty as possible; I think they should be as full as needed and no more so. 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 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 would think it'd be a better idea to simply merge the old data with the new (preferably via automation if available). Otherwise, you have to maintain 2 separate systems, regardless of how similar they look. 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)? 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". This isn't much of a concern for web-based applications where you tend not to pass around individual URLs beyond the homepage, but for non-app websites, where individual URLs may be referenced (via bookmarks, marketing materials, etc.) This becomes a fairly weighty concern. 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). This is not much of an issue for smaller/simpler sites like you cat club site, but imagine having to do this with something larger. Also falling into this issue is having the developers learn both "file systems." Granted, you can get around this by not requiring this of developers (for example, using XFAs in FB), but as I stated earlier in the thread, I prefer my developers to know as much about the site's architecture as possible. Not just that the site is built on Framework X but that it uses the following variables, pathways, etc. This is not so that they can muck with the internal architecture, but so that they can be better developers and debuggers. 4) There are probably more, but it's starting to get late and I still have more work to do before bed. 8^) 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. You can accomplish this by including header/footer files from App.cfm, et al, or have each file include the header/footer themselves. However, what if you want to display the common header/footer but only on certain pages (ex. everything but pop-ups) or when a certain condition is true (ex. printMode equals "Off")? Now you have to include page/parameter-specific references/logic in a global file. This isn't a big deal for smaller sites, again, but what about larger sites? 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. Those files would, ideally pass control to other files for logic/DB functionality. This last step could be accomplished just as easily (perhaps more?) without requiring the use of the Request Controller. So, my specific question again, is what are the pros/cons to using this controller method vs. the direct approach? At this point, I'm beginning to wonder if it's simply a matter of personal preference. I see a bunch of downsides, but I'd be more than happy to hear about and possibly be convinced of some benefits. -- 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 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 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
