AJAX features

AJAX is a mixture of several popular technologies put together to build the next generation of web applications, which are more responsive, more interactive and behave like their desktop counterparts. MX AJAX Toolbox brings the benefits of AJAX to Dreamweaver.
Asynchronous loading of content without page refresh
With MX AJAX Toolbox, an AJAX site has one or more master pages. The building blocks of any master page are the AJAX panels – regions of content that users can place anywhere in their site and that change their state independently from the rest of the page. Each AJAX panel has one or more states – the actual files included in the website when an AJAX request that calls them is performed. AJAX Panels can be reused across multiple master pages, in order to reduce development time. For instance, you can reuse a menu panel in all your site pages, without having to rebuild it each time.




When AJAX links are clicked within a site, only the targeted panel state is loaded, independently and asynchronously, without refreshing the whole page.
Working with AJAX panels will appear very familiar to developers, since the approach is similar to using editable regions in Dreamweaver templates, or using master pages in Microsoft Visual Studio.
Increased interactivity and responsiveness
With MX AJAX Toolbox, developers can build Rich Internet Applications (RIA) that interact with site visitors, offering them a unique web experience. Visitors can continue using the website while parts of it load separately and asynchronously. They will enjoy the increased interactivity that comes with a suite of AJAX controls and widgets included in the toolbox. AJAX websites will render fast on their first load, while incrementally loading necessary JavaScript files in the background. This means users on slow connections (such as dial-up) will be able to see and interact with the website immediately after they access it.
Reduced loading time and server traffic
Since only parts of the site are loaded at one time (states of the AJAX panels), the loading time is obviously shorter than if the whole page refreshed. Server traffic is considerably reduced. Because only parts of the page content are sent, the bandwidth usage decreases and websites will appear to load seamlessly.

The Purpose of the Marker Interface

One of the "clean" features of the Java programming language is that it mandates a separation between interfaces (pure behavior) and classes (state and behavior). Interfaces are used in Java to specify the behavior of derived classes.

Often you will come across interfaces in Java that have no behavior. In other words, they are just empty interface definitions. These are known as marker interfaces. Some examples of marker interfaces in the Java API include:


- java,lang.Cloneable
- java,io.Serializable
- java.util.EventListener


Marker interfaces are also called "tag" interfaces since they tag all the derived classes into a category based on their purpose. For example, all classes that implement the Cloneable interface can be cloned (i.e., the clone() method can be called on them). The Java compiler checks to make sure that if the clone() method is called on a class and the class implements the Cloneable interface. For example, consider the following call to the clone() method on an object o:


SomeObject o = new SomeObject();
SomeObject ref = (SomeObject)(o.clone());

If the class SomeObject does not implement the interface Cloneable (and Cloneable is not implemented by any of the superclasses that SomeObject inherits from), the compiler will mark this line as an error. This is because the clone() method may only be called by objects of type "Cloneable." Hence, even though Cloneable is an empty interface, it serves an important purpose.

IO Operations - Reading a File

package com.test.corejava;

/**
*
* @author seetharam
*/
import java.io.*;

public class IOReading {

/**
* Fetch the entire contents of a text file, and return it in a String.
* This style of implementation does not throw Exceptions to the caller.
*
* @param aFile is a file which already exists and can be read.
*/
public static String getContents(File aFile) {
//...checks on aFile are elided
StringBuilder contents = new StringBuilder();

try {
//use buffering, reading one line at a time
//FileReader always assumes default encoding is OK!
BufferedReader input = new BufferedReader(new FileReader(aFile));
try {
String strLine = null; //not declared within while loop
/*
* readLine is a bit quirky :
* it returns the content of a line MINUS the newline.
* it returns null only for the END of the stream.
* it returns an empty String if two newlines appear in a row.
*/
while (( strLine = input.readLine()) != null){
contents.append(strLine);
contents.append(System.getProperty("line.separator"));
}
}
finally {
input.close();
}
}
catch (IOException ex){
ex.printStackTrace();
}

return contents.toString();
}
public static void main(String a[]){

File f= new File("c:/myfile.txt");
String str =getContents(f);
System.out.println(str);
}
}

idempotent request and non-idempotent request - in HttpServletResquest Header

Official definition from dictionary.com is "unchanged when multiplied by itself". In HTTP perspective, you can send idempotent requests multiple times without altering system state / data / resource.

Since get requests are meant to get required resource and not change anything, it's considered idempotent. Although technically it's feasible to implement your program in bad way that would alter the data even for get request.

Post request are usually implemented to achieve server side action that would alter data. For example, providing your credit card and submitting purchase button. If you submit the button twice, chances are that you might pay twice! Since post requests are non-idempotent, one should take extra care in implementing it such that duplicate request doesn't go through.

mutable and immutable objects in java

As per the dictionary, mutable objects are objects which can change their values and immutable objects are objects which cannot have their values changed.

