Monthly Archives: August 2017

Memformat tabel HTML otomatis dengan JavaScript


A member on the Forum mentioned in a post how he was working with (or trying to work with) an article he recently read by a guy named David F. Miller.

Basically, the article had some interesting JavaScript code that automatically changed the background color of every 2nd row in an HTML table. The reasons for wanting to do this are many; here are a couple of big ones:

  • To make the table look good
  • To make the table information easier to read

You can see an example here.

I want to point out a couple of things:

  1. This is for tables that are being used to present data. Think of spreadsheets, MS Excel et cetera.
  2. Typically when you’re displaying data in a table, you would be sucking it in from a database using something like PHP (articles on PHP coming soon, grasshoppers!) and in that case you would just do this in the PHP code and not bother with doing this with JavaScript.

Because of that (the PHP thing), when I first took a look at the article, I did not pay much attention. But about 2 weeks later, I found a place (my new HTML tags/codes page) where I could use this script!

So I got the JavaScript code, and put it to use on my page. Everything worked fine ‘out of the box’, except for one thing – it would not allow you to use the script on more than one table on the page … I needed to use it on many.

I could have taken the easy way out, and just manually colored the many table rows. But I quickly realized that the manual way was going to be just too much freaking work – too much work just goes against my basic sensibilities. Too much video game playing time would be lost, so something had to be done!

I got out my nerd-cap and started banging away at the JavaScript and CSS code that made this nifty script work. Thinking I could also write a nice article out of this, I settled on a variation of the script (out of a few) that made it easy to apply the script to as many tables as you wanted to; easy even for the non-programmer.

The original article was called ‘Zebra Tables’ (as in zebra stripes), so I thought that my modified version of the script should be called ‘Killer Zebra Tables’.


Since this is an article about using the Killer Zebra Tables tool (script) and not about how the JavaScript programming works, I will spare you the details of the JavaScript.

That being said, you are free to go into the code and check it out for yourself. You’ll find it well commented (my own and some left over from David F. Miller) along with some testing code that will allow you to ‘see’ the script work as it styles the tables.

The whole thing can be downloaded here.

You will find in the ZIP file a simple HTML page and a .js file with all the JavaScript. I left the required CSS code in the HTML page since it’s really short, but you can easily extract it into its own CSS document.


  1. Applying the CSS.
  2. Applying table ID’s.
  3. Changing the HTML ‘body’ tag to ‘talk’ to the script.
  4. (Optional) Setting the standard color in the .js file.


Let’s start by looking at the CSS:

