> I figured for the includes that it was inefficient to > process CF code, then send it to have SSI added. Or > whatever the order would be. I'm not even sure you > could do that.
You really can't do that, as a practical matter. HTML pages that use server-side includes and CF pages both require server-side processing. > But I don't want to have different include calls for my > CF pages than I do for my other pages. For example, I > don't want static *.html pages being processed for SSI > and *.cfm pages being processed for CFINCLUDE. I'd like > it all the same. It seems like maintenance for me and > future people would be easier if it was all the same. I don't see any problem with using SSI within your static HTML pages, and using CFINCLUDE within your CF pages. If in both cases you're including the same HTML headers and footers, it won't make any difference at all to do that. In general, you should only use CF when you need to do something that only CF can do. There's a lot of overhead with CF, compared to static HTML files. In the case where you need CF, though, why not just use the .cfm extension? > 2. USER SESSIONS: Users need to be able to log in and > have their username carried across the website. > > I'm thinking that the session cookie CF sets on log in > can be accessed from a static HTML page. Is this right? > It's just like any other cookie? Yes, it's just like any other cookie, but you can't "access" it from a static HTML page, because a static HTML page isn't a program. On the other hand, once you map the .html extension to the CF server, it won't be a static HTML page any more - it'll be a program, even if you don't have any CFML tags or functions within it. > As for *.html vs. *.cfm for page names on dynamic > websites, I think it'd be easier for users to guess > file names with *.html than with *.cfm. Either way, > I think having the entire website have the same extension > offers a minor usability feature. This is a small detail, > but my naming conventions are pretty standardized just > in case users want to type random URLs to find something. Why should your users have to guess file names? Your interface should preclude the need to make users guess file names. You can provide links to every page, you can use meaningful directory names, and you can specify a default document for each directory. Users don't necessarily need to see file names at all, really, if you don't want them to. As for having the entire website use the same extension, I would agree to the extent that files do the same thing. That is, if you have static HTML files, you might as well use either .htm or .html for all of them, but not use both extensions. However, if you have static HTML files and CF programs, you might as well use different extensions for them. It won't make any difference to the user, but will make a big difference for those who have to maintain the site. > Does this seem to make more sense, or does it still > seem unnecessary? Like I mentioned, I can code CF, but > properly designing an application is something I'm totally > new to. In general, my advice to you would be to do what you see other people doing, since you're new to application design. Don't overthink things unnecessarily. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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
