Client Side Scripting Language

Client-side scripting generally refers to the class of computer programs on the web that are executed client-side, by the user's web browser, instead of server-side (on the web server). This type of computer programming is an important part of the Dynamic HTML (DHTML) concept, enabling web pages to be scripted; that is, to have different and changing content depending on user input, environmental conditions (such as the time of day), or other variables.

Client-side scripts are often embedded within an HTML or XHTML document (known as an "embedded script"), but they may also be contained in a separate file, which is referenced by the document/s that use it (known as an "external script"). Upon request, the necessary files are sent to the user's computer by the web server (or servers) on which they reside. The user's web browser executes the script, then displays the document, including any visible output from the script. Client-side scripts may also contain instructions for the browser to follow in response to certain user actions, (e.g., clicking a mouse button). Often, these instructions can be followed without further communication with the server.

By viewing the file that contains the script, users may be able to see its source code. Many web authors learn how to write client-side scripts partly by examining the source code for other authors' scripts.

In contrast, server-side scripts, written in languages such as Perl, PHP, ASP.NET, Java, and server-side VBScript, are executed by the web server when the user requests a document. They produce output in a format understandable by web browsers (usually HTML), which is then sent to the user's computer. The user cannot see the script's source code (unless the author publishes the code separately), and may not even be aware that a script was executed. Documents produced by server-side scripts may, in turn, contain client-side scripts.

Client-side scripts have greater access to the information and functions available on the user's browser, whereas server-side scripts have greater access to the information and functions available on the server. Server-side scripts require that their language's interpreter be installed on the server, and produce the same output regardless of the client's browser, operating system, or other system details. Client-side scripts do not require additional software on the server (making them popular with authors who lack administrative access to their servers); however, they do require that the user's web browser understands the scripting language in which they are written. It is therefore impractical for an author to write scripts in a language that is not supported by popular web browsers.

Due to security restrictions, client-side scripts may not be allowed to access the user's computer beyond the web browser application. Techniques like ActiveX controls can be used to sidestep this restriction.

Client-side scripting is not inherently unsafe. Users are encouraged to always keep their web browsers up-to-date to avoid exposing their computer and data to vulnerabilities that are discovered.

The latest group of web browsers and web pages tend to employ a heavy amount of client-side scripting, accounting for an improved user interface in which the user does not experience the unfriendly "refreshing" of the web page, but instead sees perhaps an animated GIF file indicating that the request occurred and the page will be updated shortly. Ajax is an important addition to the JavaScript language, allowing web developers to communicate with the web server in the background without requiring a completely new version of the page to requested and rendered. This leads to a much improved user experience in general.

Unfortunately, even languages that are supported by a wide variety of browsers may not be implemented in precisely the same way across all browsers and operating systems. Authors are well-advised to review the behavior of their client-side scripts on a variety of platforms before they put them into use.

Server-Side Scripting Language - PHP

Server-side scripting is invisible to the user. Pity the poor server-side scripters, toiling away in utter obscurity, trapped in the no-man’s land between the web server and the database while their arty brethren brazenly flash their wares before the public gaze.

Server-side web scripting is mostly about connecting web sites to backend servers, processing data and controlling the behavior of higher layers such as HTML and CSS. This enables the following types of two-way communication:

• Server to client: Web pages can be assembled from backend-server output.
• Client to server: Customer-entered information can be acted upon.

Server-side scripting products consist of two main parts: the scripting language and the scripting engine (which may or may not be built into the web server). The engine parses and interprets pages written in the language.

Common examples of client-to-server interaction are online forms with some drop-down lists (usually the ones that require you to click a button) that the script assembles dynamically on the server.

Advantages of PHP, Apache, Mysql

Cross-platform compatibility

PHP and MySQL run native on every popular flavor of Linux/Unix ( Mac OS X) and Microsoft Windows. Most of the world’s Hypertext Transfer Protocol (HTTP) servers run on one of these two classes of operating systems.

PHP is compatible with the leading web servers: Apache HTTP Server for Linux/Unix and Windows
and Microsoft IIS Server (Internet Information Server). It also works with several simple, known servers.

Stability

The word stable means two different things in this context:

• The server doesn’t need to be rebooted or restarted often.
• The software doesn’t change radically and incompatibly from release to release.

To our advantage, both of these points apply to both MySQL and PHP.

Apache Server is generally considered the most stable of major web servers, with a reputation for enviable uptime percentages. Most often, a server reboot isn’t required for each setting change. PHP inherits this reliability; plus, its own implementation is solid yet lightweight.

PHP and MySQL are also both stable in the sense of feature stability. Their respective development teams are enjoyed a clear vision of their projects and user demand that comes along. Much of the effort goes into incremental performance improvements, communicating with more major databases, or adding better OOP support. In the case of MySQL, the addition of reasonable and expected new features has hit a rapid clip. For both PHP and MySQL, such improvements have rarely come at the expense of compatibility.

Many extensions

