ASP VBScript template system

[Colin Mc Mahon]

Hi all,

I am currently using a system you are probably familiar with if you have
done any templating with vbscript, define a template file with special
tokens in it(like ##Content## etc), load the file and replace these with
strings on each page. This works well but means on some pages there are vast
string concatenations to make up the content areas etc.

I had a bit of a brainwave and started rewriting my templating functions to
support 2 files, the template file and the content file. The template is
loaded via the fso, and some tokens are replaced, then I load the content
file via Msxml2.ServerXMLHTTP which allows me to execute vbscript in the
other file. I then have one page to which all page requests are sent(eg
default.asp?url=/home.asp) which loads the template and loads the requested
content file then merges both. This worked well until I started trying to
integrate it into my CMS!

The immediate problem was users login could not be read from session by the
xmlhttp loaded content page (guessing these pages are considered a different
session), but this can be got around by writing actual cookies rather than
Session vars only, or by maintaining a 'current users' table in the site
database and passing a user token back and forth.

Next prob was querystrings, but I can request these from the 'container' and
pass them down into the second page via Msxml2.ServerXMLHTTP get requests.

The big problem I have hit is forms, i can't think how to pass forms to the
second page, obviously get requests aren't a problem, but I can't change all
my forms to get since the quantity of info in some would kill the
querystring, I also have some multipart/form-data forms that i haven't a
clue how to pass.

The only inkling of an idea I have is to intercept all qstrings/posted data
at the container level into a custom collection and then to pass these to
the secondary page in some way. It's the 'some way' i'm not so sure about :)

I suppose my questions are:
1) Is this approach used out there? If so any performance issues I
should be aware of?
2) Are there any potential security issues anyone can think of?
3) Can I send data via XMLHTTP in the way I have in mind?

Any light/advice/help anyone can provide on this would be appreciated.
Thanks for your time,

Colin

[McKirahan]

"Colin Mc Mahon" <pr*********@takemeout.gmail.com> wrote in message
news:ur**************@tk2msftngp13.phx.gbl...

Hi all,

I am currently using a system you are probably familiar with if you have
done any templating with vbscript, define a template file with special
tokens in it(like ##Content## etc), load the file and replace these with
strings on each page. This works well but means on some pages there are vast string concatenations to make up the content areas etc.
[snip]
Colin

This probably doesn't help but here's what I've done:

I have an ASP file like this ("ABC_Contact.asp"):

<!--#include file="ABC_0.asp"-->
<!--#include file="ABC_1.asp"-->
<!--#include file="ABC_Contact.htm"-->
<!--#include file="ABC_2.asp"-->

Where the content is in "ABC_Cont.htm" and
"ABC_0.asp" contains common constants, variables, etc.
"ABC_1.asp" contains page header and left side navigation.
"ABC_2.asp" contains page footer code.

[Jean-Pierre Thomasset]

Colin Mc Mahon wrote:

I had a bit of a brainwave and started rewriting my templating functions to
support 2 files, the template file and the content file. The template is
loaded via the fso, and some tokens are replaced, then I load the content
file via Msxml2.ServerXMLHTTP which allows me to execute vbscript in the
other file.
IMO using this component is a bit heavy, maybe using server.execute is
suffficient.

I then have one page to which all page requests are sent(eg
default.asp?url=/home.asp)
Use this method with care because someone could use your page to access
files you do not want to share or cause more trouble.
The immediate problem was users login could not be read from session by the
xmlhttp loaded content page (guessing these pages are considered a different
session), but this can be got around by writing actual cookies rather than
Session vars only, or by maintaining a 'current users' table in the site
database and passing a user token back and forth.

Next prob was querystrings, but I can request these from the 'container' and
pass them down into the second page via Msxml2.ServerXMLHTTP get requests.
Using server.execute will solve this problem.
I suppose my questions are:
1) Is this approach used out there? If so any performance issues I
should be aware of?
I don't use it but IMO XMLHTTP is overkill.
2) Are there any potential security issues anyone can think of?
The "default.asp?url=/home.asp".
3) Can I send data via XMLHTTP in the way I have in mind?

I don't know but again it's like reinventing the wheel.

Regards,
JP.

[Colin Mc Mahon]

Thanks for your reply

[snip]

This probably doesn't help but here's what I've done:

