Organisation of ASP applications

Results 1 to 2 of 2

Thread: Organisation of ASP applications

  1. #1
    Join Date
    Dec 1969

    Default Organisation of ASP applications

    I have organised my ASP application by making a separate file for each &#039;action&#039; the server must perform - for example if a user wanted to change their password they would request changepassword.asp to fill in their new password details, and the contents of the form would be submitted to changepassword2.asp where the SQL would be executed.<BR><BR>Looking at professional ASP applications, most of them seem to have one fundamental file, such as toolbox.asp. All the primary tasks are performed by that file, with a querystring to identify the action required, for example changing a password would be accomplished by visiting toolbox.asp?action=changepassword to input the data, with the SQL being executed by toolbox.asp?action=changepassword2 or similar.<BR><BR>Is there any advantage in doing it the second way? The only one I can think of is that the code for the navbars etc only has to be written once, although mine is in include files which work ok at the moment.<BR><BR>Many thanks for your help.<BR>Sam

  2. #2
    Join Date
    Dec 1969

    Default ''Professional'' ASP applicati

    ...are not what you are looking at, in my opinion.<BR><BR>You wrote:<BR>Looking at professional ASP applications, most of them seem to have...a querystring to identify the action required<BR><BR>My opinion is that if you can see the action needed in the URL then the app isn&#039;t as professional as it should be. <BR><BR>Unless it is intended that a user could purposely bookmark such a URL (and if a login is required first, then why would you intend that?), I&#039;d *much* rather see *nothing* in the URL to indicate what is happening under the covers. Meaning using <BR> &#060;FORM Method=POST ...&#062;<BR>to pass info from one page to the next.<BR><BR>Okay, okay, so I&#039;m arguing with a person who isn&#039;t here.<BR><BR>Personally, your way seems much more logical to me. It&#039;s modular. It keeps the pages smaller, more manageable, easier to read, etc., etc.<BR><BR>I think monolithic applications (action=eatLunchWithBernie) get ugly real fast.<BR><BR>About the only exceptions I can think of are pages that allow entry of either all new info or the editing of existing info. In that case, a unified page makes sense because if you need to add a form field or modify the contents of a &#060;SELECT&#062; or or only need to do it in one place. No accidental forgetting to put it in the second (or third? or nth) page.<BR><BR>But if the actions being performed are completely separate, then I&#039;d say keep them separate.<BR><BR>Just my $3.96 (two cents, 1901 prices).<BR><BR>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts