Sei sulla pagina 1di 13

Ajax Ajax an acronym for Asynchronous JavaScript and XML)[1] is a group of interrelated web development methods used on the

client-side to create asynchronous web applications. With Ajax, web applications can send data to, and retrieve data from, a server asynchronously (in the background) without interfering with the display and behavior of the existing page. Data is usually retrieved using the XMLHttpRequest object. Despite the name, the use of XML is not needed (JSON is often used instead), and the requests do not need to be asynchronous.[2] Ajax is not one technology, but a group of technologies. Ajax uses a combination of HTML and CSS to mark up and style information. The DOM is accessed with JavaScript to dynamically display, and to allow the user to interact with the information presented. JavaScript and the XMLHttpRequest object provide a method for exchanging data asynchronously between browser and server to avoid full page reloads. History In the 1990s, most web sites were based on complete HTML pages; each user action required that the page be reloaded from the server (or a new page loaded). This process is inefficient, as reflected by the user experience: all page content disappears then reappears, etc. Each time a page is reloaded due to a partial change, all of the content must be

re-sent instead of only the changed information. This can place additional load on the server and use excessive bandwidth. Asynchronous loading of content first became practical when Java applets were introduced in the first version of the Java language in 1995. These allow compiled clientside code to load data asynchronously from the web server after a web page is loaded.[3] In 1996, Internet Explorer introduced the iframe element to HTML, which also enabled asynchronous loading.[4] In 1999, Microsoft utilized its iframe technology to dynamically update the news stories and stock quotes on the default page for Internet Explorer (http://home.microsoft.com). In April 2000 Microsoft filed a patent on the basic Ajax technology, which was granted in June 2006, related to ASP.[5] In 1999, Microsoft created the XMLHTTP ActiveX control in Internet Explorer 5, which was later adopted by Mozilla, Safari, Opera and other browsers as the XMLHttpRequest JavaScript object.[4][6] Microsoft has adopted the native XMLHttpRequest model as of Internet Explorer 7, though the ActiveX version is still supported. The utility of background HTTP requests to the server and asynchronous web technologies remained fairly obscure until it started appearing in full scale online applications such as Outlook Web Access (2000)[7] and Oddpost (2002), and later, Google made a wide deployment of Ajax with Gmail (2004) and Google Maps (2005).[8] The term Ajax was coined on February 18, 2005 by Jesse James Garrett in an article entitled "Ajax: A New Approach

to Web Applications", based on techniques used on Google web pages.[1] On April 5, 2006 the World Wide Web Consortium (W3C) released the first draft specification for the XMLHttpRequest object in an attempt to create an official web standard. Technologies The term Ajax has come to represent a broad group of web technologies that can be used to implement a web application that communicates with a server in the background, without interfering with the current state of the page. In the article that coined the term Ajax, Jesse James Garrett explained that the following technologies are incorporated:

HTML (or XHTML) and CSS for presentation The Document Object Model (DOM) for dynamic display of and interaction with data XML for the interchange of data, and XSLT for its manipulation The XMLHttpRequest object for asynchronous communication JavaScript to bring these technologies together

Since then, however, there have been a number of developments in the technologies used in an Ajax application, and the definition of the term Ajax. In particular, it has been noted that JavaScript is not the only client-side scripting language that can be used for

implementing an Ajax application; other languages such as VBScript are also capable of the required functionality. JavaScript is the most popular language for Ajax programming due to its inclusion in and compatibility with the majority of modern web browsers. Also, XML is not required for data interchange and therefore XSLT is not required for the manipulation of data. JavaScript Object Notation (JSON) is often used as an alternative format for data interchange, although other formats such as preformatted HTML or plain text can also be used. Simple API for XML SAX (Simple API for XML) is an event-based sequential access parser API developed by the XML-DEV mailing list for XML documents.[1] SAX provides a mechanism for reading data from an XML document that is an alternative to that provided by the Document Object Model (DOM). Where the DOM operates on the document as a whole, SAX parsers operate on each piece of the XML document sequentially. Definition Unlike DOM, there is no formal specification for SAX. The Java implementation of SAX is considered to be normative. [2] It is used for state-independent processing of XML documents, in contrast to StAX that processes the documents state-dependently.[3]

[edit] Benefits SAX parsers have certain benefits over DOM-style parsers. The quantity of memory that a SAX parser must use in order to function is typically much smaller than that of a DOM parser. DOM parsers must have the entire tree in memory before any processing can begin, so the amount of memory used by a DOM parser depends entirely on the size of the input data. The memory footprint of a SAX parser, by contrast, is based only on the maximum depth of the XML file (the maximum depth of the XML tree) and the maximum data stored in XML attributes on a single XML element. Both of these are always smaller than the size of the parsed tree itself. Because of the event-driven nature of SAX, processing documents can often be faster than DOM-style parsers. Memory allocation takes time, so the larger memory footprint of the DOM is also a performance issue. Due to the nature of DOM, streamed reading from disk is impossible. Processing XML documents larger than main memory is also impossible with DOM parsers, but can be done with SAX parsers. However, DOM parsers may make use of disk space as memory to sidestep this limitation. [4] [edit] Drawbacks The event-driven model of SAX is useful for XML parsing, but it does have certain drawbacks. Certain kinds of XML validation require access to the document in full. For example, a DTD IDREF attribute

requires that there be an element in the document that uses the given string as a DTD ID attribute. To validate this in a SAX parser, one would need to keep track of every previously encountered ID attribute and every previously encountered IDREF attribute, to see if any matches are made. Furthermore, if an IDREF does not match an ID, the user only discovers this after the document has been parsed; if this linkage was important to building functioning output, then time has been wasted in processing the entire document only to throw it away. Additionally, some kinds of XML processing simply require having access to the entire document. XSLT and XPath, for example, need to be able to access any node at any time in the parsed XML tree. While a SAX parser could be used to construct such a tree, the DOM already does so by design. [edit] XML processing with SAX A parser that implements SAX (i.e., a SAX Parser) functions as a stream parser, with an event-driven API.[1] The user defines a number of callback methods that will be called when events occur during parsing. The SAX events include:

XML Text nodes XML Element nodes XML Processing Instructions XML Comments

Events are fired when each of these XML features are encountered, and again when the end of them is encountered. XML attributes are provided as part of the data passed to element events. SAX parsing is unidirectional; previously parsed data cannot be re-read without starting the parsing operation again. [edit] Example Given the following XML document: <?xml version="1.0" encoding="UTF-8"?> <RootElement param="value"> <FirstElement> Some Text </FirstElement> <?some_pi some_attr="some_value"?> <SecondElement param2="something"> Pre-Text <Inline>Inlined text</Inline> Post-text. </SecondElement> </RootElement> This XML document, when passed through a SAX parser, will generate a sequence of events like the following: XML Element start, named RootElement, with an attribute param equal to "value" XML Element start, named FirstElement

XML Text node, with data equal to "Some Text" (note: text processing, with regard to spaces, can be changed) XML Element end, named FirstElement Processing Instruction event, with the target some_pi and data some_attr="some_value" XML Element start, named SecondElement, with an attribute param2 equal to "something" XML Text node, with data equal to "Pre-Text" XML Element start, named Inline XML Text node, with data equal to "Inlined text" XML Element end, named Inline XML Text node, with data equal to "Post-text." XML Element end, named SecondElement XML Element end, named RootElement

Note that the first line of the sample above is the XML Declaration and not a processing instruction; as such it will not be reported as a processing instruction event. The result above may vary: the SAX specification deliberately states that a given section of text may be reported as multiple sequential text events. Thus in the example above, a SAX parser may generate a different series of events, part of which might include:

XML Element start, named FirstElement XML Text node, with data equal to "Some " XML Text node, with data equal to "Text" XML Element end, named FirstElement

XSL In computing, the term Extensible Stylesheet Language (XSL) is used to refer to a family of languages used to transform and render XML documents. Historically, the XSL Working Group in W3C produced a draft specification under the name XSL, which eventually split into three parts: XSL Transformation (XSLT): is an XML language for 2. transforming XML documents 3. XSL Formatting Objects (XSL-FO): an XML language for specifying the visual formatting of an XML document 4. the XML Path Language (XPath): a non-XML language used by XSLT, and also available for use in non-XSLT contexts, for addressing the parts of an XML document.
1.

As a result, the term XSL is now used with a number of different meanings: Sometimes it refers to XSLT: this usage is best avoided. However, "xsl" is used both as the conventional namespace prefix for the XSLT namespace, and as the conventional filename suffix for files containing XSLT stylesheet modules Sometimes it refers to XSL-FO: this usage can be justified by the fact that the XSL-FO specification carries the title Extensible Stylesheet Language (XSL);

however, the term XSL-FO is less likely to be misunderstood Sometimes it refers to both languages considered together, or to the working group that develops both languages Sometimes, especially in the Microsoft world, it refers to a now-obsolete variant of XSLT developed and shipped by Microsoft as part of MSXML before the W3C specification was finalized [edit] History XSL began as an attempt to bring the functionality of DSSSL, particularly in the area of print and high-end typesetting, to XML. In response to a submission from Arbortext, Inso, and Microsoft,[1] a W3C working group on XSL started operating in December 1997, with Sharon Adler and Steve Zilles as co-chairs, with James Clark acting as editor (and unofficially as chief designer), and Chris Lilley as the W3C staff contact. The group released a first public Working Draft on 18 August 1998. XSLT and XPath became W3C Recommendations on 16 November 1999 and XSL-FO reached Recommendation status on 15 October 2001. [edit] "XSL" in Microsoft products Microsoft's MSXML, first released in March 1999, contained an incomplete implementation of the December 1998 transformation language published in the W3C XSL Working Draft. Microsoft documentation used the term

"XSL" to refer to this language as implemented in MSXML, including MSXML-specific extensions and omissions. Subsequently, when MSXML was updated to support the final W3C XSLT 1.0 Recommendation, Microsoft documentation referred to the obsolete dialect as "XSL" and to the new language as "XSLT". Other commentators follow the lead of Michael Kay[2] in referring to the older language as WD-xsl. Current versions of MSXML (as of 2009) continue to support the obsolete dialect, but no longer mention it in the documentation. Since the mid-2000 release of MSXML 3.0, MSXML has had complete support for both XSLT 1.0 alongside the older dialect. MSXML 3.0 became the default XML services library of Internet Explorer (IE) upon the release of IE 6.0 in August 2001. Older versions of IE could use MSXML 3.0 only with a custom install in "replace mode". [edit] The XSL family [edit] XSL Transformations Main article: XSL Transformations XSL Transformations (XSLT) currently has many implementations available. Several web browsers, including Internet Explorer (using the MSXML engine), Firefox, Mozilla, and Netscape (all using the TransforMiiX engine), Opera (native engine) and Safari, all support transformation of XML to HTML (or other languages) through XSLT. Other notable implementations include Saxon and Xalan.

[edit] XSL Formatting Objects Main article: XSL Formatting Objects Support for XSL Formatting Objects is available in a number of products: the XEP package from RenderX has near 100% support for XSL-FO 1.0 XSLFormatter from Antenna House also has near 100% support for the XSL-FO 1.0 specification and has 100% support for all new features within the XSL-FO 1.1 specification XINC from Lunasil has a great amount of support for the XSL-FO 1.0 specification FOP from the Apache project can render a portion of the XSL formatting objects 1.0 specification to PDF Xml2PDF Server 2007 from AltSoft has near 100% support for the XSL-FO 1.1

These products support output in a number of file formats, to varying degrees:


Portable Document Format PostScript SVG MIF PCL text files

[edit] XPath Main article: XPath

XML Path Language (XPath), itself part of the XSL family, functions within XSLT as a means of navigating an XML document. Another W3C project, XQuery, aims to provide similar capabilities for querying XML documents using XPath. The components of the XSL language The full XSL language logically consists of three component languages which are described in three W3C (World Wide Web Consortium) Recommendations:

XPath: XML Path Language--a language for referencing specific parts of an XML document XSLT: XSL Transformations--a language for describing how to transform one XML document (represented as a tree) into another XSL: Extensible Stylesheet Language--XSLT plus a description of a set of Formatting Objects and Formatting Properties