Comment On ASP = ASP Server Pages

Ah, those freshman follies!

I did have one occassion where I was told to build a small, data-intensive internal site, but explicitely denied the opportunity to make it dynamic.  So I wound up putting the data in MS Abcess, and using MS Word .dot files with bookmark objects to make life manageable, dumping a lop of .htm.

See, boss!  You said static!

As far as this WTF goes, two things we all need to do are grasp the cost of each act we ask of the system, and RTFM.

Aside: Alex Papadimoulis , thanks for the boot to the head about tlkp_ a few days ago.  Made me rethink the design of a pet project, with positive results.

smitty_one_each:

 opportunity to make it dynamic.  So I wound up putting the
data in MS Abcess, and using MS Word .dot files with

I must say that I have seen a nearly complete implementation of cold fusion (cfm) implemented in asp 2.0 using the same parsing based approach.

Try not to think that this is the exclusive domain of juniors and newbies, I am periferaly aware of stuff created by MCS France that didn't want to confuse people with <asp:controlType  ... ></asp:controlType> so they created a kind of FrontPage webbot that converts custom tags to asp.net tags when you upload them to the server.

<%=orderTotal%>

<%=orderTotal%>

Anonymous:

Isn't this exactly the philosophy behind JSTL?



It's too confusing to write

<%=orderTotal%>

so instead we write

<%=orderTotal%>

(No, I'm not justifying the WTF code, I'm bashing JSTL.)

<c:out value="${order.total}"/>

Of course I could mention the other WTF nobody has noticed, abusing the string datatype to hold large amounts of changing content when a StringBuilder should be used.  Their string abuse is probably the largest bottleneck of their application.

And in case you are wondering, StringBuilder DOES exist for VBScript (aka Classic ASP) and VB6.  For Classic ASP check out http://www.15seconds.com/howto/pg000929.htm

For VB6 you have to include a COM object, but you can google it if you are curious.

Anonymous:

Anonymous:

Isn't this exactly the philosophy behind JSTL?



It's too confusing to write

<%=orderTotal%>

so instead we write

<%=orderTotal%>

(No, I'm not justifying the WTF code, I'm bashing JSTL.)

I meant, we write

tag:

Silly microsoft types, don't you know templates are so 1990's?  Transformations are where its at now.

richleick:

I have to disagree to some extent that this is a wtf.  Especially from the other wtf's we have seen.  I worked for a company that implemented this same type of philosophy.  It allowed us to port the code quickly.  In our world, we would build websites for various companies.  Rather than constantly changing the .asp code and/or .html, we had standard functions like this that would process "template" type files.  It was simply a matter of changing the template for each customer.  Granted, it could probably be implemented a little better using vb com dll's and I'm sure .asp is not the fastest when implemented this way.  But a wtf?  Not really.  (imho)

This is why ASP was invented.  You can already have variables and function calls in an ASP.  An ASP is a template already.

I think you're smoking crack.  IMHO. 

Anonymous:

Anonymous:

Anonymous:

Isn't this exactly the philosophy behind JSTL?



It's too confusing to write

<%=orderTotal%>

so instead we write

<%=orderTotal%>

(No, I'm not justifying the WTF code, I'm bashing JSTL.)

I meant, we write

Without JSTL

 <%@ page import="com.mycompany.myapp.UserContext" %>

 <% UserContext uc = (UserContext) session.getAttribute("userContext"); %>

 <%= uc.getGroup().getName() %>



With JSTL



   



With JSP 2.0 EL



    ${sessionScope.userContext.group.name}



You're so right. JSTL is definitely useless.  And that expression language crap.  I mean really, who needs it?

Anonymous:

In your favorite IDE or editor, try searching for usages of the
getName() method.....better yet, try to use your IDE's refactoring
tools to rename "getName()" as "getUsername()".



Or try to figure out, just from the JSTL expression, what classes are being invoked.

Maurits:

ASP is NOT implementing itself.  The .html file is a static string - no ASP directives are processed by Response.Write.

This isn't really a WTF... it could be sped up by loading the template into the Application object, for example:

Application_OnStart:
    Application("Discount_Template") = CreateObject("Scripting.FileSystemObject").OpenTextFile (cstpg_SHOW_DISCOUNT, 1, False, False).ReadAll

In this page:
    v_Content = Application("Discount_Template")
    ...

Any stale content issues could be fixed by having an admin page which reloads the file into the application string.

So your suggestion is that rather than educate the web developers in the simple syntax of a well-known web language that has been mastered by hundreds of thousands of people, instead we should add a little ASP code to make the server load all HTML pages into memory on bootup.

