By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,885 Members | 1,499 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,885 IT Pros & Developers. It's quick & easy.

how to return value from server.execute call

P: n/a
I am trying to replace a huge chunck of code that currently I incorporate
with an #Include directive. The program rarely has to flow through that
code, so I thought it would be better if I used Server.Execute.

I found I can pass data TO the called asp file by creating an HTML <input>
and erading it after I get there.

However, I also need to read back ONE variable that the called file must
set. I cannot figuer out how to do that. My backup positions are (1) I can
keep on using the #Include technique, and (2) I can use a database to bridge
the gap.

BUT... Isn't there a way to carry data BACK TO the calling asp file FROM
THE CALLED asp file?

I certainly do appreciate the help!

Thanks,

Jim

Aug 5 '07 #1
Share this Question
Share on Google+
17 Replies


P: n/a
=?Utf-8?B?SmltIFJvZGdlcnM=?= wrote on 05 aug 2007 in
microsoft.public.inetserver.asp.general:
I am trying to replace a huge chunck of code that currently I
incorporate with an #Include directive. The program rarely has to
flow through that code, so I thought it would be better if I used
Server.Execute.

I found I can pass data TO the called asp file by creating an HTML
<inputand erading it after I get there.

However, I also need to read back ONE variable that the called file
must set. I cannot figuer out how to do that. My backup positions
are (1) I can keep on using the #Include technique, and (2) I can use
a database to bridge the gap.

BUT... Isn't there a way to carry data BACK TO the calling asp file
FROM THE CALLED asp file?
try session variables:

============== test.asp ==================
<%
response.write "running test.asp<br>"
session("a") = "from test"
response.write "1-A: "&session("a")&"<br>==========<br>"

server.execute "testtest.asp"

response.write "running test.asp<br>"
response.write "2-A: "&session("a")&"<br>"
response.write "3-B: "&session("b")&"<br>"
%>
==========================================

============ testtest.asp ================
<%
response.write "running testtest.asp<br>"
session("b") = "from testtest"
response.write "A: "&session("a")&"<br>"
response.write "B: "&session("b")&"<br>==========<br>"
%>
==========================================

===== result from running test.asp ======
running test.asp
1-A: from test
==========
running testtest.asp
A: from test
B: from testtest
==========
running test.asp
2-A: from test
3-B: from testtest
==========================================
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Aug 5 '07 #2

P: n/a
Server.execute is a dynamic include, so any variables defined in the parent file will also be availabel in the "include" file, since
they execute within the same page scope.

http://support.microsoft.com/kb/224363


Aug 5 '07 #3

P: n/a
"Evertjan." wrote:
=?Utf-8?B?SmltIFJvZGdlcnM=?= wrote on 05 aug 2007 in
microsoft.public.inetserver.asp.general:
I am trying to replace a huge chunck of code that currently I
incorporate with an #Include directive. The program rarely has to
flow through that code, so I thought it would be better if I used
Server.Execute.

I found I can pass data TO the called asp file by creating an HTML
<inputand erading it after I get there.

However, I also need to read back ONE variable that the called file
must set. I cannot figuer out how to do that. My backup positions
are (1) I can keep on using the #Include technique, and (2) I can use
a database to bridge the gap.

BUT... Isn't there a way to carry data BACK TO the calling asp file
FROM THE CALLED asp file?


try session variables:

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Thanks, Evertjan. We made a design decision early on in the project not to
use the Session object -- for various reasons, mostly related to scalability
in some way. But you're right, of course; that would be perfect.

This is why I described one of my fallback positions to be using a database,
which is the way many developers implement Session functionality without the
Session object. I believe MS eCommerce Server (correct name?) does it that
way.

It seems, except for the Session object, any "variables" that can be passed
TO the CALLED asp file are essentially read-only in the sense they cannot be
changed and passed back to the CALLING asp file.

For example, I can create Request.Form(1) in the CALLING file using an
<inputelement, and I can read it in the CALLED file. However, this
expression is not permitted on the left side of an equation, so it seems I
cannot change that value.

Moreover, if I create yet another Form name / value pair in the CALLED file,
that one will NOT be visible to the CALLING file upon return.

Can you think of any way a script can modify a passed value in the CALLED
file so a script in the CALLING file can see it?
Aug 5 '07 #4

P: n/a
"Jon Paal [MSMD]" wrote:
Server.execute is a dynamic include, so any variables defined in the parent file will also be availabel in the "include" file, since
they execute within the same page scope.

http://support.microsoft.com/kb/224363
Thank you, Jon Paal. The variables that are available to the script in the
CALLED file are the ASP object variables like Server, Request, Response,
Application, etc., and most importantly, variables in the Session object.
The VBScript variables do not scope beyond the CALLING file as they do with
the #Include directive. It's very frustrating.

