RadarBob
08-01-2002, 05:06 PM
All;
Background
I've been assigned to modify an existing web application that maintains a database. The thing is using IIS, MS SQL Server 7, ASP, VBScript, Javascript. Target browser is IE 5.5 (we're an intranet, although the app was tested to work with NN (version?).
The existing app uses two web pages for each logical data entity. One for "update" and another for "add". Thats six pages total! My immediate reaction when I first saw this was "what the...?". Naturally much of the code is essentially duplicated on each page. Fortunately much of the data validation code is in #include files.
As I am new to web-based database programming, and web development (but NOT a novice programmer - whew!) I had to ask myself if there are some technical considerations for the code redundancy and apparent code maintenance faux pas.
Question:
Are there any reasons why I can't / shouldn't use the same web page for both updating existing data and adding new data records?
What would the general (big picture) structure look like to implement a common data update page? I.E. what code or functions might be SQL, Server-side, Client-side? What are the control structures, and what do they look like, to handle the "are we working with existing or new records?" question.
Discussion
There must be some magic "complementary" code (SQL, ASP, script) that ties it all together. As our application stands now, I suspect it's kludgier than necessary - and redundant data update pages is the most obvious symptom I see.
For example, does the code somehow need to know that it has to fetch an existing record vice not? Does the SQL->ASP->Client page "chain" fail if we try to fetch non existant records?
Do we need the different pages because the client->ASP->SQL chain "fails" if the page doen't explictly know if it's handling a new vice existing record?
I'm at the early stages of really grocking ASP but I know there are "update" and "addNew" methods to the recordset object.
Seems to me the user gets to the page via an explicit "update" or "add" button (these buttons are on different pages in our app), so we can control the "back end" (do we fetch a record or not) and *still* display the data using the same page.
Gawd! I want job security as much as the next fella, but doubling the development, testing, and maintenance load is a poor way to go about it. Excellent coding is the way!
Background
I've been assigned to modify an existing web application that maintains a database. The thing is using IIS, MS SQL Server 7, ASP, VBScript, Javascript. Target browser is IE 5.5 (we're an intranet, although the app was tested to work with NN (version?).
The existing app uses two web pages for each logical data entity. One for "update" and another for "add". Thats six pages total! My immediate reaction when I first saw this was "what the...?". Naturally much of the code is essentially duplicated on each page. Fortunately much of the data validation code is in #include files.
As I am new to web-based database programming, and web development (but NOT a novice programmer - whew!) I had to ask myself if there are some technical considerations for the code redundancy and apparent code maintenance faux pas.
Question:
Are there any reasons why I can't / shouldn't use the same web page for both updating existing data and adding new data records?
What would the general (big picture) structure look like to implement a common data update page? I.E. what code or functions might be SQL, Server-side, Client-side? What are the control structures, and what do they look like, to handle the "are we working with existing or new records?" question.
Discussion
There must be some magic "complementary" code (SQL, ASP, script) that ties it all together. As our application stands now, I suspect it's kludgier than necessary - and redundant data update pages is the most obvious symptom I see.
For example, does the code somehow need to know that it has to fetch an existing record vice not? Does the SQL->ASP->Client page "chain" fail if we try to fetch non existant records?
Do we need the different pages because the client->ASP->SQL chain "fails" if the page doen't explictly know if it's handling a new vice existing record?
I'm at the early stages of really grocking ASP but I know there are "update" and "addNew" methods to the recordset object.
Seems to me the user gets to the page via an explicit "update" or "add" button (these buttons are on different pages in our app), so we can control the "back end" (do we fetch a record or not) and *still* display the data using the same page.
Gawd! I want job security as much as the next fella, but doubling the development, testing, and maintenance load is a poor way to go about it. Excellent coding is the way!