—“You know… writing a Web Application with dBASE is very similar to this.”

Roan looks up from the fire and frowns:
—“What do you mean… this is fun! Pure pleasure… shucks, how can you even compare it with Application writing? I am sure your brain has been fried by all those hours in front of the PC screen. Too much radiation!”

With that he takes a huge sip from the bottle in his hand and he mocks some sort of cerebral incident. His antics with his eyes and spasmodic jerks of the head do not blend well with the frothy liquid and he manages to semi-choke himself. After a furious bout of coughing and snorting, he regains some composure and stares at me.
—“You are crazy, man. Completely nuts!”
—“Why… why do you say that?”
— “Look man, how can you compare the two. Just tell me how?”

Nico comes back and I take the glass of Coke from him. While I took a long sip of the cold brew, Roan described to Nico what happened while he was away. I had to smile at the colorful description, accompanied by dozens of interjections and lots of gestures, most of which were designed to reflect my mental state.

— “Okay, tell us. How do you get to this crazy comparison?” It was Nico and he sat down across from me. “Let’s hear.”

I lounged back in my chair, lit a smoke, and watched the blue smoke dissipate before I spoke. Both men watched in silence. They know me well and they know that I will always reflect for a few moments before I will make a statement.

— “Look, it is like this. Before you can start with an application you must have the urge to do it — and by urge I really mean URGE — without that, well, you will never produce something spectacular. It might be good but it will never sparkle. This urge is something that sits deep inside you and every time that dBASE hits you with a completely unexpected and highly annoying obstacle, that is when this URGE will come to your aid and drive you to write and rewrite one procedure a hundred times until you get it right.
      It is the same with getting a barbecue together. You must have the urge to do it. If you don’t feel the urge, you will give up the first time that it looks like it might rain or when one of the guests has an excuse not to come. The urge will drive you to get the best logs from the field and chop them up to make the perfect fire with the perfect coals. Without this urge, you will start the fire with petrol instead of using carefully selected kindling.” I took one last draw on the cigarette and flicked it into the fire. “The next step is to think about your application. Think about it a lot and you must also talk about it. By doing this, you will become familiar with the application and you will begin to get enthusiastic about it. Your enthusiasm will infect the people that you talk to, and, as they respond, you will become more engrossed in the potential of the application. In a very short while, you will begin to feel this application. You feel it in your mind and you will begin to have visions of people using it. These visions will inspire you to be creative with the application. It will drive you to make the application a pleasure to use.
     It is the same with the barbecue. We talk about it and the more we talk about it, the more we want to do it. This is why we start talking about it long before it actually happens.”

— “Hey guys. Where is the meat? We are starving!” The voice of my wife plucked us back to reality and Roan began to stack the steaks onto a large wooden board.

— “Let’s go eat.” Roan picked the meat up and we walked back to the patio where the women were waiting.

Now this little story carries a lot of truth and there are some valuable principles locked up there. Take the Cyber Cards Application for an example.

As most of you know, I am a co-owner of the LinkAfrica Network and we have a large portion of Afrikaans speaking clients. One afternoon we had a meeting, and at the end of the meeting Nico told us that he has been surfing the Web for days now to try and find a site that offered Cyber Cards in Afrikaans. He wanted to send a card to one of his parents and the old people will just not accept an English card.

