Creating a Server Component with VB - Redesigned - Part 1[1]

this article is for asp developers and visual basic (vb) programmers who want to combine both technologies to write compiled vb components for asp pages. when i reread my initial article, "creating a server component with visual basic" (see http://www.15seconds.com/issue/980930.htm), it struck me that a lot of code has flowed under the bridge since then. i also realized that the way i code a server-side component has dramatically changed from the method described in the previous article. i decided that writing an "upgrade" article was not only important for demonstrating a more manageable way to code server-side components in vb, but also because secure and fast processing components will continue to have an important place with microsoft's internet information services (iis) for a long time to come.

i will summarize what a server-side component is as a short review before explaining how the component described here differs from the one described in the previous article

download supporting source code

server-side components differ from client-side components by virtue of . . . well, which side they are on. a server-side component is a dll file registered on the server computer that serves data to any visiting browser. alternatively, a client-side component is registered on the visitors' computer where the browser is running. with microsoft's internet explorer (ie), these client-side components are called activex plug-in browser components.

activex client-side components can be written in vb and sent, via the internet or intranet, to an ie browser to produce wonderful results. the problem is that activex client-side components are limited to ie browsers. on the other hand, or side, a server-side component written in vb can produce pure html code that will successfully render on any popular browser. the only limitation on the server-side is that the component has to be run on windows iis or a server compatible with the iis application program interface (api). thus, on the server-side, you can call the shots as far as compatibility, whereas on the client-side you're guaranteed compatibility only if you have a controlled intranet that ensures that ie will be exclusively used by all users.

iis server-side components reside within the same memory space as iis and readily wait for a call from any asp page being processed on the server. although you could inject any type of text/code into the asp file sent back to a visiting browser, generally speaking, most server-side components are used to process time-consuming calculations and/or database information that's sent back to the visiting client browser as simple html code. the main point is that you can generate dynamically created text, or html code, from a server-side vb component that will work with any modern browser.

my initial article described how to include the asp object within a server-side vb component so as to capture variables set by a browsers' html form, a url query string, session objects, etc. this made server-side component coding convenient since all the asp objects, and their settings related to each individual visiting browser, were made available to the vb code as global-like variables.

but there was also a downside to this type of server-side component design. i found that managing the many aspects of the asp object from within my components became increasingly complicated as my projects grew. i also found that using property procedures did not add to the management or scalability of my components (property procedures weren't explicitly covered in the previous article so i'll briefly discuss them below).

so the components written in the way described in the previous article had the advantages of having access to all the many variable values provided by the asp object, as well as those that could be sent from an asp file by setting the components' property properties in the manner illustrated below:

asp file code:

<%
aspvariable = "a string example variable sent to the component"

set objreference  = server.createobject("projectname.classname")
objreference. examplepropertyprocedure = aspvariable
objreference.classmethod
%>

vb code:

private strpropertyprocedure as string
public property let examplepropertyprocedure(byval rhs as string)
    strpropertyprocedure = rhs
end property

not only does a vb component that uses the asp object allow access for variable values going in to the vb code, but the asp response object can be used to return text or html from the vb code back out to the asp file that called it. and the asp response.write() method can be called multiple times from anywhere within the vb code.

previous design:

to summarize, a vb component designed like the one in the previous article will have access to all the variable values coming in to it via the asp object, via property procedures, and via database table fields. it would send variable values out to the asp page via the asp object.

again, the downside to this design was keeping up with the many avenues that a variable could take when being sent in and out of the component. these design complications were increasingly detrimental as a project inevitably grew beyond manageable proportions, not to mention the scalability issues related to the overhead from using property procedures and the asp object within the vb code.

the solution was to forgo instantiating the asp object in the component and eliminating property procedures altogether. the newly designed server-side component reduced the complexity of the previous design to a simple set of classes that contained groups of various similar functioning methods that worked without access to variable values that could be mutually shared. the question was "what was the cleanest way to get variable values to the vb code in from the asp file and back out from the vb component to the asp file?"