Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VBScript/DOM structure to dynamically create tables

Status
Not open for further replies.

camillaj

Programmer
Sep 18, 2003
31
0
0
AU
I just found a way on

on how to dynamically create tables using JScript.
I want to add a new row to my table each time the user clicks the "new" button. I don't know JScript at all and the samples using DOM structure with document.createElement("tr") etc.... doesn't work with VBScript (I can't find a similar way using VBScript).

Does anybody have any idea how I can dynamically add rows in a asp page? Is DOM structure an option? How is the syntax then?

Thanks :)
 
ASP is server side, it runs when someone requests the page. You can specify the initial structure here by simply outputting your table.

If you want to 'dynamically add rows' when someone clicks a button you are best off doing it with client-side script. You could use client-side vbscript to do this, but it is an IE-only solution. Instead why not use ECMAscript (the standardized JavaScript) and the DOM.
Have a look here Its a tutorial for a dynamic 'tree' (example: which you can modify to make a dynamic table.

good luck, and check the JavaScript forum for help.

Posting code? Wrap it with code tags: [ignore]
Code:
[/ignore][code]CodeHere
[ignore][/code][/ignore].
 
There are two ways to dynamically create table elements in Internet Explorer: through the document object model and the table object model.

They are used the same way in both JScript and VBScript.

I think you are talking about ASP and not VBScript. This seems to be a common source of confusion for newbies, because they see a lot of JScript at the client and a lot of VBScript at the server. You can use either language in either situation though.

There is no DOM in ASP, because ASP's purpose is to generate a document. So you create tables by emitting table element tags in loops and such, or using things like the ADO Recordset's GetString() method and emitting the result.

So basically, you create table elements in ASP much as you would any other HTML text. That's just it: your ASP creates text, it doesn't manipulate a DOM.

ASP pages are also "one shot." They don't interact with the user. The user invokes an ASP page as a document request (possibly with parameters) and the ASP page runs, creating a document that gets spit back out to the browser. Game over until a fresh page request.

But...

If you truly want to do this client-side, in IE, using the Table Object Model rather than the DOM (which also works), and do this in VBScript... just make the same method calls as shown at the page you posted a URL to. You just do them in VBScript.

Example:
Code:
<html>
<head>
  <script language=VBScript>
    Sub btnInsert_onclick()
      Dim objRow, objCell

      Set objRow = tblDemo.insertRow()
      Set objCell = objRow.insertCell()
      objCell.innerText = &quot;New Col1&quot;
      Set objCell = objRow.insertCell()
      objCell.innerText = &quot;New Col2&quot;
      Set objCell = Nothing
      Set objRow = Nothing
    End Sub
  </script>
</head>
<body>
  <input type=button id=btnInsert value=&quot;Insert Row&quot;><br>
  <table id=tblDemo border=1>
    <tr>
      <td>Col1</td><td>Col2</td>
    </tr>
  </table>
</body>
</html>
The trick is knowing the correct VBScript syntax for manipulating different sorts of things. In VBScript you need to use explicit syntax for managing object references, and you are responsible for removing references explicitly. JScript uses the ECMAScript model of massive, rampant coercion everywhere and a &quot;garbage collection&quot; model of managing objects instead of VBScript's &quot;reference counting&quot; model.

They each have their strengths.
 
What's clever about doing it the way I showed above is that is fairly compact, clear, and flexible. Even so my example was more verbose than necessary to help illustrate its workings.

While clarkin makes a seemingly good point about sticking to the DOM and some generic ECMAScript for browser-neutrality, people need to understand that the browser wars are over for good or ill, and IE is it.

I'm not trying to troll here, but if you read the suggested WebReference.com article you will find that the suggested approach only works on Netscape products once you reach version 6.1, and it also &quot;breaks&quot; IE until version 5.0 of that product. There isn't any mention of Opera, so all bets are off there.

The example I gave is supported in IE only, but all versions from 4.0 and later on Win 3.1, Win32 OSs, Win CE, Mac, and Unix.

It is very hard to get statistics you can trust, but the penalty for using IE-only approaches over &quot;generic&quot; ones is at best only 2% of all browsers in service. If the &quot;generic&quot; approach works for Opera you gain another 2% at the most. I seriously doubt that the 2% of all Gecko browsers in service are at the NS 6.1 level though.

That said, I'm a die-hard myself and normally for public pages I still try to offer the best experience I can for users of even 4.x IE and Netscape. The cost/benefit is hardly there anymore though, and Gecko/Netscape is too little, too late.
 
It's an important discussion, but probably out of the scope of this thread :)

My quick opinion is 'work to the standards and you're less likely to get burnt'. I wouldn't like to tie myself (or all my site's users..) into MS's browser for evermore - what if they suddenly change how IE works? Or change their proprietary add-ons? Or start charging for IE? :-(

Here's a great article about ESPN.com 's redesign and why they opted to support standards rather than one browser (among other things):

On stats, bear in mind that if your site 'breaks' for non-IE users your stats will reflect that.. &quot;We only support IE for our page, and our log shows that 99.6% of browsers accessing are IE - so why support other?&quot; :)

And, er, back to the thread!
..you read the suggested WebReference.com article you will find that the suggested approach only works on Netscape products once you reach version 6.1, and it also &quot;breaks&quot; IE until version 5.0 of that product. There isn't any mention of Opera, so all bets are off there.
That's the trick with using web standards to do stuff, you just let the hard working folks making the browsers do all the hard work. The latest version of all the browsers you mention have worked nicely with DOM / ECMAscript manipulation in my testing - yay.


Posting code? Wrap it with code tags: [ignore]
Code:
[/ignore][code]CodeHere
[ignore][/code][/ignore].
 
Thanks for that. Really good answers. I understand I mix up client side coding and server side, and that seems to be the problem now!

I tried your VBScript way shown below, but now I don't know how to dynamically add content into the cells.

E.g.:
objCell.innerText = &quot;Here I want to retrieve data from DB&quot;

Is it possible to retrieve DB data here? Since this is client script I obviously can't mess around with server code in there. Can I somehow call a function there that retrieves my data from DB, such as:

objCell.innerText = GetDataFromDB()

Is it at all possible to add &quot;server content&quot; to the table cell?

Sorry, I'm confused. Please, any help :)
 
Well, you are kind of stuck and kind of not...

The obvious answer is to abandon client-interactivity. In such a case getting more rows/more data means a server round-trip to fetch a new page with the additional info.

If you have a requirement to support browsers beyond IE this may be where things end. But if you are developing for an intranet or other &quot;closed community&quot; where you can dictate recent versions (say, 5.5+) of IE you have other options.

These can range all over the place. But it depends on what you are really trying to achieve, if you DHTML to manipulate data, you have to get the data to the browser in some manner.

If what you really have is a case where a request of the server returns a bunch of rows of data to be browsed by the user and you just want to &quot;page&quot; through the stuff dynamically, the easiest IE-way to do this is to have the server return the actual data as a CSV file. Then in your HTML you make use of the Tabular Data Control (TDC) and an IE feature called data-bound tables, which can have a page-size less than the full number of rows yet with a little DHTML you can give the users page-ahead, page-back buttons.

The TDC cannot post any changes back to the server though, it is only an info-display device.

Another alternative is RDS. RDS offers another IE data-binding Data Source Object (DSO) behaving something like the TDC, but potentially bi-directional (allowing updates) and with a more generalized object model - more like ADO objects. RDS is actually considered part of ADO.

RDS relies on special components installed server-side that it talks to, to make it look almost like your browser code has a connection to the database server itself. It actually does but through proxy components running under IIS.

RDS is a big topic, and there are several serious security considerations to examine.

Then you have the newer XML options to look at. There are several XML components designed for client-side use, and most of them can fetch data from an ASP host, and several can even post updated data back where desired. Some of them expose an IE DSO interface, so once again they can be used for data binding in IE.

This is also another big topic.


Adding more than a little interactivity at the client side requires a lot of work. You need to keep in mind that web browsers are really designed to display static information and handle simple forms in a request/response mode of operation. They were never intended to work like a desktop application.

You might be better off cutting back your client-side expectations and do more at the server, living with the clunky round-tripping that HTTP is all about. On a LAN this is less of a handicap than over slow dial connections, and you will be &quot;walking a development road&quot; that is well traveled (in terms of getting help, finding useful books, etc). It also makes it easier to support more browsers, since you are not requiring a lot of &quot;smarts&quot; at the client-side.


Here are a few links:




To go much beyond this you might try the ASP Forum.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top