And the reference about ASP implementing itself is in the Replace() function calls, because ASP will already do that if you use the proper syntax in the page. These people came up with their own syntax which ASP must now detect and deal with. Instead of one ASP file to do everything, they have one ASP file which the user visits, but it loads an HTML file and does ASP-like automated find-and-replace on it, only much slower because it's working through the scripting layer.

Manni:

add a little ASP code to make the server load all HTML pages into memory on bootup.

Anonymous:

It's too confusing to write

<%=orderTotal%>

so instead we write

Actually I would probably write <fmt:formatNumber type="currency" value="${order.total}"/> [8-|]

Agreed, there isn't yet support in IDEs for EL lookups as there is for strongly types languages.  And implementing it would be tricky, as you actually don't KNOW the type of the object. 

However I much prefer JSTL to scriptlet code.  Give me a loop rather than a standard for loop any day of the week.

And JSTL is nowhere near as bad as this WTF.  It still gets compiled into java code - not loaded/searched/replaced at runtime.

Meh, evnafets

overview.tpl:


<p>You have {$entries} entries in the database.</p>


overview.tpl:


$smarty = new Smarty();


$smarty->assign('entries', $db->getEntries());


$smarty->display('overview.tpl');

Select Case TagName
	Case "WC@ServerVars"
	 TagContents = "<TABLE BORDER=1>"
	 TagContents = TagContents & "<TR><TD><b>Server Variables:</b></TD>"
	 TagContents = TagContents & "<TD><b>Value</b></TD></TR>"
	 For Each name In Request.ServerVariables
	   TagContents = TagContents & "<TR><TD>" & name & "</TD>"
	   TagContents = TagContents & "<TD>" & Request.ServerVariables(name)          
	   TagContents = TagContents & "</TD></TR>"
	 Next
	 TagContents = TagContents & "</TABLE>"
	Case Else
	 'no other tags
	 TagContents = "No tags found"
End Select

Anonymous:

richleick:

I have to disagree
to some extent that this is a wtf.  Especially from the other
wtf's we have seen.  I worked for a company that implemented this
same type of philosophy.  It allowed us to port the code
quickly.  In our world, we would build websites for various
companies.  Rather than constantly changing the .asp code and/or
.html, we had standard functions like this that would process
"template" type files.  It was simply a matter of changing the
template for each customer.  Granted, it could probably be
implemented a little better using vb com dll's and I'm sure .asp is not
the fastest when implemented this way.  But a wtf?  Not
really.  (imho)

This is why ASP was invented.  You can already have variables
and function calls in an ASP.  An ASP is a template already.

I think you're smoking crack.  IMHO. 

Free:

I must say that I have seen a nearly complete implementation of cold fusion (cfm) implemented in asp 2.0 using the same parsing based approach.

Try not to think that this is the exclusive domain of juniors and newbies, I am periferaly aware of stuff created by MCS France that didn't want to confuse people with so they created a kind of FrontPage webbot that converts custom tags to asp.net tags when you upload them to the server.

 

 

Maurits:

Manni:

add a little ASP code to make
the server load all HTML pages into memory on bootup.

Sure, why not?  I can see this being perfectly viable.  If
there were thousands and thousands of HTML pages, RAM usage would be a
concern... but we don't know how many pages there are in this app...



Another concern would be the first-hit penalty the first user of the
day will experience.  This could be mitigated by taking all the
Application-level caching out of the Application_OnStart(...) event,
and having each page be responsible for caching itself.



v_Content = "" & Application(this_page)

If v_Content = "" Then

    v_Content = ... ' load filesystem object

    Application(this_page) = v_Content

End If



' ... replace @@ stuff...

Man, I am amazed at how far I come.  I don't miss Classic ASP at all.  Thank God I was able to make the switch to ASP.Net when I did. 

I have to agree with both Tony and Kevin, but I experienced the inverse. I had to change jobs recently (because where I was we were working overtime pretty much everyday and every weekend and I need to go to college everyday after work, so I was losing classes and study time, but anyway), and with that job change I stopped working with ASP.NET and I'm back to PHP and classic ASP [:@]. I miss ASP.NET sooooooooooo much [:'(].

(Talk about job change, I'm from Brazil but I'll be looking for opportunities in Canada next year. Any canadians around? Drop me a line at luciolucio AT gmail dotcom. Thanks.)

Anonymous:

