Transcript Chapter 1 Web Application Technologies

Web Application Technologies
Chapter 1
Chapter 1 Web Application
Technologies
• "I am interested in becoming a web
developer, but I don't know where to
begin. There seems to be so many
technologies in the field of web
development that I feel lost. How do all
these technologies relate to each other,
which ones do I need to learn in order to
be considered a serious professional,
and which one should I learn first?"
Of Lego Blocks and Puzzle Pieces
• "It seems to me that my job as a
webmaster has continually been about
fitting together a zillion little puzzle
pieces. This piece talks to that piece
and that piece talks to this piece. It is
easy to get overwhelmed."
NOT puzzle pieces
• Web application development technologies
are definitely NOT puzzle pieces.
• In web application development however,
there is no right way to solve a problem and
no truly unique technology. Rather, there are
multiple possible configurations of essentially
redundant tools, each which solves the same
set of problems.
Example
• CGI, ASP and Servlets all serve the
same basic function. They perform
server-side processing. Similarly
CORBA, DCOM and enterprise Java
Beans specify how to talk to distributed
objects. Likewise XML, HTML, SGML,
XSL and CSS are all similar tools for
marshaling and displaying data across a
network.
Legos
• web technologies within the same categories,
can be used interchangeably in MOST
situations.
• I like to think of web application development
in terms of legos. With legos, there is no
overarching "right" way to solve a problem.
There are just a whole bunch of block
categories (6 hole, 4 hole, 2 hole) which can
be put together in an infinite number of ways.
Categories
• Rather than understanding each
technology on its own, you need only
understand the categories into which
individual technologies fall. Once you
understand where a technology fits into
the scheme of a web application, you
already understand 60% of that
technology.
Web Application
•
all web applications do pretty much
the same things:
1.
2.
3.
4.
5.
Provide a Query Interface
Transmit User-Defined Query
Perform Server Side Processing
Massage Data
Transmit Query Results
6. Perform Client Side Processing
Consider the following generic web application workflow diagram.
Role of GUI
• In its role as translator, the GUI is responsible for two
things.
• First, the GUI must translate the desires, intentions,
needs, and wants of people into executable, logical
machine instructions. At the same time, the GUI must
also translate computer-generated data into
meaningful human-readable information.
• This translation, as you might imagine, is no mean
feat. In fact, in creating web applications, web
developers will spend just as much time building a
solid front end as they will spend developing a
dependable backend.
UI Widgets or Controls
• As a web application developer, when
concerning yourself with the GUI Layer, you
will most likely be concerned primarily with
the use and manipulation of "UI Widgets" or
"controls".
• Widgets are interface tools that clients can
use to make their intentions, desires, and
wants known to the program.
• Widgets could include buttons, scroll bars,
grids, or even click able images. Widgets
should be almost intuitive to you as this is the
bit of software we humans most often work
with.
Understanding the Web Browser
• a web browser is a software program that knows how
to contact a web server (using the HTTP protocol),
request a given document from that web server, and
display that document returned by the server to a
human user.
• Because the communication between the browser
and server is better discussed as a function of the
communication layer, we'll discuss it in the next
section. For now, we concern ourselves mainly with
the document display that is more classically a GUI
Layer issue.
HTML
• Typically, the document that is returned from the web
server is formatted (according to some formatting
instructions) by the browser so that when it is
displayed, the document will look pretty (rather than
just being displayed as plain text) or have some
special functionality. All readers will certainly be
familiar with HTML, the most ubiquitous webformatting languages around today.
• Most web browsers know how to take HTMLencoded text and display it according to the HTML
formatting instructions. Thus, a web browser will take
<CENTER><B>Hello Cyberspace</B></CENTER>
and turn it into
Hello Cyberspace
A Short History of Web Browsers
• In terms of the use of a web browser by
the mass public, the history of web
browsers begins with LYNX.
• LYNX is a simple text-based web
browser primarily accessed via UNIX
shell accounts that displays formatted
HTML text (but not images). A sample of
what you might see in a LYNX browser
is seen below:
• In fact, soon after the development of LYNX, as the
concept of web browsing took off, web browsers
would quickly evolve into the graphical web browser
species beginning with Mosaic, Mozilla, and finally
browsers such as Navigator and Explorer (there are
dozens of other browsers of course, we just name the
biggies
• These browsers offered a truly user-friendly graphical
interface that turned bland library-like document
archives into an exciting electronic frontier.
• Consider the same page as above, viewed in
Netscape and Internet Explorer!
Basic User Interactivity with HTML
Forms
• However, besides displaying HTML-formatted
text to users, web browsers also provide a
means to solicit data from users and send
that data to web servers. They do so by using
HTML forms.
• The ability to create forms is really the
beginning of a true, traditional web
application. HTML forms allow web
application developers to design standard
input forms with widgets such as drop downs,
text boxes and buttons. Users can enter in
data dynamically using these widgets
• Behind the scenes, once the user enters in
their data and hits a submit button, the web
browser will collate the user defined values
for the form widgets and submit them to the
web server using the POST or GET methods
of the HTTP protocol. Again, we will discuss
the HTTP communication layer aspects in the
next section.
• What you should do at this point is get
comfortable with the idea that HTML provides
the syntax for defining forms and that
browsers will help you process those forms
• NOTE: Besides dealing with HTML form
widgets, web browsers also help you
maintain application state. they do so by
providing an interface for " cookies".
• HTTP is a stateless protocol, most web
applications will need help
"remembering" what has happened so
far in their workflow.
• Consider the example of a web store that might need
to keep track of all the items a client has added to a
virtual shopping cart. The web store application must
keep track of the shopping cart items wherever the
user goes on the website, or even whether or not the
user leaves the website and returns later!
• To help solve this problem of state maintenance,
browsers keep a log of all the application activity
locally in a "cookie" (an invisible widget of sorts).
Applications can access the contents of the cookie so
that they can maintain the state
QUESTION :
When did we start seeing web-forms
that captured credit-card details, and
passed them to CGI-scripts, thereby
enabling interaction with server-side
applications, in particular interfacing
with the EFT/POS network?
The elements that were necessary to support
eCommerce of this kind are:
•a version of HTML that supports forms;
•a browser that implements a version of HTML
that supports forms;
•the HTTP POST method, to enable transmission
of the data that is keyed into a web-form;
•a server that implements the HTTP POST
method, and supports CGI scripts; and
•an application that interfaces to the EFT/POS
system to get credit authorizations and capture
transactions into the financial system.