PHP makes it easy to communicate with other programs and protocols. The PHP development team
seems committed to providing maximum flexibility to the largest number of users. Database connectivity is especially strong, with native-driver support for about 15 of the most popular databases plus Open DataBase Connectivity (ODBC). In addition, PHP supports a large number of major protocols such as POP3, IMAP, and LDAP. Earlier versions of PHP added support for Java and distributed object architectures (Component Object Model [COM] and Common Object Request Broker Architecture [CORBA]), making n-tier development a possibility for the first time, fully incorporated GD graphics library and revamped Extensible Markup Language (XML) support with DOM and simpleXML.

Fast feature development

Users of proprietary web development technologies can sometimes be frustrated by the glacial speed at which new features are added to the official product standard to support emerging technologies. With PHP, this is not a problem. All it takes is one developer, a C compiler, and a dream to add important new functionality. This is not to say that the PHP team will accept every random contribution into the official distribution without community buy-in, but independent developers can and do distribute their own extensions that may later be folded into the main PHP package in more or less unitary form. For instance, Dan Libby’s elegant xmlrpc-epi extension was adopted as part of the PHP distribution in version 4.1, a few months after it was first released as an independent package.

PHP development is also constant and ongoing. Although there are clearly major inflection points, such as the transition between PHP4 and PHP5, these tend to be most important deep in the guts of the parser — people were actually working on major extensions throughout the transition period without critical problems. Furthermore, the PHP group subscribes to the open source philosophy of “release early, release often,” which gives developers many opportunities to follow along with changes and report bugs.

Not proprietary

The history of the personal computer industry to date has largely been a chronicle of proprietary standards: attempts to establish them, clashes between them, their benefits and drawbacks for the consumer, and how they are eventually replaced with new standards. In the past few years the Internet has demonstrated the great convenience of voluntary, standardsbased, platform-independent compatibility. E-mail, for example, works so well because it enjoys a clear, firm standard to which every program on every platform must conform. New developments that break with the standard (for example, HTML-based e-mail stationery) are generally regarded as deviations, and their users find themselves having to bear the burdens of early adoption. Furthermore, customers (especially the big-fish businesses with large systems) are fed up with spending vast sums to conform to a proprietary standard only to have the market uptake not turn out as promised. Much of the current momentum toward XML and web services is driven by years of customer disappointment with Java RMI (Remote Method Invocation), CORBA, COM, and even older proprietary methods and data formats. Right now, software developers are in a period of experimentation and flux concerning proprietary versus open standards. Companies want to be sure that they can maintain profitability while adopting open standards. There have been some major legal conflicts related to proprietary standards, which are still being resolved. These could eventually result in mandated changes to the codebase itself or even affect the futures of the companies involved. In the face of all this uncertainty, a growing number of businesses are attracted to solutions that they know will not have these problems in the foreseeable future. PHP is in a position of maximum flexibility because it is, so to speak, antiproprietary. It is not tied to any one server operating system, unlike Active Server Pages. It is not tied to any proprietary cross-platform standard or middleware, as is Java Server Pages or ColdFusion. It is not tied to any one browser or implementation of a programming language or database. PHP isn’t even doctrinaire about working only with other open source software. This independent but cooperative pragmatism should help PHP ride out the stormy seas that seem to lie ahead. Strong user communities PHP is developed and supported in a collaborative fashion by a worldwide community of users.

Some core developers are more equal than others, but that’s hard to argue with, because they put in the most work, had the best ideas, and have managed to maintain civil relationships with the greatest number of other users. The main advantage for most new users is technical support without charge, without boundaries, and without the runaround. People on the mailing list are available 24/7/52 to answer your questions, help debug your code, and listen to your gripes. The support is human and real. PHP community members might tell you to read the manual, take your question over to the appropriate database mailing list, or just stop your whining — but they’ll never tell you to wipe your C drive and then
charge you for the privilege. Often, they’ll look at your code and tell you what you’re doing wrong or even help you design an application from the ground up.

As you become more comfortable with PHP, you may wish to contribute. Bug tracking, offering
advice to others on the mailing lists, posting scripts to public repositories, editing documentation, and, of course, writing C code are all ways you can give back to the community. MySQL, while open source licensed for non-redistributive uses, is somewhat less community driven in terms of its development. Nevertheless, it benefits from a growing community of users who are actively listened to by the development team. Rarely has a software project responded so vigorously to community demand, and the community of users can be extremely responsive to other users who need help. It’s a point of pride with a lot of SQL gurus that they can write the complicated queries that get you the results you are looking for but had struggled with for days. In many cases, they’ll help you for nothing more than the enduring, if small, fame that comes with the archived presence of their name on Google Groups.

Embedding PHP into the HTML

PHP can write with HTML combination. We can integrate PHP within HTML.

When a user requests this page, the web server preprocesses it, the page process from top to bottom, looking for sections of PHP, the php code will try to resolve, and finally the page provides the result as HTML format.

HTML and PHP Example:



When a user requests this page, the web server preprocesses it, the page process from top to bottom, looking for sections of PHP, the php code will try to resolve, and finally the page provides the result as HTML format.

Here is the "Browser" HTML Code::


This code is exactly the same as if you were to write the HTML by hand!

The HTML-embeddedness of PHP has many helpful to add dynamical code.

• PHP can quickly be added to code produced by WYSIWYG editors.
• Every line of HTML does not need to be rewritten in a programming language.
• PHP can reduce man power costs and increase efficiency, because of its easy learning curve and ease of use.