This style of "self-templating" is very often
seen in PHP world. In my opinion templating systems like Smarty are
good only if there's a clear need for controlling the code which goes
into templates (as Smarty allows only subset of functionality put into
templates, you can allow only "safe" methods to be put there). An
example could be a large system where templates are made by
non-programmers and there's so many / so large templates that
programmer himself doesn't want to scan then though or a multi-user
system where users themselves can submit and use their own templates,
so you don't want to see system("rm -rf ~"); snippets there. Compiling
PHP templates with PHP into PHP seems a bit slow, but Smarty uses
pretty robust caching system to save those compiled templates, so it's
really just a first-hit penalty of the first user of the day.

[H]

For those debating the value of templating systems, both ASP and JSP are fundamentaly templating systems.

richleick:

I have to disagree to some extent that this is a wtf.  Especially
from the other wtf's we have seen.  I worked for a company that
implemented this same type of philosophy.  It allowed us to port
the code quickly.  In our world, we would build websites for
various companies.  Rather than constantly changing the .asp code
and/or .html, we had standard functions like this that would process
"template" type files.  It was simply a matter of changing the
template for each customer.  Granted, it could probably be
implemented a little better using vb com dll's and I'm sure .asp is not
the fastest when implemented this way.  But a wtf?  Not
really.  (imho)

Sean:

What exactly is the line of thinking here?



"That asp.dll extension is crap.  Why, I bet I could do my own.  With a scripting language.  That uses asp.dll."

Anonymous:

richleick:

I have to disagree
to some extent that this is a wtf.  Especially from the other
wtf's we have seen.  I worked for a company that implemented this
same type of philosophy.  It allowed us to port the code
quickly.  In our world, we would build websites for various
companies.  Rather than constantly changing the .asp code and/or
.html, we had standard functions like this that would process
"template" type files.  It was simply a matter of changing the
template for each customer.  Granted, it could probably be
implemented a little better using vb com dll's and I'm sure .asp is not
the fastest when implemented this way.  But a wtf?  Not
really.  (imho)

This is why ASP was invented.  You can already have variables
and function calls in an ASP.  An ASP is a template already.

I think you're smoking crack.  IMHO. 

lucio:

