What can't the function you call get the form values from the
Request oject?
I was referring to the issue of passing the many Request.Form(i)
variables to a DLL. I did not want to stop and write a DLL right
now. Of course, with both the #Include and the Server.Execute,
I do not have a problem with this since Request is valid in those
cases. I would prefer not to write unplanned VB6 DLLs during
the main stretch of an ASP Classic project. In "Phase 2," if you
will, I can marshall together the opportunities for improvements
and assign VB6 DLL development in the context of the big picture.
Since no one could tell me about [an obscure] technique for
getting one or two answers back to the CALLING script, I have
decided to write the validation results to a database. Thus, I
need only to check the database when I return to the first file.
Previously, I acted on the validation results (with
Response.Write's) in the CALLED file. Now I will simply do that
after I return. Even though the second file now does no output
to the client side, it still makes sense to use Server.Execute
because of the sheer volume of Request.Form(i) variables.
Would you agree?
No. The volume of values is not a problem there are
numerous solutions to this.
The appropriate approach is a function call and/or the use
of Classes.
The fact that you need to jump through ugly hoops to attempt
to force a server.execute into a function call semantic (ie you
want it to return a value) indicates that it's not the right tool
for the job.
For me, writing the result to a database is not an inherently ugly
hoop. It's akin to using Session, but without the scalability issues.
Of course, potential problems could sometimes arise if the data
model did not accommodate the subject information, but that did
not happen here. If it had been a problem, then one might be
concerned that the data model was effective, or that the project
management issues (e.g., deadlines) would kick in. The point is
the code was already done in-line, then became an #Include.
All this time, there was one little boolean that was being carried
forward to the rest of the program. I never embarked on using
Server.Execute when I knew I needed something to come back
from it. There was just this one little thing versus hundreds of
lines of code, and it was not in the existing data model at the time.
As it turns out, I now have re-written the whole thing. The large
number of variables to be validated was creating a large volume
of code. However, I had the variables formatting and limits specs
in a database, so I took the additional time to write better code
rather than to brute force it with a lot of easy code. The result
was so tight, I no longer feel the need to extract it into either an
#Include or a Server.Execute. (When we started, validation was
somewhat generic. It became much more complex, however, as
other parts of the project emerged into testing.)
This code section is now back in-line with the "main" program.
There no longer is an issue with Server.Execute.
My original reason for putting it into an #Include was the code
(i.e., the "main" program) was just getting too big. We did not
anticipate how much the client needed this validation. Testing
later revealed the core function, a complex financial simulation,
required much more extensive input validation (including limits
based on previous user inputs) to maintain simulation stability.
Anyway, as the validation section gradually became horrendous,
it first was #Included. Later, I wanted not to load all these lines
of code unless I needed them, hence the Server.Execute idea,
since the program logic could jump around it. About 1/3 of the
time I was processing a tabbed dialog containing a sequence of
input pages. The other 2/3 of the time, this validation section
was non-value-added overhead.
The reason for wanting the SINGLE piece of information back
from the Server.Executed file was simply to know if Validation
had in fact detected an error. If there were an error, the code
would not process the State Transition Matrix; it would simply
render the same tab page again (with error messages added)
rather than navigate to the next state (i.e., user page). It is
not easy to fully explain this here because there are many
aspects both to the technical objectives of the code and to the
history of the project and client relationship.
It's always a judgement call when either scope creep or the
revelation of unknown requirements causes more code to be
developed. Do you write as "ingeniously" as you would like,
or do you blast it out in a manner more consistent with what
the customer is willing to pay? Sometimes you have to make
what is essentially a business decision to write more without
getting paid more in order to protect the client relationship for
future business. Quality is a high level requirement, and that
includes reliability and maintainability of the product. Hence,
there is a need to go back and tighten-up code if it starts
getting too loose or too big. Clients don't always understand
this. I always endeavor to maintain the right (in the contract
with the client) to "keep" code snippets for re-use – just as I
draw on our code library to keep their price under control. I
can justify the extra-and-sometimes-unpaid work this way.
So, I believe the problem at hand is solved, and there are new
problems already.
Watch as I start new threads with deceptively naive questions.
I really appreciate all the participation in this thread. Thank
you for your time.
Cheers,
Jim Rodgers