>>java.lang.String is an example of an immutable object in Java
whereas
>>java.lang.StringBuffer is a mutable object.

response.sendRedirect-RequestDispatcher.forward-PageContext.forward

Q. What is the difference between response.sendRedirect(), RequestDispatcher.forward(), and PageContext.forward()?

In a nutshell, RequestDispatcher.forward() works on the server and response.sendRedirect() works on the browser. When you invoke RequestDispatcher.forward(), the servlet engine transfers control of this HTTP request internally from your current servlet or JSP to another servlet or JSP or static file. When you invoke response.sendRedirect(), this sends an HTTP response to the browser to make another request at a different URL.

RequestDispatcher.forward() and PageContext.forward() are effectively the same. PageContext.forward() is a helper method that calls the RequestDispatcher method.

Page Directive

Defines attributes that apply to an entire JSP page.

Syntax

<%@ page

[ language="java" ]

[ extends="package.class" ]

[ import="{package.class | package.*}, ..." ]

[ session="true|false" ]

[ buffer="none|8kb|sizekb" ]

[ autoFlush="true|false" ]

[ isThreadSafe="true|false" ]

[ info="text" ]

[ errorPage="relativeURL" ]

[ contentType="mimeType [ ;charset=characterSet ]" |

"text/html ; charset=ISO-8859-1" ]

[ isErrorPage="true|false" ]

%>

Examples

<%@ page import="java.util.*, java.lang.*" %>

<%@ page buffer="5kb" autoFlush="false" %>

<%@ page errorPage="error.jsp" %>

Description

The <%@ page %> directive applies to an entire JSP file and any of its static include files, which together are called a translation unit. A static include file is a file whose content becomes part of the calling JSP file. The <%@ page %> directive does not apply to any dynamic include files; see for more information.

You can use the <%@ page %> directive more than once in a translation unit, but you can only use each attribute, except import, once. Because the import attribute is similar to the import statement in the Java programming language, you can use a <%@ page %> directive with import more than once in a JSP file or translation unit.

No matter where you position the <%@ page %> directive in a JSP file or included files, it applies to the entire translation unit. However, it is often good programming style to place it at the top of the JSP file.
Attributes

* language="java"

The scripting language used in scriptlets, declarations, and expressions in the JSP file and any included files. In this release, the only allowed value is java.

* extends="package.class"

The fully qualified name of the superclass of the Java class file this JSP file will be compiled to. Use this attribute cautiously, as it can limit the JSP container's ability to provide a specialized superclass that improves the quality of the compiled file.

* import="{package.class | package.*}, ..."

A comma-separated list of Java packages that the JSP file should import. The packages (and their classes) are available to scriptlets, expressions, and declarations within the JSP file. If you want to import more than one package, you can specify a comma-separated list after import or you can use import more than once in a JSP file.

The following packages are implicitly imported, so you don't need to specify them with the import attribute:

java.lang.*
javax.servlet.*
javax.servlet.jsp.*
javax.servlet.http.*

You must place the import attribute before the element that calls the imported class.

* session="true|false"

Whether the client must join an HTTP session in order to use the JSP page. If the value is true, the session object refers to the current or new session.

If the value is false, you cannot use the session object or a element with scope=session in the JSP file. Either of these usages would cause a translation-time error.

The default value is true.

* buffer="none|8kb|sizekb"

The buffer size in kilobytes used by the out object to handle output sent from the compiled JSP page to the client Web browser. The default value is 8kb. If you specify a buffer size, the output is buffered with at least the size you specified.

* autoFlush="true|false"

Whether the buffered output should be flushed automatically when the buffer is full. If set to true (the default value), the buffer will be flushed. If set to false, an exception will be raised when the buffer overflows. You cannot set autoFlush to false when buffer is set to none.

* isThreadSafe="true|false"

Whether thread safety is implemented in the JSP file. The default value is true, which means that the JSP container can send multiple, concurrent client requests to the JSP page. You must write code in the JSP page to synchronize the multiple client threads. If you use false, the JSP container sends client requests one at a time to the JSP page.

* info="text"

A text string that is incorporated verbatim into the compiled JSP page. You can later retrieve the string with the Servlet.getServletInfo() method.

* errorPage="relativeURL"

A pathname to a JSP file that this JSP file sends exceptions to. If the pathname begins with a /, the path is relative to the JSP application's document root directory and is resolved by the Web server. If not, the pathname is relative to the current JSP file.

* isErrorPage="true|false"

Whether the JSP file displays an error page. If set to true, you can use the exception object in the JSP file. If set to false (the default value), you cannot use the exception object in the JSP file.

* contentType="mimeType [; charset=characterSet ]" |
"text/html;charset=ISO-8859-1"

The MIME type and character encoding the JSP file uses for the response it sends to the client. You can use any MIME type or character set that are valid for the JSP container. The default MIME type is text/html, and the default character set is ISO-8859-1.