BTW, the article you mentioned has some problems; I think they should pull
it. For example, the data stream to the client includes...

<html>
<body>
<html>
<body>
....
</body>
</html>
</body>
</html>

....which works, but, well they need to do more than just test their examples.

An excellent (albeit somewhat verbose) alternative article is this one:

http://msdn.microsoft.com/msdnmag/issues/0400/redir/

Yet even that one fails to mention (I think) the subject of returning (or
not...) values back to the CALLING script.

Can you think of any other ways?

Thanks,

Jim

Aug 5 '07 #5

P: n/a
"Jim Rodgers" <Ji********@discussions.microsoft.comwrote in message
news:63**********************************@microsof t.com...
I am trying to replace a huge chunck of code that currently I incorporate
with an #Include directive. The program rarely has to flow through that
code, so I thought it would be better if I used Server.Execute.

I found I can pass data TO the called asp file by creating an HTML <input>
and erading it after I get there.

However, I also need to read back ONE variable that the called file must
set. I cannot figuer out how to do that. My backup positions are (1) I
can
keep on using the #Include technique, and (2) I can use a database to
bridge
the gap.

BUT... Isn't there a way to carry data BACK TO the calling asp file FROM
THE CALLED asp file?

I certainly do appreciate the help!
For this scenario the next step from an include file is a VB6 dll. Of
course for various reasons that may not be an option.

For an include file that contains a large set of functions enclosing them in
a class helps to keep the global namespace free.

Server.Execute is not an appropriate solution.

How have you determined that having a large include file is a problem?
--
Anthony Jones - MVP ASP/ASP.NET
Aug 5 '07 #6

P: n/a
"Anthony Jones" wrote:
>
For this scenario the next step from an include file is a VB6 dll. Of
course for various reasons that may not be an option.

For an include file that contains a large set of functions enclosing them in
a class helps to keep the global namespace free.

Server.Execute is not an appropriate solution.

How have you determined that having a large include file is a problem?

--
Anthony Jones - MVP ASP/ASP.NET
Thanks, Anthony!

I have not yet determined that having a large include file is a problem. I
may keep what I have until it is a problem. However, I am not only creating
a specific web application, but I am trying to keep my options open for code
reuse since the project is turning into a decent platform for more work.

Your idea about a VB6 DLL is excellent. I am planning to replace a lot of
my #Includes (containing my VBScript Subs and Functions "library") with a DLL
soon. But it will make more sense to you and everyone if I mention one more
aspect of the problem I have in the current case.

