Undo whenever you make a mistake
If you have made a mistake in editing, either by wrongly deleting text or inserting it at a wrong location, then as a first measure, just press{Esc} and then u to undo the last action. If that makes matters worse, use u again. Linux users should insted use {Ctrl-r}.
Cleaning the screen
If the screen gets garbled for some reason, use {Ctrl-l}(el) in Command Mode to redraw the screen. If you hit {Ctrl-l} in the Input Mode, you'll see ^l on the screen, use the backspace key to wipe it out, press{Esc} and then hit {Ctrl-l}.
Don't use {CapsLock}
vi commands are case-sensitive; a and A are different commands.
Avoid using the PC navigation Keys
As far as possible, avoid using all the standard navigation keys.
Tuesday, June 5, 2007
Mashup Styles
Before delving into mashup styles, it's important to understand that despite the definition of the term mashup. If a web site uses data or functionality from another web site and combines it in an application, it's a mashup. The application can access the data or functionality in various ways. It can use formal Representational State Transfer (REST)-based APIs provided by the other site. Or it can do some informal screen scraping, in which it extracts data from the displayed output of a program on another site. Or it can access an RSS feed or use a widget provided by another site. However, if the application simply links to another site, for instance, through an HTML href link, it is not a mashup. In the simplest sense, if your web application is using other web sites, it's a mashup.
The two primary mashup styles are server-side mashups and client-side mashups. As you might expect, server-side mashups integrate services and content on the server. The server acts as a proxy between a web application on the client, typically a browser, and the other web site that takes part in the mashup. In a server-side mashup, all the requests from the client go to the server, which acts as a proxy to make calls to the other web site. So, in a server-side mashup, the work is pushed from the web application client to the server.
In general,
1. A user generates an event in the client, typically a web page in a browser. The event triggers a JavaScript function in the client.
2.The client makes a request to the server in your web site. The request is typically an Ajax request in the form of an XmlHttpRequest object.
3. A web component such as a servlet receives the request and calls a method on a Java class or on multiple Java classes. The class or classes encapsulate the code to connect and interact with the other web site in the mashup. This class, referred to here as the proxy class, could be a Java Platform Enterprise Edition (Java EE) component or just a plain Java class that you write.
4. The proxy class processes the request, augments it as needed, and opens a connection to the mashup site, that is, the web site that provides the needed service.
5. The mashup site receives the request, usually in the form of an HTTP GET or HTTP POST, processes the request, and returns data to the proxy class.
6. The proxy class receives the response and may transform it to an appropriate data format for the client. It can also cache the response for future request processing.
7. The servlet returns the response to the client.
8. A callback function exposed in the XmlHttpRequest updates the client view of the page by manipulating the Document Object Model (DOM) that represents the page.
Client-side mashups integrate services and content on the client. They mash up directly with the other web site's data or functionality. For example, in a client-side mashup, the client might make requests directly to the other web site.
In general,
1. The browser makes a request to the server in your web site for the web page.
2. The server on your web site loads the page into the client. The page usually includes a JavaScript library from the mashup site -- for example, from a site such as Google Maps -- to enable using the mashup site's service. If the page does not include a JavaScript library, you can write a custom JavaScript function to facilitate the mashup.
3. Some action in the browser page calls a function in the JavaScript library provided by the mashup site, or it calls the custom JavaScript function that you created. The function creates a <script> element that points to the mashup site.
4. Based on the <script> element, a request is made to the mashup site to load the script.
5. The mashup site loads the script. Typically, a local callback in the browser page is then executed with a JavaScript Object Notation (JSON) object sent as a parameter.
6. The callback function updates the client view of the page by manipulating the DOM that represents the page.
The two primary mashup styles are server-side mashups and client-side mashups. As you might expect, server-side mashups integrate services and content on the server. The server acts as a proxy between a web application on the client, typically a browser, and the other web site that takes part in the mashup. In a server-side mashup, all the requests from the client go to the server, which acts as a proxy to make calls to the other web site. So, in a server-side mashup, the work is pushed from the web application client to the server.
In general,
1. A user generates an event in the client, typically a web page in a browser. The event triggers a JavaScript function in the client.
2.The client makes a request to the server in your web site. The request is typically an Ajax request in the form of an XmlHttpRequest object.
3. A web component such as a servlet receives the request and calls a method on a Java class or on multiple Java classes. The class or classes encapsulate the code to connect and interact with the other web site in the mashup. This class, referred to here as the proxy class, could be a Java Platform Enterprise Edition (Java EE) component or just a plain Java class that you write.
4. The proxy class processes the request, augments it as needed, and opens a connection to the mashup site, that is, the web site that provides the needed service.
5. The mashup site receives the request, usually in the form of an HTTP GET or HTTP POST, processes the request, and returns data to the proxy class.
6. The proxy class receives the response and may transform it to an appropriate data format for the client. It can also cache the response for future request processing.
7. The servlet returns the response to the client.
8. A callback function exposed in the XmlHttpRequest updates the client view of the page by manipulating the Document Object Model (DOM) that represents the page.
Client-side mashups integrate services and content on the client. They mash up directly with the other web site's data or functionality. For example, in a client-side mashup, the client might make requests directly to the other web site.
In general,
1. The browser makes a request to the server in your web site for the web page.
2. The server on your web site loads the page into the client. The page usually includes a JavaScript library from the mashup site -- for example, from a site such as Google Maps -- to enable using the mashup site's service. If the page does not include a JavaScript library, you can write a custom JavaScript function to facilitate the mashup.
3. Some action in the browser page calls a function in the JavaScript library provided by the mashup site, or it calls the custom JavaScript function that you created. The function creates a <script> element that points to the mashup site.
4. Based on the <script> element, a request is made to the mashup site to load the script.
5. The mashup site loads the script. Typically, a local callback in the browser page is then executed with a JavaScript Object Notation (JSON) object sent as a parameter.
6. The callback function updates the client view of the page by manipulating the DOM that represents the page.
Subscribe to:
Posts (Atom)