.taglist {
border: 1px solid #666666;
margin-top:40px; margin-bottom:30px;
.taglist tbody tr td {
font-family: "lucida grande", verdana, sans-serif;
font-size: 8pt;
padding: 3px 8px;<
border-left: 1px solid #D9D9D9;
.taglist tbody tr.selected td {
background-color: #3d80df;
color: #ffffff;
font-weight: bold;
border-left: 1px solid #346DBE;
border-bottom: 1px solid #7DAAEA;

Even if you don’t know any CSS, all you really need to know about the above code snippet is:

It’s CSS code – CSS is used to style web pages. This code targets our tables specifically. In a nutshell, I’ve created a CSS class called ‘taglist’ and 2 other more targeted CSS selectors (‘.taglist tbody tr td’ and ‘.taglist tbody tr.selected td’) that help to further define the look of the tables.

What you have to do is ‘tag’ your tables with the class: ‘.taglist’. You do this by going to your table code and write this:

<table id="table1" class="taglist">

I’m not going to go into the details of CSS; this is standard stuff and if you are having problems, you should go to my CSS Tutorial website.

Again, all you need to know is that for each table that you want to have styled, will need this text included in its’ tag:class=”taglist”


The next thing you need to do, is to give a unique ID to each table that you want the zebra tables script to affect.

To do this, all you need to do is ‘tag’ each table with the text ‘id=’ and the unique name you want to give it. The ‘unique’ name can be anything as long as it’s the only tag on the page with an ID of that name.

For example:

<table id="table1" class="taglist">
<table id="table2" class="taglist">

You’ll notice that one table has an ID of ‘table1’ and the other has an ID of ‘table2’. There cannot be another table (or any other HTML tag) with either of these ID’s. I hope this makes sense? The JavaScript uses these unique ID’s to find the tables that you want to have affected by the script.


Finally, we’re almost done! Ok, the last thing you have to do is ‘talk’ to the Killer Zebra Tables script. You do this in the HTML ‘body’ tag. As with many other things in life, it’s just easier if I show you:

<body onload="stripeTables('table1','red','table2', 'blue');">

So what I’ve done in the HTML ‘body’ tag is to tell the browser to ‘talk’ to the script called ‘stripeTables’ and fed the ‘stripeTables’ script some information it needs – the name of the table and the color I want the alternate row to be. For each table I want the script to affect, I need to include the tables’ unique ID (that I gave it) and the color:

‘table1′,’red’, -> for the first table

‘table2’, ‘blue’ – > for the 2nd table

As you can see it always works in pairs: table ID + color. You will also notice that I single quoted each table ID and each color with commas in-between.

If you’re a little confused by this, don’t worry; it will soon clear up for you. Just download the sample and try it out, change the colors and see what happens. If you’re still having problems, just post a question to forum and I will answer.


If for some reason you want to change the standard color used in all the tables (the other color that makes the zebra pattern in your tables) you will need to open up the ‘killerZebraStripes.js’ file and look for this code:

// hard coded here and applies to all tables.
var oddColor = "#eee";
// hard coded here and applies to all tables.

What you are actually looking for is this line of code:

var oddColor = "#eee";

This can be found around line 30 of the page. Right now it is set to an off white color: ‘#eee’. You can change it to any other color that you want – just type it in and re-save the file.

Build your own Dynamic Web Applications

Using Model-View-Controller (MVC)

By Richard Mischook

It’s easy to fall into a trap and treat designing dynamic web sites in the same way one treats developing static web sites. In this article we will be looking at how the MVC design pattern works and why we should use it.

This article is part of a series on server side development exlusive to


There are lots of technologies and tools available for building dynamic web applications. These include ASP and .Net from Microsoft, J2EE from Sun Microsystems, PHP, Cold Fusion – the list goes on. Regardless of which of these technologies/frameworks one selects, there are certain common patterns that one finds show up over and over again. One of the most talked about is the MVC or Model-View-Controller Pattern and yet for those who might be used to a page-centric style of design, understanding how the MVC pattern works or the need for it can be difficult.

This article hopes to explain the MVC pattern as simply as possible. In subsequent articles we will look at a simple framework I have evolved to enable MVC development in Java without relying on outside frameworks such as Struts.

The Page-Centric Design Pattern

Before discussing the Page-Centric Pattern we need to distinguish between a dynamic web application and a static web site – although for many readers this will probably be obvious. Essentially a static web site is composed of HTML pages that never change, or only change when the author/web-master manually changes them. Contrasted to this, a dynamic web site features content that changes in response to user input. The simplest example is a search engine like Google where what you see depends on what you asked for. More complex examples include shopping and banking sites. Because of their interactive nature these sites can be thought of as applications or programs – that is, tools that can be used to do work.

Some of the easiest technologies for adding dynamic features to web sites include Active Server Pages (ASP), Java Server Pages (JSP), PHP and Cold Fusion. Each of these technologies shares a common attribute: the ability to embed tags on the page that are parsed by the server before being delivered to the client web browser. For example the following bit of JSP:

<%out.println(new java.util.Date())%>

will print the the current date and time when the JSP page is loaded. Hitting reload in your browser will cause the value that is displayed to change each time. Voila – a simple dynamic page.

The ability to embed tags in a page coupled with some simple programming logic opened doors previously been to many web developers. The only real option for dynamic web site creation prior to that was CGI scripting using programming languages like C which, for many HTML developers, made dynamic web scripting un-achievable. The flip side of the accessibility introduced by tag-based development though, is that some bad habits were introduced. For HTML developers used to the web page as the center of their universe, it made sense to put everything in the page. This might be OK for a simple web site wanting to display a counter or the current date and time, for example. But when you start building applications with complex business logic and many functions, this approach can turn into a nightmare.

Anatomy of an Application Request

It might help to look at what generally happens when a user makes a request from a web application. Take a look at the diagram in figure

The first thing a user does is make a request. Let’s use the search-engine example: a user types in what they are looking for and hits the search button (User Makes Request). The web application server receives the request and evaluates it (Evaluate Request). The next step for the application is to assemble the data that the user is looking for, i.e. matching web sites (Retrieve Data). And finally the user needs to be shown the results of the search (Show Response).

Many applications (web or otherwise) will tend to follow this pattern, at least in outline. The meat of the application lies in the work that is done in steps 2, 3 and 4. The Page-Centric model puts all of the code to manage these steps in one place – the page. A smarter approach breaks the code up into components, each of which handles a particular step in the process. Some reasons for doing this are:

  • debugging pages can be difficult and time consuming, whereas debugging components is often far easier
  • using components promotes code-reuse, e.g. a login component can be used from different pages
  • refactoring operations in response to changing requirements are hard to do on pages
  • moving all the tricky stuff out of pages means that non-programmers can work on the pages while those with programming skills can focus on the components

We could discuss this in greater detail but it is beyond the scope of this article. Those of you who have had to deal with complex and hard to understand (and debug) ASP/PHP/JSP pages may already have some idea of what I am talking about though.

MVC Understood as Data-Presentation-Logic

When I first read about the Model-View-Controller pattern I was confused by the terminology. I have always preferred to think of it as Data-Presentation-Logic. Here’s why:

Model = the information that will presented to the user (Data)

View = the component(s) that handles the way that the data will be shown to the user (Presentation)

Controller = the component(s) that evaluate and handle the user request (Logic)

So the model is the data that the user asked for; the view is how the data will be formatted for presentation to the user; and the controller is the component that evaluates the user request. We can map these components to our process in figure 2:

Earlier I mentioned that the MVC pattern really starts to shine when the application get complicated. Our search engine example is useful but perhaps a little simplistic. I want to look at a slightly more complicated scenario to illustrate one way it could be implemented using MVC. In this scenario the user wishes to load a dashboard-style page like My Yahoo, for example.

The first thing we need to do is identify some of the things that can happen in response to a user request to load his or her dashboard (note that the scenario below is still far too simple for a real-world application).

We start with the request by the user to show the dashboard and follow through some of the things that can happen:

If the user is not logged-in then we need to log them in.

After logging in (or if already logged in) we need to check their access rights (for simplicity I have omitted dealing with a fail here).

If the user has not specified their preferences (e.g. they have not chosen what content they want on their dashboard) then we forward to an appropriate module/component to handle that.

Otherwise we fetch the data and show them their personalized dashboard.

Notice that in this scenario there are a few decisions that need to be made in response to the user’s initial request. It is the Controller’s job to make those decisions and invoke the appropriate path in the process. Note also that the Controller can use other components to get things done: a Login component to handle logging the user in, a Data Access Component to get the data from a database and so on. Each of these can be thought of as helpers or business objects because they provide services that can be re-used in other contexts. Note also that as each sub-component is invoked (e.g. login), we probably need a mechanish to send processing back to a Controller so that the user’s original request (to see the dashboard) gets executed.

At the end of this process is a View component that expects to be supplied with some data – in this case the contents of the user’s dashboard. I’ll talk about how we do this in concrete terms in a subsequent article. The thing to note is that the View component (which could be an ASP, JSP or PHP page) does not care how the data gets to it. All that is required is that when the page is invoked, it is supplied with the data it needs to show the dashboard. The View is and should be a relatively ‘dumb’ component with as little logic as possible.


HTML Forms: Basic Concepts

If you are new to web design in general, then you have to check out my online course on web design before you can benefit from this article to its fullest.


When the web was first invented, it was just an elegant and simple system of exchanging information with the world using a simple page paradigm. Yet one of the problems with simple web pages was that there was no way to gather information from people who were visiting a web site.

To solve this problem, some smart people came up with an extension to HTML (the language/system used to build web pages) called ‘forms.’


An HTML form is made up of a bunch of HTML tags that allow people visiting web sites to enter in information or select information from a list that can then be transmitted to the server for processing.

We all know that HTML tags are used to build a web page; some tags are used to create headers, others to create tables and yet others are used to create forms and form elements. HTML has a bunch of tags that are used to create forms and the sub-elements that make up an HTML form.

To make an HTML form you need to first create the mother of all form tags that creates the ‘form’ and defines its region or boundary:

	        <form action="myFormScript.php " method="post" >
	        … All the form buttons and fields are inserted here

This set of form tags does a couple of things:

  1. It defines the region of the form: Any form tags inserted in between these two tags are considered (by the browser) to be part of the same form.
  2. Tells the browser where to send the information entered into the form.

So what does that mean in practical use?

To understand what that means, you have to understand one important point: the content of an HTML form (what ever the user / person fills in) is sent to the server as a collection of information.

It may be easier to think of an HTML form as a basket of information about a particular subject. So when someone fills in the HTML form, it is like someone is adding things to a basket. When the person is finished filling in the form (the basket is filled) he or she then ‘walks over’ (submits the form by clicking on the ‘submit’ button) to the ‘checkout’ (server) so that the contents of the basket can be processed.

Many times the information that is filled out in a form is sent to a server so that a server script (a server script is like a mini-program) can insert this information into a computer storage program called a ‘database.’

If you ever heard of CGI, ASP, PHP, JSP and others like them, these are server side programming / scripting languages that are often used with HTML forms. As I mentioned above, these languages (ASP, PHP, JSP etc.) are used to create scripts that can read (geeks like to say ‘parse’) the information sent to it using an HTML form.

One last point for this newsletter; as mentioned above, the form tag also tells the browser (Netscape for example) where to send the information, or as a geek would say: where to submit the form too.

This is done with this text: action=”myFormScript.php”. The ‘action’ attribute of the form tag specifies the location of the script that will handle the form data, more about this in part 2.

In part 2 of this little series I will show you some of the HTML form tags that are actually used to collect information from people. I will also show you how to set up a form and even give you a practice script you can work with to see your form in action!

For you more advanced coders who are out there, I also plan to include some flexible JavaScript code that you can use to validate your forms.

can Send emails from Webpages that we create

Option 1: Browser’s built in support for sending email.

The easiest way to send an email is by using the browser’s built in support for mailto:

<a href=’’>Email Me!</a> 

When the user clicks on a link with the ‘mailto’ attribute written in, the browser is smart enough to know that is should open up the default email program and set the ‘to’ address to the one specified in the link.

So in this case the address would be: 

You can get a little fancy by setting the ‘Subject’ field by adding this to the address: have to break up with you because you are a nerd … 

Now that subject will be automatically inserted as well.

Advantages: Easy to do and widely supported.

Disadvantages: Spam bots can pick up the email address listed on the page (but there are ways to protect against that.) – Not all people’s machines will be able to support it. – People can see where you are sending the email.

NOTE: Whenever you create a URL there should never be any spaces in it. In this case this would include the subject we just appended to the URL:

subject=I have to break up with you because you are a nerd …

So to make this proper you would add the space character (%20) like so:

subject=I%20have%20to%20break%20up%20with%20you ... 

This is the strict way of doing it and is best practice, but many browsers are forgiving …

Option 2: Use a server side script.

Today there are many options for sending mail via server side scripting engines like PHP and PERL CGI. PHP has a built in mail function and there are many CGI scripts that will do it for you too.


You would build an HTML form according to the scripts instructions where the form would post to the script, be it in a page (like in PHP) or to a CGI bin script like with PERL CGI.

The problem is that you have to have the server set up to run the scripts and you have to know just a little programming. In addition to that, unless the person enters his email address in a form field, you can’t know who emailed you.

On the positive side, if the user does not have an email program on his/her computer (say he/she found your site while at an internet coffee shop) he/she will still be able to send you an email. Another positive is that spam bots have no way of snooping for your email address on that page. And yet another advantage is that people will not be able to send you an email virus this way, even by accident.