The subject asp file (which currently is #Included and which I would prefer
to be Server.Execute'd) processes a huge number of Request.Form(i) variables
for all kinds of input validation requirements. It is because of the
Request.Form(i) variables that I felt Server.Execute would be a good choice.
I hate having to pass all these TO the CALLED file.

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?

Thanks again for your remarks.

Jim

Aug 5 '07 #7

P: n/a

>
Yet even that one fails to mention (I think) the subject of returning (or
not...) values back to the CALLING script.

Can you think of any other ways?

Thanks,

Jim
You don't have to "return" them as they are avaiable as part of the parent page scope. Just use the variable.

Aug 6 '07 #8

P: n/a
"Jon Paal [MSMD]" wrote:
Server.execute is a dynamic include, so any variables defined
in the parent file will also be availabel in the "include"
file, since they execute within the same page scope.

http://support.microsoft.com/kb/224363
Absolutely nothing in that article suggests such a thing, and it certainly
is false. Maybe you are thinking of Server.Transfer.

Te following are shared, which is a far cry from "any variables":

- Application variables
- Session properties
- Server variables and properties
- Request collections and properties
- Response collections and properties

http://msdn2.microsoft.com/en-us/library/ms525849.aspx
--
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.

Aug 6 '07 #9

P: n/a
=?Utf-8?B?SmltIFJvZGdlcnM=?= wrote on 05 aug 2007 in
microsoft.public.inetserver.asp.general:
"Evertjan." wrote:
>=?Utf-8?B?SmltIFJvZGdlcnM=?= wrote on 05 aug 2007 in
microsoft.public.inetserver.asp.general:
I am trying to replace a huge chunck of code that currently I
incorporate with an #Include directive. The program rarely has to
flow through that code, so I thought it would be better if I used
Server.Execute.

I found I can pass data TO the called asp file by creating an HTML
<inputand erading it after I get there.

However, I also need to read back ONE variable that the called file
must set. I cannot figuer out how to do that. My backup positions
are (1) I can keep on using the #Include technique, and (2) I can
use a database to bridge the gap.

BUT... Isn't there a way to carry data BACK TO the calling asp
file FROM THE CALLED asp file?


try session variables:
>
Thanks, Evertjan. We made a design decision early on in the project
not to use the Session object -- for various reasons, mostly related
to scalability in some way. But you're right, of course; that would
be perfect.

This is why I described one of my fallback positions to be using a
database, which is the way many developers implement Session
functionality without the Session object. I believe MS eCommerce
Server (correct name?) does it that way.
That is duplicating the session object, and if that is done well, the
solution should work the same.
It seems, except for the Session object, any "variables" that can be
passed TO the CALLED asp file are essentially read-only in the sense
they cannot be changed and passed back to the CALLING asp file.
I don't see why not. A "variable" stored in a database should have the
same workings as using the session database structure.
For example, I can create Request.Form(1) in the CALLING file using an
<inputelement, and I can read it in the CALLED file.
But that is not using a serverside daabase.
However, this
expression is not permitted on the left side of an equation, so it
seems I cannot change that value.
And rightly so.
Moreover, if I create yet another Form name / value pair in the CALLED
file, that one will NOT be visible to the CALLING file upon return.

Can you think of any way a script can modify a passed value in the
CALLED file so a script in the CALLING file can see it?
I personally think you should keep to includes
or change your design decision.

It is never to late to improve on design decisions,
they are only to be kept static at your peril.

In the end:

What is wrong with an include,
where the whole code is contained in:

If Not myBoolean Then
' whole code
End If

as opposed to a statement line

If Not myBoolean Then Server.execute "...."

?
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Aug 6 '07 #10

P: n/a
you are correct..
Aug 6 '07 #11

P: n/a
my bad, all page scope variables are not handled, see Dave's comment below.
Aug 6 '07 #12

P: n/a
Jon Paal [MSMD] wrote on 06 aug 2007 in
microsoft.public.inetserver.asp.general:
my bad, all page scope variables are not handled, see Dave's comment
below.
Jon, what are you refering to?
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Aug 6 '07 #13

P: n/a
Jon Paal [MSMD] wrote on 06 aug 2007 in
microsoft.public.inetserver.asp.general:
you are correct..
Jon, what and who are you referring to?
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Aug 6 '07 #14

P: n/a
"Evertjan." wrote:
>you are correct..

Jon, what and who are you referring to?
Me. And my post about what *IS* shared among scripts when Server.Execute()
is used.

--
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.

Aug 6 '07 #15

P: n/a
"Evertjan." wrote:
>my bad, all page scope variables are not handled, see Dave's
comment below.

Jon, what are you refering to?
Evertjan, you really ought to give it a rest. I may be your only defender in
here, and even I tire of the constant policing.

--
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.

Aug 6 '07 #16

P: n/a
Dave Anderson wrote on 06 aug 2007 in
microsoft.public.inetserver.asp.general:
"Evertjan." wrote:
>>my bad, all page scope variables are not handled, see Dave's
comment below.

Jon, what are you refering to?

Evertjan, you really ought to give it a rest. I may be your only
defender in here, and even I tire of the constant policing.
Dave, I think this is nonsense. Why even you?
I am just asking. If you think that is policing, so be it.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Aug 6 '07 #17

P: n/a
"Jim Rodgers" <Ji********@discussions.microsoft.comwrote in message
news:C8**********************************@microsof t.com...
"Anthony Jones" wrote:

For this scenario the next step from an include file is a VB6 dll. Of
course for various reasons that may not be an option.

For an include file that contains a large set of functions enclosing
them in
a class helps to keep the global namespace free.

Server.Execute is not an appropriate solution.

How have you determined that having a large include file is a problem?

--
Anthony Jones - MVP ASP/ASP.NET

Thanks, Anthony!

I have not yet determined that having a large include file is a problem.
I
may keep what I have until it is a problem. However, I am not only
creating
a specific web application, but I am trying to keep my options open for
code
reuse since the project is turning into a decent platform for more work.

Your idea about a VB6 DLL is excellent. I am planning to replace a lot of
my #Includes (containing my VBScript Subs and Functions "library") with a
DLL
soon. But it will make more sense to you and everyone if I mention one
more
aspect of the problem I have in the current case.

The subject asp file (which currently is #Included and which I would
prefer
to be Server.Execute'd) processes a huge number of Request.Form(i)
variables
for all kinds of input validation requirements. It is because of the
Request.Form(i) variables that I felt Server.Execute would be a good
choice.
I hate having to pass all these TO the CALLED file.
What can't the function you call get the form values from the Request
object?
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.

--
Anthony Jones - MVP ASP/ASP.NET
Aug 6 '07 #18

This discussion thread is closed

Replies have been disabled for this discussion.