is there a way of having a file that's name is a variable (eg
dependant on the user name) act like a include.
i know that you cant define the file for an include asp tag using a
variable and that reading the file using "Response.Write
FSO.OpenTextFile(ppp, 1, False, False).readall" prints the file, and
treating it like a html file. can anyone suggest another way of doing
this?
j.woodcock@find-a-part.com wrote:
> is there a way of having a file that's name is a variable (eg
> dependant on the user name) act like a include.
> i know that you cant define the file for an include asp tag using a
> variable and that reading the file using "Response.Write
> FSO.OpenTextFile(ppp, 1, False, False).readall" prints the file, and
> treating it like a html file. can anyone suggest another way of doing
> this?
http://www.aspfaq.com/show.asp?id=2042
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.
http://www.devguru.com/Technologies/asp/quickref/server_exec ute.html
> is there a way of having a file that's name is a variable (eg
> dependant on the user name) act like a include.
> i know that you cant define the file for an include asp tag using a
> variable and that reading the file using "Response.Write
> FSO.OpenTextFile(ppp, 1, False, False).readall" prints the file, and
> treating it like a html file. can anyone suggest another way of doing
> this?
>
j.woodcock@find-a-part.com wrote on Mon, 15 Oct 2007 09:18:18 -0700:
> is there a way of having a file that's name is a variable (eg dependant
> on the user name) act like a include.
> i know that you cant define the file for an include asp tag using a
> variable and that reading the file using "Response.Write
> FSO.OpenTextFile(ppp, 1, False, False).readall" prints the file, and
> treating it like a html file. can anyone suggest another way of doing
> this?
While Server.Execute is fine if the code in the "include" file is
self-contained, it won't work if you need to reference variables from the
"parent" code. You could pass all variables from the "parent" to the
"include" via the Session object, but with a large number of variables this
is impractical. Try Server.Execute and see if it'll fit your requirements,
if not then read on.
I had to do something similar recently and kludged a function together which
works so far with all the "include" files I've thrown at it - all my
"includes" are mixed ASP and HTML, and use variables from the "parent" page,
so Server.Execute and Server.Transfer were not suitable. My code isn't
pretty, and it's probably not very efficient either, but it works for me.
What this does is takes a filename, reads the file into a variable, and then
takes any inlined HTML and wraps it in Response.Write calls. It then
executes the resulting string which is now all ASP using the Execute call.
If the function returns False then the "include" file is empty or could not
be found. There's no error checking in the function, so you'll have to add
this yourself once you're happy it works.
To use the function, just do something like this:
Blah blah
more blah
Oops, didn't include a variable call to the function. Try this:
Blah blah
more blah
Daniel Crichton wrote:
>
> Execute sTemp
>
> Use this code at your own risk. It shouldn't cause any problems, but
> I can't guarantee it. If anyone can suggest improvements to this I'd
> be happy to hear them.
The basic problem with this is the use of Execute. For an explanation of why
I say this google Lippert and "Eval is Evil"
Many times, application development comes down to a choice between runtime
performance/efficientcy/resource-expenditure and developer convenience. I
typically choose the former.
I have faced this situation (needing to decide at runtime which include
files to load) but up to this point, I have been able to use encapsulation
techniques to avoid using Execute. However, at some point, a choice will
need to be made between the memory/cpu consumed by loading all the
encapsulated functionality
and the resources consumed by using Execute to avoid loading the entire
shebang. My intent in making this post is to make sure readers know that
this choice should be an intelligent one based on testing and measurements,
rather than just doing the one that makes writing the code a little easier.
--
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"
Bob wrote on Fri, 19 Oct 2007 07:59:12 -0400:
> My
> intent in making this post is to make sure readers know that this
> choice should be an intelligent one based on testing and measurements,
> rather than just doing the one that makes writing the code a little
> easier.
Oh, I agree. Sometimes it's just not possible to rewrite everything,
especially if the customer wants it finished yesterday. I always try to
avoid this sort of thing, and only use includes for common functions if
possible, but for one particular case this was the only solution I could
come up with in the specified timeframe and so far it's worked flawlessly,
and there's been no noticeable performance degradation (my use of it is on
an intranet system with a small number of users and a low transaction rate,
not a public web site).
--
Dan