【正文】 由于客戶端程序設(shè)計仍然要編程，所以無論 如何都該針對自己的特定情況采取最好的開發(fā)途徑。使用了瀏覽器后，升級就變得易如反掌，而且整個過程是透明和自動進行的。而且一旦發(fā)現(xiàn)錯誤，就可以馬上改正。需作一些跨平臺處理，以及適當(dāng)?shù)陌踩婪?，比如采用某種腳本語言或者 Java。內(nèi)聯(lián)網(wǎng)提供了比因特網(wǎng)更 高 的安全級別，因為可以物理性地控制對公司內(nèi)部服務(wù)器的使用。 6. 因特網(wǎng)和內(nèi)聯(lián)網(wǎng) Web 是解決客戶機／服務(wù)器問題的一種常用方案，所以最好能用相同的技術(shù)解決此類問題的一些 “子集 ”，特別 是公司內(nèi)部的傳統(tǒng)客戶機／服務(wù)器問題。實際上， ActiveX 的意思是 “假如你的程序同它的工作環(huán)境正常連接，它就能進入 Web 頁，并在支持ActiveX的瀏覽器中運行 ”（ IE 固化了對 ActiveX的支持，而 Netscape 需要一個插件）。如果對腳本編制語言比較熟，那么在轉(zhuǎn)向 Java 之前，建議先熟悉一下 JavaScript 或者VBScript，因為它們可能已經(jīng)能夠滿足你的需要，不必經(jīng)歷學(xué)習(xí) Java的艱苦過程。另一個因素是學(xué)習(xí)方面的問題。大家要注意另外兩個重要的問題。大多數(shù)數(shù)據(jù)校驗工作均可在客戶端完成，沒有必要坐在計算機前面焦急地等待服務(wù)器的響應(yīng)。它們能自動取得客戶軟件的最新版本，不會出錯，也沒有重新安裝的麻煩。 程序片（或 “小應(yīng)用程序 ”）是一種非常小的程序，只能在 Web 瀏覽器中運行。 4. Java 如果說一種腳本編制語言能解決 80％的客戶端程序設(shè)計問題，那么剩下的 20％又該怎么辦呢？它們屬于一些高難度的問題嗎？目前最流行的方案就是 Java。無論 NetscapeNavigator，Microsoft Inter Explorer，還是 Opera，目前都提供了對 JavaScript的支持。而且由于腳本編制語言的宗旨是盡可能地簡化與快速，所以在考慮其他更復(fù)雜的方案之前（如 Java 及 ActiveX），首先應(yīng)想一下腳本語言是否可行。另一方面，由于通常不用腳本編制語言做 過分 復(fù)雜的事情，所以這個問題暫且可以放在一邊。通過這種腳本語言，可將用于自己客戶端程序的源碼直接插入 HTML頁，而對那種語言進行解釋的插件會在 HTML頁顯示的時候自動激活。在我們構(gòu)建一個特定的站點時， 可能并不希望涉及這方面的工作。利用插件，程序員可以方便地為瀏覽器添加新功能，用戶只需下載一些代碼，把它們 “插入 ”瀏覽器的適當(dāng)位置即可。那個程序一般保存在一個名為 “cgibin”的目錄中（按下 Web頁內(nèi)的一個按鈕時，請注意一下瀏覽器頂部的地址窗，經(jīng)常都能發(fā)現(xiàn) “cgibin”的字樣）。基本 HTML 語言提供了簡單的數(shù)據(jù)收集機制：文字輸入框、復(fù)選框、單選鈕、列表以及下拉列表等，另外還有一個按鈕，只能由程序規(guī)定重新設(shè)置表單中的數(shù)據(jù)，以便回傳給服務(wù)器。 you must then back up a page and try again. Not only is this slow, it’s inelegant. The solution is clientside programming. Most machines that run Web browsers are powerful engines capable of doing vast work, and with the original static HTML approach they are sitting there, just idly waiting for the server to dish up the next page. Clientside programming means that the Web browser is harnessed to do whatever work it can, and the result for the user is a much speedier and more interactive experience at your Web site. The problem with discussions of clientside programming is that they aren’t very different from discussions of programming in general. The parameters are almost the same, but the platform is different: a Web browser is like a limited operating system. In the end, you must still program, and this accounts for the dizzying array of problems and solutions produced by clientside programming. The rest of this section provides an overview of the issues and approaches in clientside programming. One of the most significant steps forward in clientside programming is the development of the plugin. This is a way for a programmer to add new functionality to the browser by downloading a piece of code that plugs itself into the appropriate spot in the browser. It tells the browser “from now on you can perform this new activity.” (You need to download the plugin only once.) Some fast and powerful behavior is added to browsers via plugins, but writing a plugin is not a trivial task, and isn’t something you’d want to do as part of the process of building a particular site. The value of the plugin for clientside programming is that it allows an expert programmer to develop a new language and add that language to a browser without the permission of the browser manufacturer. Thus, plugins provide a “back door” that allows the creation of new clientside programming languages (although not all languages are implemented as plugins). languages Plugins resulted in an explosion of scripting languages. With a scripting language you embed the source code for your clientside program directly into the HTML page, and the plugin that interprets that language is automatically activated while the HTML page is being displayed. Scripting languages tend to be reasonably easy to understand and, because they are simply text that is part of an HTML page, they load very quickly as