| Groups | Blog | Home |
inetserver asp general : http://www.aspfaq.com/show.asp?id=2424
Rob Meade wrote: > Lo all, > > Just reading through and saw this in the FAQ... > > *********************** > <some error> > /file.asp, line 1294 > > > This seems to be *way* too many lines of ASP code to (a) manage and > (b) expect to run efficiently. I've worked on some pretty big ASP > applications and I don't recall ever having an ASP script more than > 250 lines long. > > *********************** > I've never run into an issue caused by the size of my pages, but I write only intranet applications. What Aaron is saying here may be more valid for internet apps with lots of users and narrow pipelines. Bob Barrows -- Microsoft MVP - ASP/ASP.NET Please reply to the newsgroup. This email account is my spam trap so I don't check it very often. If you must reply off-line, then remove the "NO SPAM"
[quoted text, click to view]
"Rob Meade" wrote: > > For myself it is *very* common place to have pages in excess > of 1000 lines, one application I've written recently has a > main page which then based on user selection might include 1 > of 4 or 5 .asp's into it- thus again generating a mammoth > total page... Are you actually seeing line numbers over 1000, or are you counting the lengths of the #includes? [quoted text, click to view] > I just wondered what the norm was... Do you post scripts back to themselves? That would certainly add to the length. As could the construction of SQL strings instead of SP calls, depending on complexity. I can't speak for anyone else, but my scripts tend to be under 300 lines, with about 20-30% whitespace or documentation, and typically under 100 lines of server-side code. I often use process-and-redirect scripts, which are typically quite short. Most of my process-and-display scripts also #include about 900 lines, of which the vast majority is corporate branding for common look & feel. That, in turn, is lessened by the use of client-side .js and .css files (as opposed to inline). If not for these abstractions, I would certainly exceed 1000 lines on almost every script. -- ASIDE -------------- One of the most burdensome scripts I can recall was one I made intentionally large. I had previously agreed to code a "20 question" survey. When the final copy hit my desk (a week before the deadline and *after* the paper version had already been printed) it turned out there were 20 *sections* and 132 questions. Normally I would break such a thing into multiple scripts, but the time constraints and my sense of being ambushed convinced me to do the whole thing in one page -- and post back. Even so, it's a slim 600 lines (plus the boilerplate includes), of which only 20 or so are devoted to storing the responses and roughly 100 to populating the various sets of OPTION tags. I certainly think my script is easier to navigate than the survey it produced (users predictably complained of survey fatigue). I needed an "emergency" to make it 600 lines. 1000+ sounds like a crime to me. In fact, I have a colleague who writes 1000-line scripts, and I absolutely HATE working on those things**. Ugh. **Confession time. I also hate them because they are unstructured. I separate processing from presentation as much as possible, whereas my colleague does not. My HTML sections are continuous, with tokens for the dynamic content. The only interlacing I do looks something like this... <INPUT NAME="LastName" VALUE="<%=Page.LastName%>"> or <SELECT NAME="Ethnicity"><%=Page.EthnicityList%></SELECT> or <TABLE><%=Page.TableRows()%></TABLE> ....where [Page] is the only variable I declare with page scope. -- Dave Anderson Unsolicited commercial email will be read at a cost of $500 per message. Use of this email address implies consent to these terms. Please do not contact me directly or ask me to contact you directly for assistance. If your question is worth asking, it's worth posting.
I've never quite understood why a thousand lines of code is too long, but
then I tend to put all page processing into one page. A single ASP page for listing, adding, editing and deleting employee records from a database (for instance) contains all the code I need for those operations --- except for generic function libraries and database connections which are #included from elsewhere --- in one page. I might have a page of 2000 lines or more since I rarely post forms to separate "action" pages. Functions are kept small, are named to indicate what they do ("fnDeleteEmployee(parmEmployeeID)"), and all in all are quite manageable. Want to work with employee records? Want to know where employee records are deleted? Want to see the add code? Go to editEmployees.asp. Simple. I've got some tools I use within Homesite that makes browsing for functions easy. I can see how more than 250 lines would be a problem for some programmers (I work with one, as it happens, but I'm converting him), but not for me. - Wm -- William Morris Product Development, Seritas LLC Kansas City, Missouri [quoted text, click to view] "Rob Meade" <robert.meade@NOSPAMubht.swest.nhs.uk> wrote in message news:efj8nk5zDHA.540@tk2msftngp13.phx.gbl... > Lo all, > > Just reading through and saw this in the FAQ... > > *********************** > <some error> > /file.asp, line 1294 > > > This seems to be *way* too many lines of ASP code to (a) manage and (b) > expect to run efficiently. I've worked on some pretty big ASP applications > and I don't recall ever having an ASP script more than 250 lines long. > > *********************** > > I must confess that I dont think I've ever written anything thats as short > as that - unless it was a real basic attempt at testing something - most of > my pages have both html and asp in - therefore increasing the number of > lines (typically forms that post back to themselves etc) - some of these > forms might have lots of validation going on - therefore several IF-THENS - > and perhaps within these there might be forms that post back with an error > message to the same page etc... > > For myself it is *very* common place to have pages in excess of 1000 lines, > one application I've written recently has a main page which then based on > user selection might include 1 of 4 or 5 .asp's into it- thus again > generating a mammoth total page... > > I just wondered what the norm was...I understand the above quote from the > FAQ - but I'm not convinced it would always be prudent to "Consider > optimizing the code and perhaps spreading the work over multiple pages" - > unless these were 'included' instead of being redirect to etc.... > > Please dont see this as a criticism or anything - I just stumbled across it, > and like most ASP FAQ's found it an interesting read and wondered what other > developers did... > > Cheers all, oh and happy new year :o) > > Rob > >
Lo all,
Just reading through and saw this in the FAQ... *********************** <some error> /file.asp, line 1294 This seems to be *way* too many lines of ASP code to (a) manage and (b) expect to run efficiently. I've worked on some pretty big ASP applications and I don't recall ever having an ASP script more than 250 lines long. *********************** I must confess that I dont think I've ever written anything thats as short as that - unless it was a real basic attempt at testing something - most of my pages have both html and asp in - therefore increasing the number of lines (typically forms that post back to themselves etc) - some of these forms might have lots of validation going on - therefore several IF-THENS - and perhaps within these there might be forms that post back with an error message to the same page etc... For myself it is *very* common place to have pages in excess of 1000 lines, one application I've written recently has a main page which then based on user selection might include 1 of 4 or 5 .asp's into it- thus again generating a mammoth total page... I just wondered what the norm was...I understand the above quote from the FAQ - but I'm not convinced it would always be prudent to "Consider optimizing the code and perhaps spreading the work over multiple pages" - unless these were 'included' instead of being redirect to etc.... Please dont see this as a criticism or anything - I just stumbled across it, and like most ASP FAQ's found it an interesting read and wondered what other developers did... Cheers all, oh and happy new year :o) Rob
I think the article is more trying to point out the that using single ASP
pages with a lot of code in them is difficult to manage. Encapsulating a lot of common functionality to Classes and includes does result in the same total length of ASP code but the ASP page itself in development and debugging is a lot smaller and easier to see what's going on. I used to have about 10 ASP pages that all used the same ADO code (few years back now when learning ASP) - copied and pasted to each resulting in about 1200 lines of code in each page. Moving the ADO stuff to a class helped by reducing this to under 300 lines for each page with the Class based include being cached by IIS thus increasing performance. Chris. [quoted text, click to view] "Rob Meade" <robert.meade@NOSPAMubht.swest.nhs.uk> wrote in message Lo all,news:efj8nk5zDHA.540@tk2msftngp13.phx.gbl... Just reading through and saw this in the FAQ... *********************** <some error> /file.asp, line 1294 This seems to be *way* too many lines of ASP code to (a) manage and (b) expect to run efficiently. I've worked on some pretty big ASP applications and I don't recall ever having an ASP script more than 250 lines long. *********************** I must confess that I dont think I've ever written anything thats as short as that - unless it was a real basic attempt at testing something - most of my pages have both html and asp in - therefore increasing the number of lines (typically forms that post back to themselves etc) - some of these forms might have lots of validation going on - therefore several IF-THENS - and perhaps within these there might be forms that post back with an error message to the same page etc... For myself it is *very* common place to have pages in excess of 1000 lines, one application I've written recently has a main page which then based on user selection might include 1 of 4 or 5 .asp's into it- thus again generating a mammoth total page... I just wondered what the norm was...I understand the above quote from the FAQ - but I'm not convinced it would always be prudent to "Consider optimizing the code and perhaps spreading the work over multiple pages" - unless these were 'included' instead of being redirect to etc.... Please dont see this as a criticism or anything - I just stumbled across it, and like most ASP FAQ's found it an interesting read and wondered what other developers did... Cheers all, oh and happy new year :o) Rob
On Wed, 31 Dec 2003 12:25:48 -0000, "Rob Meade"
[quoted text, click to view] <robert.meade@NOSPAMubht.swest.nhs.uk> wrote: >Lo all, > >Just reading through and saw this in the FAQ... > >*********************** ><some error> >/file.asp, line 1294 > > >This seems to be *way* too many lines of ASP code to (a) manage and (b) >expect to run efficiently. I've worked on some pretty big ASP applications >and I don't recall ever having an ASP script more than 250 lines long. > >*********************** > >I must confess that I dont think I've ever written anything thats as short >as that - unless it was a real basic attempt at testing something - most of >my pages have both html and asp in - therefore increasing the number of >lines (typically forms that post back to themselves etc) - some of these >forms might have lots of validation going on - therefore several IF-THENS - >and perhaps within these there might be forms that post back with an error >message to the same page etc... > >For myself it is *very* common place to have pages in excess of 1000 lines, >one application I've written recently has a main page which then based on >user selection might include 1 of 4 or 5 .asp's into it- thus again >generating a mammoth total page... But I assume these are includes, and the actual file on disk isn't as long as what's being served, correct? I've been working to break my pages into extremely small chunks with includes/classes to make it easier to manage as well as speed download times since the classes get cached. I'm not perfect at it by any means, but I doubt any of the resulting ASP files are more than 200 lines or so. On the other hand, I also tend to break lines for readability, and while I have built long SQL queries in a single line, I often will build them in multiple lines. Again, for management ease, as well as code readability. [quoted text, click to view] >I just wondered what the norm was...I understand the above quote from the >FAQ - but I'm not convinced it would always be prudent to "Consider >optimizing the code and perhaps spreading the work over multiple pages" - >unless these were 'included' instead of being redirect to etc.... I think that's the general consensus among all programmers. In another life I used to write assembler language that had to fit in memory as little as 256 bytes, and crunching code was an art form. Now I don't get penalized for being sloppy, but I'm also able to make my code more manageable and readable. Which in my case can be importnat because someone modifying my code may have no contact with me and little concept of what my original intent was. Now, If I'd just take time to comment fully... :)
I enjoy reading your posts.
I have been known in a crunch to do the same thing ... I could easily see your crunch-time project starting something like this for me ... Dim theText, theSectionArray, theQuestionsArray theText="Section A###Another Question?###Another Question?###Another Question?###Another Question?###Another Question?###Another Question?###Another Question?###Another Question?###Another Question?###Another Question?@@@Section B###Another Question?###Another Question?" theSectionArray = Splt(theText, "@@@") LOL!!! Been there. I know, I would use a database too ... lol ACTUALLY, I am writing to ask your opinion on the performance of using those classes, versus using straight subroutines. I have heard of performance leaning the way of the subroutine, and would certainly like to hear you comments to better my skills. I will use classes when doing intranet, extranet stuff with X number of users, but for web I have been sticking to subs and functions. Thanks in advance for any response :) Brynn www.coolpier.com (under-construction ... 2 days old) On Wed, 31 Dec 2003 10:32:19 -0600, "Dave Anderson" [quoted text, click to view] <GTSPXOESSGOQ@spammotel.com> wrote:
>"Rob Meade" wrote: >> >> For myself it is *very* common place to have pages in excess >> of 1000 lines, one application I've written recently has a >> main page which then based on user selection might include 1 >> of 4 or 5 .asp's into it- thus again generating a mammoth >> total page... > >Are you actually seeing line numbers over 1000, or are you counting the >lengths of the #includes? > > >> I just wondered what the norm was... > >Do you post scripts back to themselves? That would certainly add to the >length. As could the construction of SQL strings instead of SP calls, >depending on complexity. > >I can't speak for anyone else, but my scripts tend to be under 300 lines, >with about 20-30% whitespace or documentation, and typically under 100 lines >of server-side code. I often use process-and-redirect scripts, which are >typically quite short. > >Most of my process-and-display scripts also #include about 900 lines, of >which the vast majority is corporate branding for common look & feel. That, >in turn, is lessened by the use of client-side .js and .css files (as >opposed to inline). If not for these abstractions, I would certainly exceed >1000 lines on almost every script. > > >-- ASIDE -------------- >One of the most burdensome scripts I can recall was one I made intentionally >large. I had previously agreed to code a "20 question" survey. When the >final copy hit my desk (a week before the deadline and *after* the paper >version had already been printed) it turned out there were 20 *sections* and >132 questions. > >Normally I would break such a thing into multiple scripts, but the time >constraints and my sense of being ambushed convinced me to do the whole >thing in one page -- and post back. Even so, it's a slim 600 lines (plus the >boilerplate includes), of which only 20 or so are devoted to storing the >responses and roughly 100 to populating the various sets of OPTION tags. > >I certainly think my script is easier to navigate than the survey it >produced (users predictably complained of survey fatigue). I needed an >"emergency" to make it 600 lines. 1000+ sounds like a crime to me. In fact, >I have a colleague who writes 1000-line scripts, and I absolutely HATE >working on those things**. Ugh. > > >**Confession time. I also hate them because they are unstructured. I >separate processing from presentation as much as possible, whereas my >colleague does not. My HTML sections are continuous, with tokens for the >dynamic content. The only interlacing I do looks something like this... > > <INPUT NAME="LastName" VALUE="<%=Page.LastName%>"> >or <SELECT NAME="Ethnicity"><%=Page.EthnicityList%></SELECT> >or <TABLE><%=Page.TableRows()%></TABLE> > >...where [Page] is the only variable I declare with page scope. > > >-- >Dave Anderson > >Unsolicited commercial email will be read at a cost of $500 per message. Use >of this email address implies consent to these terms. Please do not contact >me directly or ask me to contact you directly for assistance. If your >question is worth asking, it's worth posting. > >
[quoted text, click to view]
"Brynn" wrote: > > ...I am writing to ask your opinion on the performance of > using those classes, versus using straight subroutines. I > have heard of performance leaning the way of the subroutine, > and would certainly like to hear you comments to better my > skills. Note that I use JScript for this, so I don't know if it answers your question. That said, I don't know that there is enough performance difference to justify one over the other on the basis of performance alone. I certainly think there is merit in abstracting the processing from display -- the only question to be answered is whether that benefit exceeds any possible efficiency benefit. In this case, I believe it does. I have not noticed any performance issues whatsoever, and have benefitted greatly from the "maintainability" improvements. Both the development and maintenance cycles are reduced with abstracted processing. If you're interested, here's a typical script outline: ================================================================================ <%@ Language=JScript %><% var Page = new PageVariables() //-- Nothing else!! %><!DOCTYPE ...><HTML> ... </HTML><% function PageVariables() { ... this.DataElementToDisplay = [whatever] ... } %> ================================================================================ If you prefer to see the processing up front, you can put it there. We prefer it at the end. In any case IIS doesn't care. The important distinction here is that the HTML is all in one section, rather than interlaced. There are occasionally times when we uses loops in the HTML section for readability purposes, but that's as close as we get to interlacing. There is certainly no database processing in the middle of the Response stream. I hope this was at least interesting. -- Dave Anderson Unsolicited commercial email will be read at a cost of $500 per message. Use of this email address implies consent to these terms. Please do not contact me directly or ask me to contact you directly for assistance. If your question is worth asking, it's worth posting.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |