For ASP developers
1. When writing a lot of ASP pages, do you guys write <html><head></head><body></body></html> on every page or use <!--#include file=""-->?
2. Do you guys use one ASP page for each "task" or just one page (like Joe)? And if you use just one page, you code everything there or split it into multiple include files?
3. Encapsulate VBScript code in a COM DLL or just be lazy (as me)?
I'm finishing a big ASP project and I wonder if everybody has the same approach. :-)
Saturday, March 16, 2002
for most server-side apps i try to segregate presentation from logic. the logic i tend to stuff in a few files that reach toward the database and offer some level of abstraction. the presentation i tend to disperse in multiple files that generally cluster around the outermost logic file (furthest from the db). it kind of ends up looking like so....
presentation < - logic logic -> database
kind of like a tree :)
if two web pages are really closely related (say a page with a form that takes info and the page that outputs a copy for you to print out) i might keep them together and mixed code and tags. but usually i find that the more i do this the more i mix presentation and logic without thinking about it.
include files i use a lot for the header and footer information that standardizes the layout of the pages (style sheets, and maybe session info that i use throughout the site).
p.s. i used to think that putting all the presentation in one file saved time, since i didn't need to open multiple files-but i ended up wasting time figuring out what was where and wading through gallons of comment just to get my bearings. on the othe hand, i find that the most code oriented files i can arrange it however i feel is the most "logical" with less concern about dispaly (no concern actually), so i'm more confident stuffing a lot of lines of code into these (as long as i make things modular and comment i don't seem to have a problem)
Saturday, March 16, 2002
I always used to multi-purpose a page - it's content and function would invariably decided by the URL-encoded arguments. I stopped doing this for one reason mainly. Users can't get to obvious areas of your site by typing the URL. As an example, the contact section of a site I designed originally was accessed using the url "www.sitename.com/main.cfm?section=contact" (plus other arguments tacked on to that when things got more specific).
The problem was that when asking users how they thought it most likely that they'd get to the contact section, a lot of them tried typing "www.sitename.com/contact" - if I had a sensible directory structure, this would work. Or if I was using Apache say, I could fiddle round with mod_rewrite and make it work. But being windows based (and this primarily being related to asp) I decided to abandon that.
In short, these days I try wherever possible to reflect the site content in it's directory structure. It enhances usability. Many people far more qualified than me have said this - but I can't think of any URLs of the top of my head. You'll just have to put up with my thoughts as an opinion!
Monday, March 18, 2002
Mostly I think it depends on how much of the Content is Dynamic on a particular site. If each "section" of the site has a differenty dynamic aspect, I would have one ASP content page per section, and the rest of it would be DB generated or pulled from a template or something.
ASP is scripted, so remember, the longer the page is the slower it will be. (stupid fusebox methedology) Those are my two cents, as I've worked on some pretty large ASP sites.
Tuesday, March 19, 2002
Fog Creek Home