Visual Interdev 6 / ASP tips and tricks

Warning: this article will be rendered obsolete by Visual Studio .NET coming in 20001. 

There are lots of articles around on how to write ASP and how to architect MS internet applications. We're taking a different approach here by giving a few tips on practical usage..

Interdev problem overview

ASP has always been problematic, and now Visual Interdev is looking a little old tired compared to some of the newer tools on the market.

Interdev graphical designer is not good enough

• it does not produce Netscape4 compatible code for standard HTML form elements  (eg it uses CSS positioning/sizing if you rearrange the controls, instead of using the available element attributes) 
• it breaks down as soon as you start inserting ASP eg putting a script value in a TextArea
• The design-time environment does not interpret include files.

One answer is to use Dreamweaver if you need graphical design:  it expands includes (except insofar as its limitations regarding virtual paths) and doesn't break down too much because of the ASP script on the page. 
Otherwise, we currently lay out the page with hand coded HTML and calls to VB components.  However there are a number of other solutions worth considering:

• XSLT forms: <this will be the subject of a new article, see XSLT/XHTML overview if new to subject> 
  1. design the form in XSLT/XHTML 
  2. code the form in ASP
  3. manage the form data in XML
     - the ASP code passes the current form state as XML data to the XSLT layout template and writes the result back to the browser.
     Note that for complete separation of design from data and code, the ASP can add the data to an XML fragment which is a skeleton page with appropriate client-side code hooks.
• early migration to Visual Studio .NET:  here the design-time controls are compiled and allegedly fully browser compatible.  Form state is managed by sending a hidden form control for every actual form control. 

Interdev does not know about IIS5 (Windows2000) or the script capabilities of current versions of Internet Explorer and other browsers.

• For Windows2000, you should be aware of the new functions such as Server.Execute, Server.Transfer.  You could hack a replacement type library, but this is not really necessary.
• We don't recommend Interdev for client side scripting:  it encourages non-standard MS-specific code without being aware or capable of the newer features available if you do want to create eg IE5 specific applications. 

Really we would like a scripting tool that allowed you to choose a syntax for each client script:  you could choose which document object models you wanted to target with script (eg  IE4 or NS4 or W3C (IE5+,NS6) ) and have the editor use Intellisense and syntax highlighting appropriately - our best solution at the moment though would be EditPlus (EditPlus is a text editor with a lot of powerful features including the ability to color code your source files according to a customisable dictionary files: we use custom dictionaries for XSLT,XML,XHTML1 (if you want one of these ask Jonathan Moore). Dictionaries are also available for ASP and most other scripting languages).
[Actually we don't recommend too much client scripting at the moment:  make sure the site works without client scripting first, then add helpful scripts, that way you avoid browser version dependency from the start:  we think this is as important now as ever as different non-pc based internet devices are becoming more common.]

ASP script problems

• ASP is not currently compiled and does not have typed values:
  Unlike JSP and VS.NET, ASP script is not compiled and does not have typed values:  this inevitably leads to maintenance problems.  The best solution is to use minimal ASP to manage the request/response application flow and call components for the real work.
• No mechanism for passing parameters to a script in another page:  
  • Server.Execute and Server.Transfer do not support passing parameters or query strings: all the request information is passed from the original page.
  • You can instantiate classes and call procedures on other pages only if you have 'included' the page as part of the current page.. which brings us to the next point:
• Unmanageable Included code
  • The source code designer does NOT interpret included pages, so there is no intellisense, and as there is no compilation either, it makes the management and reuse of ASP code libraries very tricky, for example if you want to change a library function.
  • In addition, the include processor effectively adds all your library code to your asp page before processing: if you have a lot of ASP library functions, this can get very inefficient.
    Our recommendations: avoid where possible by using components: exceptions include in-page error tracing, script features not available to VB such as Regular Expressions, and other minor coding conveniences not worth the overhead of a component.

Interdev Intellisense Problems and Workarounds

Intellisense is an extremely valuable aid to code maintainability:  it allows development & maintenance to see what is going on at a glance.  Of course a compiler would be better, but if a '.' dot reference works and pops up the parameters of a function it makes the job of checking the function call is correct a whole lot easier.

ASP does not support typed variables, so all intellisense is late bound and works by interpreting CreateObject and <object> tags  (if only late-bound intellisense worked in VB too).  However, there are a lot of problems with this mechanism:

When using the <object> tag to create intellisense binding in Interdev, at runtime ASP tries to create the object itself before letting you use it:

This has problems:  you cannot use <object> to refer to an object you want to instantiate from a factory class, ie:  the object must be public creatable (because ASP is going to try to instantiate it), and the Set syntax to set the object reference does not appear to be allowed, for example:

<object runat="server" progid="ewShops.ewFactory" id="Factory"></object>
<object runat="server" progid="ewShops.Product" id="oProduct"></object>
<%
    'this doesn't work: ASP tries to instantiate oProduct itself (which may not be publicly creatable)
    'also, ASP does not let you use the SET statement to reassign an object created with the <object> tag
    set oProduct = Factory.Products(1)    'normally a valid statement, but produces runtime error
%>

Some workarounds to enable intellisense references are:

use WITH, eg:

With Factory.Product
    .DoSomething
End With

This also works with nested WITH statements, eg:

With Factory.Shop
     '....
  With .Products
    With .Products
      .DoSomething
    End With
  End With
End With

An alternative ugly workaround is to insert a never executed CreateObject line:  the design time processor will examine the CreateObject statement and enable intellisense for that object using the library specified 

<%
Dim oProduct    'untyped asp variable
'Bogus code to enable intellisense
If 1 = 2 Then    'ie never execute this line
    'This line is illegal (Product is not a publicly createable object)
    Set oProduct = CreateObject("ewShops.Product")
End If

'Real code:
Set oProduct = Factory.Product(ProductID)
'Intellisense now interprets as a Product object, thanks to bogus code line...
Response.Write oProduct.Name
%>

Intellisense binding fails to show parameters of Property procedures

In Interdev, intellisense pops up an available property, but when you use it there is a runtime error.. because it didn't warn you about the parameters.
Answer, if you want to enable intellisense and your property has parameters, make it a function.  Otherwise the poor ASP programmer gets very confused. 
[We'd still use property procedures where a get/let pair is wanted and make the ASP guy suffer.]