I have to agree with both Tony and Kevin, but I
experienced the inverse. I had to change jobs recently (because where I
was we were working overtime pretty much everyday and every
weekend and I need to go to college everyday after work, so I was
losing classes and study time, but anyway), and with that job change I
stopped working with ASP.NET and I'm back to PHP and classic ASP [:@].
I miss ASP.NET sooooooooooo much [:'(].

(Talk about job change, I'm from Brazil but I'll be looking for
opportunities in Canada next year. Any canadians around? Drop me a line
at luciolucio AT gmail dotcom. Thanks.)

Implementation bad, concept good.

Yes, ASP/PHP/et.al. are templating systems - but the problem is they are limited. ASP combines dynamic logic and static content into a single template. Many real world applications need to make a further distinction, and split dynamic logic from dynamic content templates. To get this dynamic-to-dynamic mapping to work requires a metatemplating system. As others have posted, this is neither uncommon nor in any way "bad."

One of the most entertaining web applications I ever built was based on metatemplating. Each page was defined as a series of segments, and some segments could be given parameters. The top level design for the site was quite literally a set of flat-text segment lists. A segment could be used to display static content loaded from another location, or dynamic content (news, product details, etc.) - the behavior of a segment was determined by the parameters given. The format was very simple and let the (highly technology-illiterate) staff rearrange the site as they desired. Underneath this, each segment was built up of fragments. Each fragment was linked to a snippet of HTML that would eventually be fed to the browser. A segment definition could embed information using inlined tags that were essentially escape codes. This made segments easy to edit for the occasional person who understood web design (at a high level). The really hardcore (i.e. me, in most cases) could edit the raw HTML to change the fundamental look of the site. Of course all of this was also connected to a potent CSS system, so aesthetic changes could be made easily by anyone with a good grasp of CSS.

The whole mess was "compiled" at write time when the templates where changed, and the resulting data was cached in various forms for fast access. When a user requested a page, a simple engine would assemble the entire content from cached HTML snippets and dynamic data, and output it to the browser. It was nearly as fast as hardcoding all of the HTML, was infinitely more flexible and maintainable by the staff, and it allowed people with a wide range of skill levels to adjust the site without any security or performance risks involved.

Apoch:

Implementation bad, concept good.

Yes, ASP/PHP/et.al. are templating systems - but the problem is they are limited. ASP combines dynamic logic and static content into a single template. Many real world applications need to make a further distinction, and split dynamic logic from dynamic content templates. To get this dynamic-to-dynamic mapping to work requires a metatemplating system. As others have posted, this is neither uncommon nor in any way "bad."

One of the most entertaining web applications I ever built was based on metatemplating. Each page was defined as a series of segments, and some segments could be given parameters. The top level design for the site was quite literally a set of flat-text segment lists. A segment could be used to display static content loaded from another location, or dynamic content (news, product details, etc.) - the behavior of a segment was determined by the parameters given. The format was very simple and let the (highly technology-illiterate) staff rearrange the site as they desired. Underneath this, each segment was built up of fragments. Each fragment was linked to a snippet of HTML that would eventually be fed to the browser. A segment definition could embed information using inlined tags that were essentially escape codes. This made segments easy to edit for the occasional person who understood web design (at a high level). The really hardcore (i.e. me, in most cases) could edit the raw HTML to change the fundamental look of the site. Of course all of this was also connected to a potent CSS system, so aesthetic changes could be made easily by anyone with a good grasp of CSS.

The whole mess was "compiled" at write time when the templates where changed, and the resulting data was cached in various forms for fast access. When a user requested a page, a simple engine would assemble the entire content from cached HTML snippets and dynamic data, and output it to the browser. It was nearly as fast as hardcoding all of the HTML, was infinitely more flexible and maintainable by the staff, and it allowed people with a wide range of skill levels to adjust the site without any security or performance risks involved.

I"m uncertain what you mean by a need to seperate "dynamic content" from "dynamic logic".  If you are talking about seperating presentation or business logic (database queries, if/then/loop statements to show or hide content, etc) from presentation content (HTML, text, data to be displayed) again, this isn't too hard to implement using standard ASP.  I will readily admit that it takes a little discipline, and ASP/PHP/JSP and similar scripting languages DO seem to encourage blending business/presentation logic with the content and layout aspects of the application.  However, this is no reason to reinvent the wheel and create your own templating system on top of another.  You can implement the entire thing using standard ASP.  You just have to be careful to make this seperation yourself.  With the advent of ASP.NET, its much easier to make this seperation by default.  If this is NOT what you're talking about, please explain.

Also, what you are describing sounds a lot like a CMS, which is readily available in both commerical and open source versions, and isn't that difficult to build if needed.  There is no need to built the "fragments" or "segments" using a seperate kind of markup.  Its just not that hard to layer things appropriately for skinning, templating, etc.  Parsing text files to reinvent the wheel sounds kind of kooky to me. If you're users are technically illiterate, why not create your "templates" as ASP files, but with minimal logic in them, perhaps by only allowing rendering expressions such as <%= customerAddress %>?  How is it more advantageous to make your own parsing system with @@ something @@ or tags or whatever?  Maybe we're saying the same thing, that its ok to seperate things skinning, markup, layout, content, logic, etc and that only the implementation is bad.  But it SOUNDS like you're saying its actually ok to recreate the parsing mechanism which ASP has natively, because SOMEHOW that will make it easier for users to edit content and HTML templates.

I'm not talking about separating logic and content - that's the first level of distinction, which ASP/PHP/etc. handles very nicely. What I'm talking about is separating logic from content and also from the way the content is generated. In my case, the client wanted a site that they could redesign on a regular basis without touching the database access and shopping cart code. I don't mean redesign like changing the fonts and colors - that's trivial with CSS - but changing the actual physical layout and structure of pages.

Web applications are not really my forte, but I'd be shocked to learn of a technique for allowing that kind of redesign on-the-fly that didn't involve a templating system sitting on top of ASP/what have you. This was in the olden days before ASP.Net (which I have no experience with, having moved on to much better projects since then) and for the situation at the time I am not aware to this day of any approach that would have been better.

The segments were build of simple blocks like:

WelcomeBanner
ProductList CurrentPromo
ProductList MensShoes
ShoppingCartBar
Footer

If it isn't blindingly obvious how that's easier for a marketroid to work with than an ASP script, I deeply envy your sheltered career and the wonderful people you work with [;)]

No wheels were reinvented in the making of this film - at least not any wheels which existed at the time.

travisowens:

Of course I could mention the other WTF nobody has noticed, abusing the string datatype to hold large amounts of changing content when a StringBuilder should be used.  Their string abuse is probably the largest bottleneck of their application.

And in case you are wondering, StringBuilder DOES exist for VBScript (aka Classic ASP) and VB6.  For Classic ASP check out http://www.15seconds.com/howto/pg000929.htm

For VB6 you have to include a COM object, but you can google it if you are curious.

I think you've identified the REAL problem. I would bet that STRINGS are immutable, even in ASP. So each of those calls to REPLACE is just creating yet another HUGE string that must be allocated and ultimately collected.