I have an ASP file like this ("ABC_Contact.asp"):

<!--#include file="ABC_0.asp"-->
<!--#include file="ABC_1.asp"-->
<!--#include file="ABC_Contact.htm"-->
<!--#include file="ABC_2.asp"-->

Where the content is in "ABC_Cont.htm" and
"ABC_0.asp" contains common constants, variables, etc.
"ABC_1.asp" contains page header and left side navigation.
"ABC_2.asp" contains page footer code.

[/snip]

I see what you are doing and i used to do just that, but i found it
difficult to maintain in terms of page modification, the system i use at the
moment has a single file as a template which is dynamically modified per
page. This template is stored at the application level (or session level) if
required to avoid all those fso calls. It's very convenient in that you can
make changes on one file and that changes a whole site.

I might have to go back to the include method though if I can't figure out a
way to do away with these string concatenations, seriously like 2 or 300
lines of concatenations in some places, the code becomes nightmareish to
maintain!!

Thanks again,
Colin

[Colin Mc Mahon]

Hi Jean-Pierre Thomasset,

Thanks for your reply,

[snip]

I had a bit of a brainwave and started rewriting my templating functions
to
support 2 files, the template file and the content file. The template is
loaded via the fso, and some tokens are replaced, then I load the content
file via Msxml2.ServerXMLHTTP which allows me to execute vbscript in the
other file.
IMO using this component is a bit heavy, maybe using server.execute is
suffficient.

[/snip]

Hmm I hadn't thought of using Server.Execute because I can't capture a
string from it to combine with the template file, or can I? Maybe stop
writing the template to screen if i find a content token, server.execute
then resume? This approach would knock my ideas of caching static pages out
the window but could be good otherwise.
[snip]

I then have one page to which all page requests are sent(eg
default.asp?url=/home.asp)

Use this method with care because someone could use your page to access
files you do not want to share or cause more trouble.

[/snip]

I understand what you're saying, I had in mind to encrypt the q strings and
decode them before passing into the templating functions using a daily
generated key. Thus someone would would need the key to construct valid page
requests, thus highly unlikely someone would create a valid request, plus
the fact a user has to login before they get to the templating system. Any
thoughts on this?
[snip]

I suppose my questions are:
1) Is this approach used out there? If so any performance issues I
should be aware of?

I don't use it but IMO XMLHTTP is overkill

..>> 2) Are there any potential security issues anyone can think of?
The "default.asp?url=/home.asp".

3) Can I send data via XMLHTTP in the way I have in mind?

I don't know but again it's like reinventing the wheel.

[/snip]

Ok gotcha

Thanks again,
Colin

[McKirahan]

"Colin Mc Mahon" <pr*********@takemeout.gmail.com> wrote in message
news:#c**************@TK2MSFTNGP12.phx.gbl...

Thanks for your reply

[snip]

This probably doesn't help but here's what I've done:

I have an ASP file like this ("ABC_Contact.asp"):

<!--#include file="ABC_0.asp"-->
<!--#include file="ABC_1.asp"-->
<!--#include file="ABC_Contact.htm"-->
<!--#include file="ABC_2.asp"-->

Where the content is in "ABC_Cont.htm" and
"ABC_0.asp" contains common constants, variables, etc.
"ABC_1.asp" contains page header and left side navigation.
"ABC_2.asp" contains page footer code. [/snip]

I see what you are doing and i used to do just that, but i found it
difficult to maintain in terms of page modification, the system i use at

the moment has a single file as a template which is dynamically modified per
page. This template is stored at the application level (or session level) if required to avoid all those fso calls. It's very convenient in that you can make changes on one file and that changes a whole site.

I might have to go back to the include method though if I can't figure out a way to do away with these string concatenations, seriously like 2 or 300
lines of concatenations in some places, the code becomes nightmareish to
maintain!!

Thanks again,
Colin

I don't find my method "difficult to maintain in terms of page
modification".

The "ABC_1.asp" and "ABC_2.asp" pages comprise the template;
when you change those the entire site changes. A very straightforward
way to modify colors, navigation, page headings and footings, etc.

Here's a technique I use for concatenating strings:

Append "line1"
Append "line2"

when your done "Append"ing then call "Concat()".

Both are defined in my "ABC_0.asp":

<% @Language="VBScript" %>
<% Option Explicit
Response.Buffer = True
Response.Expires = -1441
'***
' "ABC_0.asp"
'
' This ASP (Active Server Pages) program does the following:
' 1) Supports the "ABC" prefixed ASP pages.
'
'****
'* Declare Constants
'* Declare Constants
'*
Const cABC = "ABC, Inc."
'*
'* Declare Variables
'*
Dim aSTR()
ReDim aSTR(100)
Dim iSTR
iSTR = 0
Dim sSTR

Sub Append(sSTR)
'***
'* Append()
'*
'* Appends strings to array entries ReDim as needed.
'***
sSTR = sSTR & ""
If iSTR > UBound(aSTR) Then
ReDim Preserve aSTR(UBound(aSTR) + 100)
End If
aSTR(iSTR) = sSTR & vbCrLf
iSTR = iSTR + 1
End Sub

Function Concat()
'***
'* Concat()
'*
'* Concatenates array entries into a single string.
'***
Redim Preserve aSTR(iSTR)
Concat = Replace(Join(aSTR,""),"`",Chr(34))
Erase aSTR
ReDim aSTR(100)
iSTR = 0
End Function
%>

[Colin Mc Mahon]

Hi McKirahan,

Thanks for your reply,

[snip]

I don't find my method "difficult to maintain in terms of page
modification".

The "ABC_1.asp" and "ABC_2.asp" pages comprise the template;
when you change those the entire site changes. A very straightforward
way to modify colors, navigation, page headings and footings, etc.

[/snip]

I didn't mean to imply the multiple include method was hugely difficult to
maintain, I just meant that in my particular scenario a one page template
system better fits my needs and I personally find it speeds the site design
process up, and leaves the template somewhat more versatile in that it can
be cached, allows entire pages to be cached, and allows a simple 'drop in'
template replacement system.

Thanks for the concatenation function, I do currently use a very similar
system to concatenate my strings.

The whole drive behind making this change is to decrease the amount of lines
like:
Append "<form action=""/products/deleteCategory.asp?cat=" & g_CategoryID &
"&verify=true"" method=""post"" onsubmit=""return confirmSubmit()"">"
because it is difficult to maintain, particularly in my situation where the
code is still being developed and is subject to frequent change. I don't
want to get rid of my current templating system but i would like to speed up
development time using it, although i'm starting to think it may be more
difficult to do so than i had thought :)

Thanks for your help and suggestions,
Colin

[Jean-Pierre Thomasset]

Colin Mc Mahon wrote:

Hmm I hadn't thought of using Server.Execute because I can't capture a
string from it to combine with the template file, or can I? Maybe stop
writing the template to screen if i find a content token, server.execute
then resume? This approach would knock my ideas of caching static pages out
the window but could be good otherwise.

No, you can't get the server.execute output, at least not with classic ASP.
Another solution is to use classic includes like in McKirahan post. In
fact i am using this technique but with only one include (which is
easier to maintain).
For example i have a content page encaspulated in a sub like that :
<%
Sub MainContent
' do something
' Response.Write something
End Sub
%>
<!-- #include file="MyTemplate.asp" -->
-EOF-------------

And then in my MyTemplate.asp, i just call the sub defined previously :
<HTML>
<BODY>
Some header info
<% MainContent %>
Some footer info
</BODY>
</HTML>
-EOF-------------

I then have one page to which all page requests are sent(eg
default.asp?url=/home.asp)

Use this method with care because someone could use your page to access
files you do not want to share or cause more trouble.

[/snip]

I understand what you're saying, I had in mind to encrypt the q strings and
decode them before passing into the templating functions using a daily
generated key. Thus someone would would need the key to construct valid page
requests, thus highly unlikely someone would create a valid request, plus
the fact a user has to login before they get to the templating system. Any
thoughts on this?

I think this is a goog solution to prevent malicious users from messing
with your application.

Regards,
JP.

[Colin Mc Mahon]

OK, thanks for the feedback McKirahan and Jean-Pierre, it has been most
valuable to me, even if it wasn't what I wanted to hear :)

I think I will go back to the drawing board on this one and look again at
the includes route, I will have to find a different method to cache pages I
think. The include method of templating would have a lower processing
overhead than my existing method at any rate, and maintenance wise it
shouldn't be much different.

Thank you both again,
Colin