We tossed some ideas around and by 15h00 (3 o'clock P.M.), I left for my farm. On my way down the mountain, the Cards thing twirled and twisted in my mind. By the time I reached my home in the valley, I knew that I wanted to do this. Now this was crazy because I am in the middle of a gigantic application for which I am being paid megabucks, and, at the same time, I am busy upgrading all our web sites to 7.5. Well, all of that became less and less important as the Cyber cards began to take shape in my head. By 17h00 I was in front of my PC and I opened FrontPage 98.

For a few minutes I just stared at the explorer interface with the cursor blinking on default.htm.

Almost fifteen minutes later, I minimized the FP Explorer and opened dBASE 7.5. The first step was to sort the tables out. This took about 30 minutes and then I fired Alan’s Web Wizards up — that’s right, I fired the Web Wizards up — although I am very competent with doing what I am doing with dBASE Web applications, I start each one with the Web Wizards. The main reason for this is not the generated code, but the fact that the Wizards generates a HTML input form that contains all the data fields.

Now it is back to FrontPage. Here I began to work on the HTML page. First I sift all the fields out that will be completed by the  server-side scripts. I change them to hidden fields and assign some “blocker” values to each one. Now this might sound crazy and a lot of work… shucks, it is easier to leave them out and create them in the program file and load it into the associated array. True, but there is a reason for this. In my initial evaluation of the input string, I look for specific values in some key fields. A crazy “hidden” value that has to be at a specific occurrence of “=” in my string. If it is not there, I know that someone is trying to “punch” the exe without going through my form. Okay, I am giving some secrets away now, but it is not serious. I am sure your mind is already working on this one, and from the light in your eyes I am sure that you are seeing the value of this.

When all of the fields are handled, either by assigning hidden attributes to them or by leaving them open for the visitor to complete, I go back to dBASE.

Now I take the generated program file, attach one of my custom classes to it and then the serious work of evaluating the input string begins. Each field is handled according to its own needs and requirements. Make sure that your “error” messages are clear and simple.

Once this is done, it is time to test the data input routine. Rebuild the project and fill in the form. Make sure every field has data in it and POST. Now it is back to dBASE. Open the table and look carefully at the last record that was entered. Now is the time to make sure the data is there and in the format that you want. You will see now that with my method of hidden fields, every field should have a value.

Now we take some time to write routines that will do things with the various fields that we want to calculate values for. This is now easier because we know that the input in “RAW” format went through, and every update of oCGI["MYTABLE1*@WHATEVER"]="ThisOrThat" will result in that new value to end up in the table in the field WHATEVER.

Now comes the part where we must make sure that all the input forms, response pages, reports and error responses are all nicely tuned, trimmed and dressed. Take time with this, because the higher you set the standard of presentation and finish, the more your visitors will admire it. High quality finishing is my way of telling my visitor that I value his presence and that I respect him. It is my way of showing appreciation for his visit.

I have seen many sites where the technical stuff under the hood is running like a well-tuned V8 motor, but my oh my, the quality of the graphics, layout, navigation system and general visual appeal sucks. That tells me that the programmer is a self-indulging son of a bi***, so engrossed in his technical abilities that he cares nothing about me, his visitor, and the only real reason for writing the application in the first place.

Okay, enough preaching. Just remember, you are no longer writing an application for a secluded and isolated user group, you are writing for a potential 100 million visitors. Who knows who will visit your site, it might be the CEO of a major corporation and what he sees might inspire him to find out who the designer was. The rest is for your imagination.

Right, now back to FrontPage, where I sorted the general layout and page composition out. Next I went back to dBASE and coded the pages that I want my server to generate instead of having static HTML pages. This took a total of about three hours.

Then it was me and Corel 8. The next two hours or so I spent in getting the graphics together. Just before midnight, I ran the first test pages and it worked like a dream. I spent another hour or so in fiddling with bells and whistles and at 02h15 I uploaded the stuff to the Web Servers. I ran four tests and found some minor glitches in the response e-mail layouts.

Finally, I send myself one of each and every card in the catalogue. Why? Well, it is not worth your while to rely on assumptions when you want to produce a successful Web application. By 03h10 I sent two cards to my partners and went to bed.

The rest of this story is history, and, in the first three days of the site being promoted, it received 4,000 plus impressions. The server crashed twice. The first was due to some clever monkey that thought he could read his card directly from the browser. I fixed that in my program and now a bad string results in a very bland and no frills response page that tells the guy to get lost. The second time it was due to a bad NT dll. I updated that one around midnight on the second night, and since then it is running like a charm. At times, the server is generating the “Layout” page at a rate of one every seven seconds.

What is the moral behind this little story?

First of all, the whole application was designed on the principles of the CSX3 Folder rule.
 

	The CSX 3Folder Rule for VdB Web Applications
	This Rule is aimed at making development and deployment easier for VdBASE Web Applications 1. WebFolder 2. BinFolder 3. DataFolder  To read a bit more about these issues: http://www.vdbase.net/vdbn_how_csx01.htm

This rule allowed me to be completely in control the various components and assured me that if I deployed to the Web, everything will work as designed because the same principles that count on the Web server are in operation on the test LAN in my home.

Lets talk about the BDE. I know that the use of BDE aliases is a well-known and well-used principle. However, I have never written a single web application that that makes use of these aliases.

Why not? Very simple, it is a source of frustration to deploy remotely to a server when you need a person on that end to set the BDE up for you. Secondly, 80% of all Web applications currently being written and tested by dBASE programmers have their roots in some sample application from the dBASE CD or from Ted Blue’s book (“Getting Started”, Blue Star Press, 1999).

So what? Well, all of them are structured to use one of the following aliases: clients, contacts, mailer, stock, mugs, signup or whatever. You can expect something like this: “Well, you are the second guy to come to me for hosting a Signup Application and guess what: your application will work… but with guy #1’s data.” Wow! that is COOL !!!!!

How do we cope with this problem? Simple. Lets go back a few years.

“Use mycontacts”

This told dBASE to use that specific dbf and nothing else. If the dbf is not in the same folder as the application, dBASE will respond with a very simple but clear error message. Now with Web applications we don’t want the data in the BinFolder for various reasons. It is better to have it in the DataFolder and away from the executables. In my experience, it is the best for a rookie to place this DataFolder just one level below the BinFolder.

Why? Your executables will be running in the BinFolder and if the DataFolder is directly under this folder, the use of relative path is a breeze.

“Use mydata\mycontacts” (in this example, the DataFolder is called “mydata”).

This command will find that data no matter where in the world on the ISP server your BinFolder is running. What is the advantage of this? First of all, you will always know exactly where your data is. The most important thing is that for the ISP, your Application be without complications. We monitor our servers regularly, and if we see that a certain server is getting busy due to a site becoming popular, we will move webs around to balance the load on the servers. So, on Monday your BinFolder was at d:\apache\wwwroot\dbusers\yourbin. By Friday it might be at f:\apache\wwwroot\megasites\dbusers\yourbin.

Now if you had a BDE alias in operation on the Rookie Server, your Application will be in trouble when we move it to a bigger server. I will not test the site, I assume you know what you are doing. You will report the error to me, I will configure the BDE (keeping in mind the DUPLICATE thing) and bill you for the time.

It is my opinion that the BDE alias thing has made us lazy and we have succumbed to “easy strokes”. Another reason for avoiding the BDE configuration thing is based on the fact that dBASE is going to get its own data engine and that will remove the need for the BDE. So, while you are learning a new discipline for dBASE, at the same time make your application more universal.

Here is a peek into a typical DataModule from one of my Applications.
 

this.KKMAIN1 = new QUERY()    this.KKMAIN1.parent = this    with (this.KKMAIN1)       left = -1       top = -1       sql = [select * from "mydata\mycontacts.dbf"]       active = true    endwith

No fancy stuff, just plain and simple.

At this point you may ask yourself why don’t I make any mention of the actual WebFolder. That's simple: this is of no consequence to dBASE. Many of my WebFolders are based on a UNIX server on the Conxion Network™ (don’t ask me where because I won’t know). All I know is that this morning it was still in Saudi Arabia. Tomorrow it might be in San Diego. Who cares, as long as my DNS to the domain resolves properly, it is really not important where that WebFolder lies. The WebFolder contains the HTML and the HTML is only a portal to the dBASE Application.

Let’s look at you and your development environment. Not many are privileged to have more than one machine at his disposal, leave alone a fully functional Network complete with a NT server that runs IIS and Apache. I have a 9 PC network in my home, here on the farm, with a NT Server, running IIS and Apache plus a ArgoSoft MailServer and FTP Services. One Win95 PC with Microsoft Personal Web Server (My BigDaddy) <g>… two Win98 machines with Personal Web Server and two laptops (one with Win98 and one with Win95). All these machines have Webs on them and they all serve pages to whoever wants it. This is heaven for a Web Application developer. I can emulate the real Internet here and test everything to pieces.

Is all of this necessary to do a Web Application? Actually no. You develop your application on a standalone machine. Running Personal Web Server on it and you follow the 3Folder Rule, I will guarantee you that your chances of deploying that application to an ISP Server that runs IIS will most probably work the first time, as long as you stay away from drive letters and hard coded fixed paths.

There is no need to test your site across a network to be sure it works. If it works in the browser on your machine, it will work in any browser on any machine that can access the WebFolder. OK, before I get flamed on this, it should work unless someone visits it using a cripple browser.<bg>

For your first Web Application, keep it very simple. Use a small table with just a few fields and make sure you understand what is happening and when. I did a series of documents on the players in a Web application as well as a few articles for The Xbase Files e-Zine about the basics of Web applications. Really spend time in getting a good grip on what your server is getting from the input page, and pay attention to what you do with the data.

Look at this simple example. This is something that can be problematic on the Web, since people from different parts of the world write dates differently and their own machine’s setting might affect how they will see a date field on a form. You really need the date that the entry is made and you need it in the right format.

In your HTML form:

<input type="hidden" name="KKMAIN1*@Dateon" value="01/01/2000">

In your program:

oCGI["KKMAIN1*@Dateon"]=dtoc(date())

Problem solved, the date will be in the format that you either set in your program with SET DATE TO or by whatever is in force on the server.

Now this is just an example one instance where you can rely on your server to provide the right information. There are millions more.

I really hope this will help some of you folks to dive into Web applications. After about 65 successful dBASE Web deployments, I am confident that I know what makes web applications easy to deploy and easy to maintain. I do many “kick-starts” for applications that we host and the most common fault in all the applications that I had to “jump-start” for clients, is the thing around the 3Folder Rule. After many months of deploying web applications, we have made a decision in our business not to host any applications that do not adhere to the 3Folder Rule.

Conclusion

1. We host only those applications that comply with the principles of the 3Folder Rule.
2. We will not deploy any exe if the source code is not available.
3. We do not allow any uploads to our BinFolders.

Greetings from Africa, and I wish you all a very exciting and satisfying trip down the Cyber Highway in you dBASE Roadster.

The CSX CyberCard application is in action at www.kuberkaartjies.com/english.htm

About the Author: Colyn Serfontein is the VdB Webmaster for the LinkAfrica Network and the owner of www.vdbase.net, www.vdbase.com and www.vdb.cswebworx.com web sites. These sites are full of handy VdBASE Information and many handy hints and tips.