1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/doc/GS/GS_bakk.tex Mon Mar 24 16:47:01 2008 +0100
1.3 @@ -0,0 +1,25 @@
1.4 +\documentclass[a4wide]{report}
1.5 +\input{preamble}
1.6 +
1.7 +\title{Communication of a Web 2.0 Browser with an Interactive Mathematics Server}
1.8 +\author{G\"unther Schr\"ottner}
1.9 +\date{$\today$}
1.10 +
1.11 +\begin{document}
1.12 +\input{titlepage}
1.13 +\tableofcontents
1.14 +\listoffigures
1.15 +
1.16 +\input{introduction}
1.17 +\input{ajax-basics}
1.18 +\input{ajax-and-isac}
1.19 +\input{summary}
1.20 +
1.21 +\bibliography{bib/isac,bib/GS}
1.22 +\end{document}
1.23 +
1.24 +
1.25 +
1.26 +
1.27 +
1.28 +
2.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
2.2 +++ b/doc/GS/ajax-and-isac.tex Mon Mar 24 16:47:01 2008 +0100
2.3 @@ -0,0 +1,196 @@
2.4 +\chapter{Ajax and \isac}
2.5 +\label{chp:ajax-and-isac}
2.6 +In this chapter I want to connect the possibilities Ajax provides with the
2.7 +requirements of \sisac. All the requirements can be fulfilled with a technique
2.8 +called ``Reverse Ajax'' which I describe in section \ref{sec:revers-ajax}.
2.9 +
2.10 +\section{Reverse Ajax}
2.11 +\label{sec:revers-ajax}
2.12 +Since there is no way for the server to start the communication with the
2.13 +web browser, the web browser is responsible for opening a connection to the
2.14 +server. But sometimes the server has information, which it would like to tell
2.15 +the web browser, but there is no connection available.
2.16 +
2.17 +The DWR toolkit \cite{dwr} provides three different techniques how to achieve
2.18 +Reverse Ajax.
2.19 +
2.20 +\subsection{Polling}
2.21 +\label{subsec:polling}
2.22 +Polling is the most intuitive solution to the problem. In periodic time
2.23 +intervals (i.g. every five seconds) the web browser sends an Ajax request to the
2.24 +server. If the server has information ready to be sent to the web browser, the
2.25 +response of the server would contain this information. If the server has no new
2.26 +information for the client, the response would be empty.
2.27 +
2.28 +The website of DWR toolkit \footnote{http://getahead.org/dwr/} has a pretty good
2.29 +metaphor which will help you understand how polling works: ``To illustrate
2.30 +imagine a 5 year old [...] in the back of the car shouting 'are we there
2.31 +yet?' every few seconds and you get the picture.'' \cite{dwr}. Figure
2.32 +\ref{fig:ajaxpolling} \cite{alexdojo} illustrates how polling works between a
2.33 +web browser and a web server.
2.34 +
2.35 +\begin{figure}[htb]
2.36 + \centering
2.37 +\includegraphics[width=0.6\textwidth,keepaspectratio=true]{myfig/ajaxpolling}
2.38 + \caption{Illustration of the Revers Ajax technique Polling}
2.39 + \label{fig:ajaxpolling}
2.40 +\end{figure}
2.41 +
2.42 +\subsection{Comet}
2.43 +\label{subsec:comet}
2.44 +This technique uses long lived HTTP connections. Once a web browser has
2.45 +established a connection with the server, the server never closes the
2.46 +connection. So it is possible for the server, to send data to the client at any
2.47 +time. Figure \ref{fig:ajaxcomet} \cite{alexdojo} illustrates how Comet works
2.48 +with a web browser
2.49 +and a web server.
2.50 +
2.51 +\begin{figure}[htb]
2.52 + \centering
2.53 +\includegraphics[width=0.6\textwidth,keepaspectratio=true]{myfig/ajaxcomet}
2.54 + \caption{Illustration of the Revers Ajax technique Comet}
2.55 + \label{fig:ajaxcomet}
2.56 +\end{figure}
2.57 +
2.58 +A drawback of this method is that it uses more resources on server side. Every
2.59 +user of the application has its own connection to the server. Maybe the web
2.60 +application uses even more than one connection, so every user has several
2.61 +connections to the web server. You can end up having a lot of connections to the
2.62 +server.
2.63 +
2.64 +\subsection{PiggyBack}
2.65 +\label{subsec:piggyback}
2.66 +PiggyBack is the last technique how to solve the Reverse Ajax problem. If
2.67 +the server has data ready to be sent to the client, it waits for the next
2.68 +incoming request. Not only the data for that request is sent back to the web
2.69 +browser, but also the data which is waiting to be sent. This makes it more
2.70 +difficult on the client to interpret the response, because there might by some
2.71 +information in it, the client did not ask for.
2.72 +
2.73 +
2.74 +\section{The hardest of \isac's requirements}
2.75 +\label{sec:hardest-isac-requiremnts}
2.76 +
2.77 +Here we cite these of \sisac's user requirements stated in \cite{isac:urd} which
2.78 +seem hardest to be accomplished by Reverse Ajax. The discussion of how to
2.79 +accomplish the requirements will follow in the subsequent section.
2.80 +
2.81 +\paragraph{UR 2.3.4} Several users may watch the progress of a calculation, but
2.82 +there is exactly one user controlling the calculation and taking actions. This
2.83 +can be useful for instruction situations, especially teleteaching.
2.84 +
2.85 +\paragraph{UR 7.2.9} There are 2 kinds of time limits: (1) given by start and
2.86 +finish, and (2) given by a duration (where start and finish are recorded with
2.87 +the user).
2.88 +
2.89 +\paragraph{UR 7.4.1} The course admin can force a user to exam-mode That in-
2.90 +cludes, that there is no way for this user, to open a session with a user-model
2.91 +which would undermine the exam-mode.
2.92 +
2.93 +\paragraph{UR 7.4.2} The course admin can force a group of users to exam-mode
2.94 +Sideconditions as in UR.7.4.1.
2.95 +
2.96 +\section{How Ajax could fulfill the requirements}
2.97 +
2.98 +\subsection{Watch asynchronous server updates}
2.99 +\label{sec:watch-asyncroneous-server-updates}
2.100 +User requirement 2.3.4 states, that a user can watch a calculation which is
2.101 +done by another user. It would rapidly get annoying for the watching user, if
2.102 +he always has to press a button to get an update on the calculation. It would
2.103 +be much more convenient, if the user could just sit in front of his monitor and
2.104 +watch the progress of the calculation.
2.105 +
2.106 +Ajax can be used to fulfill this user requirement. An Ajax request gets sent to
2.107 +the server in periodic intervals (Polling, \ref{subsec:polling}). The response
2.108 +from the server would be the progress of the calculation. The dynamic change of
2.109 +the DOM tree (see \ref{sec:the-document-object-model}) results in an updated web
2.110 +page and the user sees the progress of the calculation.
2.111 +
2.112 +Of course, this user requirement is very easy to fulfill with a HTML
2.113 +\texttt{meta} tag setting the \texttt{http-equiv} attribute to
2.114 +\texttt{Refresh}. But this has one big disadvantage: On every refresh the
2.115 +\textbf{whole} web page gets reloaded, not only a part of it. This does not
2.116 +give the user a feeling of a dynamic and responsive web page.
2.117 +
2.118 +\subsection{Stop a user session}
2.119 +\label{sec:stop-user-session}
2.120 +Timeouts are another aspect of \sisac which can be realized with Ajax. User
2.121 +requirement 7.2.9 defines, that there should be a timeout. This is necessary if
2.122 +\sisac is used to write exams.
2.123 +
2.124 +In periodic time intervals a Ajax request is sent to the server
2.125 +(Polling, \ref{subsec:polling}). The server checks, how much time is left and
2.126 +returns this as response to the web browser. If the timeout has exceeded, the
2.127 +current work of the user is submitted to the server and a timeout message is
2.128 +displayed.
2.129 +
2.130 +\subsection{Force the user into a mode of dialog}
2.131 +\label{sec:force-user-into-mode}
2.132 +The course admin can force a user, or a group of users, to change into
2.133 +exam-mode (UR 7.4.1 and UR 7.4.2). This is a typical event which does not follow
2.134 +the Request-Response communication of a web application. The event to start the
2.135 +exam-mode comes from the server and should be propagated to all clients. This is
2.136 +exactly the opposite way of communication typical for a web application.
2.137 +
2.138 +But fortunately Ajax can solve this problem too. I suggest using the Polling
2.139 +method (see \ref{subsec:polling}) here. If the course admin switches to
2.140 +exam-mode, a special state gets set on the server. The above mentioned Ajax
2.141 +request queries this state. The server returns whether we are in exam-mode or
2.142 +not. According to the answer of the server, the web page can be updated.
2.143 +
2.144 +\subsection{Events from the Mathematical Back End}
2.145 +\label{sec:events-from-back-end}
2.146 +Every time the user changes something on his current calculation, an event gets
2.147 +sent to the mathematical back end. This actions include a change of the
2.148 +calculation, pressing the ``Next'' button or the ``Auto'' button.
2.149 +
2.150 +The mathematical back end tries to interpret the event coming from the user.
2.151 +Since it is not known, how much time this will take, the front end does not
2.152 +wait for the back end to finish. If the back end is ready with its calculations,
2.153 +it sends an event to the user. In case of a web application, this means the
2.154 +server sends something to the web browser.
2.155 +
2.156 +Especially for this event, which is known as \texttt{CalcChangedEvent} in
2.157 +\sisac, I recommend using the Comet technique (see \ref{subsec:comet}). This is
2.158 +a very fast way of communicating the event to the user. As soon as the
2.159 +mathematical back end has finished its calculation, the result will be on the
2.160 +screen of the user immediately. Because the connection to the web browser is
2.161 +open for a long time, you can use this technique to model the Observer pattern
2.162 +\cite{head-first-design-patterns}.
2.163 +
2.164 +\subsection{Start, Stop and Propose a new Example}
2.165 +\label{sec:start-stop-propose-example}
2.166 +
2.167 +The course admin is able to force the user to start or stop his current
2.168 +example. He can also propose a new example to the user. These actions are
2.169 +not very time critical. So I recommend using the Polling (see
2.170 +\ref{subsec:polling}) technique again.
2.171 +
2.172 +If the user should begin a new example, the course admin sets a special state
2.173 +on the server. The polling asks for this state and if the server returns
2.174 +something, the client knows that some actions should be taken (i.g. start new
2.175 +example or stop current example). Maybe the user gets asked, if he really wants
2.176 +to start a new example. This could be part of the response from the server. So
2.177 +the course admin can force the user to start a new example or leave it up to
2.178 +the user.
2.179 +
2.180 +
2.181 +
2.182 +
2.183 +
2.184 +
2.185 +
2.186 +
2.187 +
2.188 +
2.189 +
2.190 +
2.191 +
2.192 +
2.193 +
2.194 +
2.195 +
2.196 +
2.197 +
2.198 +
2.199 +
3.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
3.2 +++ b/doc/GS/ajax-basics.tex Mon Mar 24 16:47:01 2008 +0100
3.3 @@ -0,0 +1,348 @@
3.4 +\chapter{Ajax Basics}
3.5 +\label{chp:ajax-basics}
3.6 +Ajax makes intense use of Javascript. The following sections will give a
3.7 +short overview of how Ajax uses Javascript to send requests to the server and
3.8 +receive the response in return.
3.9 +
3.10 +\section{XMLHttpRequest - The Core of Ajax}
3.11 +\label{sec:xmlhttprequest-core}
3.12 +Still many web applications use only the old-fashioned Request-Response
3.13 +communication (see \ref{sec:request-response}). User of web
3.14 +applications have to press a button or click on a link to make some action take
3.15 +place. To make a web application look more dynamic and responsive, the
3.16 +application itself has to send the request to the server, without having the
3.17 +user explicitly pressing a button. When such requests are sent to the server,
3.18 +depends on the application. It is possible to send a request to the server on
3.19 +every keypress of the user (although this is not recommended because the server
3.20 +will not be able to handle all incoming requests and eventually break down).
3.21 +
3.22 +The solution to send requests to the server in the background is Javascript
3.23 +(see \ref{sec:evolution-web-app}). Javascript provides an object called
3.24 +``\texttt{XMLHttpRequest}''\footnote{The name of this object is misleading. It
3.25 +is absolutely not necessary to send XML to the server or receive XML from the
3.26 +server.} which is able to send a request to the server and receive the response
3.27 +from the server. Depending on the response some actions could be taken to
3.28 +manipulate the user interface in the web browser. The user in front of the web
3.29 +application did not send a request to the server, but the interface of the
3.30 +application changes. This gives the user the feeling of a dynamic application.
3.31 +
3.32 +A typical web application comprises of the components, shown in
3.33 +figure \ref{fig:xmlhttprequest} \cite{ajax-in-action}.
3.34 +
3.35 +\begin{figure}[htb]
3.36 + \centering
3.37 +\includegraphics[width=0.8\textwidth,keepaspectratio=true]{myfig/xmlhttprequest}
3.38 + \caption{Parts of a web application: CSS, DOM and Javascript with
3.39 + XMLHttpRequest}
3.40 + \label{fig:xmlhttprequest}
3.41 +\end{figure}
3.42 +
3.43 +
3.44 +\subsection{Creating a XMLHttpRequest}
3.45 +\label{sec:xmlhttprequest-create}
3.46 +
3.47 +Creating a \texttt{XMLHttpRequest} object is not as straightforward as one might
3.48 +think. Due to many different web browser and therefore many different
3.49 +implementations of Javascript, the creation process of a \texttt{XMLHttpRequest}
3.50 +object differs from browser to browser.
3.51 +
3.52 +\lstset{language=Java}
3.53 +\begin{lstlisting} [caption=Creation of an XMLHttpRequest object in Javascript
3.54 +, label=lst:create-xmlhttprequest]
3.55 +var request = null;
3.56 +function createRequest() {
3.57 + try {
3.58 + request = new XMLHttpRequest();
3.59 + } catch(trymicrosoft) {
3.60 + try {
3.61 + request = new ActiveXObject("Msxml2.XMLHTTP");
3.62 + } catch(othermicrosoft) {
3.63 + try {
3.64 + request = new ActiveXObject("Microsoft.XMLHTTP");
3.65 + } catch(failed) {
3.66 + request = null;
3.67 + }
3.68 + }
3.69 + }
3.70 + if (request == null)
3.71 + alert("Error creating request object!");
3.72 +}
3.73 +\end{lstlisting}
3.74 +
3.75 +Listing \ref{lst:create-xmlhttprequest} \cite{head-rush-ajax} shows how a
3.76 +\texttt{XMLHttpRequest} is created. There are many web browser available, hence
3.77 +there are different methods of creating the \texttt{XMLHttpRequest}. In line 4
3.78 +the first attempt to create a \texttt{XMLHttpRequest} is made. This should work
3.79 +on Mozilla/Safari based web browsers. If this fails, the next method of creating
3.80 +a \texttt{XMLHttpRequest} is applied (line 7). This can also fail and the last
3.81 +method is called (line 10). Line 7 and line 10 only get called, if the user
3.82 +works with Internet Explorer. If there is still no valid \texttt{XMLHttpRequest}
3.83 +object, it is not possible to create one on the current browser and a error
3.84 +messages is displayed (line 17).
3.85 +
3.86 +\subsection{Sending an XMLHttpRequest to the Server}
3.87 +\label{subsec:sending-xmlhttprequest}
3.88 +After the function in listing \ref{lst:create-xmlhttprequest} gets called, there
3.89 +is a variable with the name \texttt{request} available which
3.90 +represents the \texttt{XMLHttpRequest}. The only thing missing, in order to
3.91 +send the request, is the location to which the request should be sent. This
3.92 +could be almost anything on the server: A simple CGI script or a more
3.93 +sophisticated Java Servlet or PHP page.
3.94 +
3.95 +The next listing creates a method, which will get called when the user clicks a
3.96 +button.
3.97 +
3.98 +\lstset{language=Java}
3.99 +\begin{lstlisting} [caption=Method for sending the XMLHttpRequest to the server
3.100 +\cite{head-rush-ajax}, label=lst:create-sendmethod]
3.101 +function getBoardsSold() {
3.102 + createRequest();
3.103 + var url = "getUpdatedBoardSales-ajax.php"
3.104 + request.open("GET", url, true);
3.105 + request.send(null);
3.106 +}
3.107 +\end{lstlisting}
3.108 +
3.109 +The first thing to mention is, that the method \texttt{createRequest()} from
3.110 +listing \ref{lst:create-xmlhttprequest} is called in order to create the
3.111 +\texttt{XMLHttpRequest} object (line 2). The next step is to set the target of
3.112 +the request which is a PHP script in this case. The call to the \texttt{open()}
3.113 +method of the \texttt{XMLHttpRequest} object initializes the connection to the
3.114 +server. The third parameter of the \texttt{open()} method with the value
3.115 +\texttt{true} indicates, that this request should be asynchronous. The
3.116 +\texttt{send()} method of the \texttt{XMLHttpRequest} object sends the request
3.117 +to the server. Since there is no data to send to the server, the parameter of
3.118 +this method is \texttt{null}.
3.119 +
3.120 +\subsection{Receiving data from the server}
3.121 +\label{subsec:receiving-data-from-server}
3.122 +After calling the \texttt{send()} method, the communication between the web
3.123 +browser and server is established. Now the server tries to fulfill the request
3.124 +and maybe sends a response back to the client. The server expects to call a
3.125 +Javascript function when there is data to send back to the client (this is
3.126 +called a ``call-back function''). Listing \ref{lst:create-sendmethod} does not
3.127 +tell the server which method to call back. The following listing sets the
3.128 +call-back function:
3.129 +
3.130 +\lstset{language=Java}
3.131 +\begin{lstlisting} [caption=Method for sending the XMLHttpRequest to the server
3.132 +with call-back method
3.133 +\cite{head-rush-ajax}, label=lst:create-sendmethodcallback]
3.134 +function getBoardsSold() {
3.135 + createRequest();
3.136 + var url = "getUpdatedBoardSales-ajax.php"
3.137 + request.open("GET", url, true);
3.138 + request.onreadystatechange = updatePage();
3.139 + request.send(null);
3.140 +}
3.141 +\end{lstlisting}
3.142 +
3.143 +In listing \ref{lst:create-sendmethodcallback} the function
3.144 +\texttt{updatePage()} (line 5) is called if the server has data to be sent back
3.145 +to the web browser. It is important to declare the call-back function before the
3.146 +\texttt{send()} method gets called. Now the server has the information to call
3.147 +the method \texttt{updatePage()}. The method \texttt{updatePage()} is
3.148 +responsible to interpret the result from the server and update the web page
3.149 +accordingly. The next listing shows the implementation of the
3.150 +\texttt{updatePage} method.
3.151 +\lstset{language=Java}
3.152 +\begin{lstlisting} [caption=The call-back method \texttt{updatePage}
3.153 +\cite{head-rush-ajax}, label=lst:update-page]
3.154 +function updatePage() {
3.155 + if (request.readyState == 4) {
3.156 + var newTotal = request.responseText;
3.157 + // Update the page using the value in newTotal
3.158 + }
3.159 +}
3.160 +\end{lstlisting}
3.161 +
3.162 +Line 2 in listing \ref{lst:update-page} queries the \texttt{readySate} of the
3.163 +request. Every time something happens with the request on the server, the
3.164 +server calls the \texttt{updatePage()} method. The only useful information can
3.165 +be obtained, after the request has completed which is indicated by the
3.166 +\texttt{readyState} 4. Other valid values for the \texttt{readyState} are
3.167 +\cite{ajax-in-action}:
3.168 +
3.169 +\begin{itemize}
3.170 + \item 0: Uninitialized
3.171 + \item 1: Loading
3.172 + \item 2: Loaded
3.173 + \item 3: Interactive
3.174 + \item 4: Complete
3.175 +\end{itemize}
3.176 +
3.177 +The data which was sent back to the web browser is stored in the
3.178 +\texttt{responseText} member of the \texttt{XMLHttpRequest}. After reading this
3.179 +value, the page can be updated dynamically. This happens, by changing the DOM
3.180 +tree of the application.
3.181 +
3.182 +\section{The Document Object Model (DOM)}
3.183 +\label{sec:the-document-object-model}
3.184 +The web browser has an internal representation of the web site which is
3.185 +called DOM tree \cite{dom}. With Javascript it is possible to change the DOM
3.186 +tree which in turn changes the web page. There is no need for reloading the
3.187 +whole web page. Every modification made on the DOM tree is immediately reflected
3.188 +in the web page.
3.189 +
3.190 +Figure \ref{fig:domtree} shows the representation of a web page as DOM tree.
3.191 +Mozilla Firefox comes with a tool called ``DOM Inspector'' which is available
3.192 +under the ``Tools'' menu. The DOM Inspector shows you the DOM tree of the
3.193 +current web page in the browser.
3.194 +\begin{figure}[htb]
3.195 + \centering
3.196 +\includegraphics[width=0.5\textwidth,keepaspectratio=true]{myfig/domtree}
3.197 + \caption{A representation of a web page as DOM tree}
3.198 + \label{fig:domtree}
3.199 +\end{figure}
3.200 +
3.201 +You can see how a web page is constructed. It starts with the root node
3.202 +``document'' followed by the node \texttt{HTML}. Then there is a \texttt{HEAD}
3.203 +and a \texttt{BODY}. Inside the \texttt{BODY} you find a \texttt{TABLE}, with
3.204 +\texttt{TR}s and \texttt{TD}s. Inside the column is a label and an
3.205 +\texttt{INPUT} field. With Javascript it is possible, to delete one of these
3.206 +nodes, change the value of one node or even add a new node.
3.207 +
3.208 +\subsection{Different types of DOM tree nodes}
3.209 +\label{subsec:dom-node-types}
3.210 +Inside the DOM tree there are two different types of nodes. A node could either
3.211 +be a ``element node'' or a ``text node''. If you deal with a ``element node''
3.212 +you can query the name by accessing the \texttt{nodeName} property of the node.
3.213 +On the other hand, if you are looking at a ``text node'' the property
3.214 +\texttt{nodeValue} is used to retrieve the text of this node
3.215 +\cite{head-rush-ajax}. Listing \ref{lst:node-types} shows an example.
3.216 +
3.217 +\lstset{language=HTML}
3.218 +\begin{lstlisting} [caption=Different node types inside the DOM tree,
3.219 +label=lst:node-types]
3.220 +...
3.221 +<div id="name">
3.222 + <b>Günther Schröttner</b>
3.223 +</div>
3.224 +...
3.225 +\end{lstlisting}
3.226 +In listing \ref{lst:node-types} the HTML tags \texttt{DIV} and \texttt{B} would
3.227 +be represented as nodes of type ``element node''. The return value of the
3.228 +property \texttt{nodeName} would by ``DIV'' or ``B'', respectively. The
3.229 +\texttt{B} tag has one child node of type ``text node''. The property
3.230 +\texttt{nodeValue} would return ``G\ünther Schr\öttner''.
3.231 +
3.232 +\subsection{Retrieving a node from the DOM tree}
3.233 +\label{subsec:retrieving-node-from-dom}
3.234 +Javascript provides very handy methods for querying the DOM tree for nodes.
3.235 +All important HTML tags support the attribute \texttt{id}
3.236 +\cite{html-specification}. This \texttt{id} should be unique inside the web
3.237 +page. Listing \ref{lst:input-definition} defines a \texttt{INPUT} field on a web
3.238 +page.
3.239 +
3.240 +\lstset{language=HTML}
3.241 +\begin{lstlisting} [caption=A text box with the \texttt{id} attribute defined,
3.242 +label=lst:input-definition]
3.243 +<html>
3.244 + <head>
3.245 + <title>Sample INPUT</title>
3.246 + </head>
3.247 + <body>
3.248 + <form>
3.249 + <input id="price" type="text" name="price" value="99,90" />
3.250 + </form>
3.251 + </body>
3.252 +</html>
3.253 +\end{lstlisting}
3.254 +
3.255 +The \texttt{INPUT} tag has the attribute \texttt{id} set to the value
3.256 +``price''. With the Javascript function \texttt{getElementById()} it is
3.257 +possible, to get the node out of the DOM tree which represents this
3.258 +\texttt{INPUT} field.
3.259 +
3.260 +\lstset{language=Java}
3.261 +\begin{lstlisting} [caption=Getting a node from the DOM tree,
3.262 +label=lst:input-query]
3.263 +function getInput() {
3.264 + var priceInput = document.getElementById("price");
3.265 + // Do something with priceInput (i.g. change the value)
3.266 +}
3.267 +\end{lstlisting}
3.268 +
3.269 +In listing \ref{lst:input-query} the implicit Javascript object
3.270 +\texttt{document} is used to query the DOM tree. The method
3.271 +\texttt{getElementById()} \cite{selfhtml} expects the value of an \texttt{id}.
3.272 +The whole DOM tree is searched for the given \texttt{id}. This is the reason why
3.273 +it is good practice to make sure, each \texttt{id} is unique within the web
3.274 +page.
3.275 +
3.276 +\subsection{Changing the value of a DOM tree node}
3.277 +\label{subsec:changing-value-of-dom-node}
3.278 +As described in chapter \ref{subsec:dom-node-types} there are two types of
3.279 +nodes inside the DOM tree. Changing the value of a ``text node'' is quite
3.280 +simple. A ``text node'' has a property with the name \texttt{nodeValue}. By
3.281 +assigning the desired text to this property, the value of this node changes.
3.282 +
3.283 +\lstset{language=HTML}
3.284 +\begin{lstlisting} [caption=Change the value of a text node,
3.285 +label=lst:change-text-node-value]
3.286 +<html>
3.287 + <head>
3.288 + <title>Change the value of a text node in the dom tree</title>
3.289 + <script>
3.290 + function changeText() {
3.291 + var div = document.getElementById("div");
3.292 + var textInsideDiv = div.childNodes[0];
3.293 + textInsideDiv.nodeValue = "You have changed the text!";
3.294 + }
3.295 + </script>
3.296 + </head>
3.297 + <body>
3.298 + <div id="div">
3.299 + This text should change.
3.300 + </div>
3.301 + <div id="button">
3.302 + <input type="button" name="button" value="Change text"
3.303 + onclick="changeText()" />
3.304 + </div>
3.305 + </body>
3.306 +</html>
3.307 +\end{lstlisting}
3.308 +
3.309 +When the button is clicked on this web page, the Javascript function
3.310 +\texttt{changeText()} is called. This function looks up the \texttt{DIV} tag by
3.311 +its \texttt{id} (line 6). The actual text to change is the child node of this
3.312 +\texttt{DIV} tag (line 7). The text is changed by simple assigning the new value
3.313 +to the \texttt{nodeValue} attribute (line 8).\newline
3.314 +
3.315 +Some HTML components, which are not represented as text nodes (like textareas or
3.316 +text boxes), have special attributes which allows one to change the value too.
3.317 +Listing \ref{lst:change-element-node-value} shows how the value of a text box
3.318 +changes by clicking on a button.
3.319 +
3.320 +\lstset{language=HTML}
3.321 +\begin{lstlisting} [caption=Change the value of a text box,
3.322 +label=lst:change-element-node-value]
3.323 +<html>
3.324 + <head>
3.325 + <title>Change the value of a text node in the dom tree</title>
3.326 + <script>
3.327 + function changeText() {
3.328 + var textBox = document.getElementById("textbox");
3.329 + textBox.value = "You just clicked the button!";
3.330 + }
3.331 + </script>
3.332 + </head>
3.333 + <body>
3.334 + <div id="div">
3.335 + <input id="textbox" name="textbox" value="" size="30" />
3.336 + </div>
3.337 + <div id="button">
3.338 + <input type="button" name="button" value="Change text"
3.339 + onclick="changeText()" />
3.340 + </div>
3.341 + </body>
3.342 +</html>
3.343 +\end{lstlisting}
3.344 +
3.345 +The example in listing \ref{lst:change-element-node-value} shows, how the value
3.346 +of a text box changes by the click on a button.
3.347 +
3.348 +
3.349 +
3.350 +
3.351 +
4.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
4.2 +++ b/doc/GS/introduction.tex Mon Mar 24 16:47:01 2008 +0100
4.3 @@ -0,0 +1,71 @@
4.4 +\chapter{Introduction}
4.5 +\label{chp:introduction}
4.6 +
4.7 +\section{Web Applications vs. Desktop Applications}
4.8 +\label{sec:web-app-vs-desktop-app}
4.9 +``Ideally, a user interface (UI) will be invisible to users, providing them with
4.10 +the options they need when they need them but otherwise staying out of their
4.11 +way, leaving users free to focus on the problem at hand.''
4.12 +(\cite{ajax-in-action}) Especially for web applications this is more important
4.13 +than one would notice in the first place. Users are used to work with rich
4.14 +desktop applications which provide a very good look and feel interface. They
4.15 +have a lot of convenient widgets, i.g.
4.16 +
4.17 +\begin{itemize}
4.18 + \item The right mouse button which provides a context sensitive menu
4.19 + \item Drag and Drop which lets the user move things around
4.20 + \item Modal windows which force the user to enter something or answer a
4.21 +question before he can continue his work
4.22 + \item Trees, Tabs, Tables and lot of other things which make the
4.23 +representation of data meaningful and easy to understand for the user
4.24 + \item Toolbars, menubars and shortcuts which makes it easy for the user to
4.25 +navigate through the different aspects of the application.
4.26 +\end{itemize}
4.27 +
4.28 +But when it comes to web applications, all these things are not available out
4.29 +of the box. I am not saying that it is impossible to do these things, but the
4.30 +effort is much higher than it is in normal desktop applications.
4.31 +
4.32 +\section{Evolution of Web Applications}
4.33 +\label{sec:evolution-web-app}
4.34 +The front end of a web applications is displayed within a web browser. One of
4.35 +the main tasks of a web browser is to render HTML code so the user can see the
4.36 +application. HTML exists for 18 years now \cite{history-html}. In the early
4.37 +days, there were only simple input types defined like text boxes, checkboxes,
4.38 +select boxes or radio buttons. Nowadays it is very hard to create a web
4.39 +application which is accepted by the users with only these few
4.40 +components.
4.41 +
4.42 +Web browsers evolved over the years an learned %WN070704 learned ?
4.43 +many new things. Javascript is one
4.44 +of these new things which was introduced by Netscape in the year 1996
4.45 +\cite{history-javascript}. Javascript is a client side programming language,
4.46 +which brings a little more dynamic into the web page. In fact, Javascript is
4.47 +the technology which we will use to create rich web applications.
4.48 +
4.49 +\section{The typical Request-Response Communication}
4.50 +\label{sec:request-response}
4.51 +One huge disadvantage of web application is the synchronous communication with
4.52 +the web server. The user of the web application has to send a request
4.53 +to the server. The server tries to interpret the {\textbf request} and sends an
4.54 +appropriate {\textbf response} back to the client. This response could either be
4.55 +the answer for the request, or in case the server was not able to fulfill the
4.56 +request, a simple error message.
4.57 +
4.58 +The HTTP protocol \cite{rfc2616} is a stateless protocol. This means after
4.59 +the server sent the response back to the client, the connection is terminated.
4.60 +So the server can never be proactive and send some data to the client. It
4.61 +always has to be the client, which initiates the communication with the server.
4.62 +
4.63 +\section{Ajax - the All-Rounder?}
4.64 +\label{sec:ajax-all-rounder}
4.65 +Ajax stands for Asynchronous Javascript + XML. Ajax is still based on the HTTP
4.66 +protocol which in turn is a stateless protocol. Anyway, Ajax manages it to
4.67 +simulate asynchronous web applications. This allows a web application to be
4.68 +felt more dynamically and has therefore a bigger acceptance by users who work
4.69 +with the application.
4.70 +
4.71 +Javascript is not only used to create requests to the server, but also to
4.72 +manipulate the DOM tree \cite{dom} of the HTML page. This is what it makes look
4.73 +a web application interactive, dynamic and more responsive.
4.74 +