| Revision as of 05:43, 12 January 2011 edit122.172.33.166 (talk) →Types of frameworks← Previous edit | Latest revision as of 19:48, 8 August 2016 edit undoHam Pastrami (talk | contribs)Extended confirmed users5,926 edits merge/redirect seems noncontroversial | ||
| (43 intermediate revisions by 32 users not shown) | |||
| Line 1: | Line 1: | ||
| ⚫ | #REDIRECT ] | ||
| {{noreferences|date=March 2010}} | |||
| An '''Ajax framework''' is a ] that helps to develop web applications that use ], a collection of technologies used to build dynamic web pages on the client side. Data is read from the server or sent to the server by JavaScript requests. However, some processing at the server side may be required to handle requests, such as finding and storing the data. This is accomplished more easily with the use of a framework dedicated to processing Ajax requests. The goal of the framework is to provide the Ajax engine and associated server and client-side functions. | |||
| ==Types of frameworks======== | |||
| Ajax frameworks can be loosely grouped into categories according to the features they offer and the skills required of the user: | |||
| ===Direct Ajax frameworks=== | |||
| These frameworks require HTML, CSS and Ajax expertise: a developer is expected to author pages directly in HTML, and framework APIs deal directly with HTML elements. Cross-browser APIs are provided for a variety of purposes, commonly including communications, DOM manipulation, event handling, and sizing/moving/animating HTML elements. | |||
| These frameworks are generally smaller. They are commonly used for a web ''site'' such as a shopping experience, but not for a web ''application'' such as web-based email, at least not without further frameworks layered on top. | |||
| ===Indirect Ajax frameworks=== | |||
| These frameworks are based on compiler technology, where, instead of writing direct Ajax and Javascript, a high-level language is used instead, along with a compiler that turns the high-level language into Javascript. Indirect frameworks therefore require knowledge of the high-level language, CSS and HTML, and do not necessarily require a great deal of Ajax or Javascript expertise. The Indirect frameworks are typically accompanied by convenient libraries, modules and classes (written in the high-level language) that take care of communications, DOM manipulation including HTML element manipulation, and event handling. | |||
| The advantages of Indirect Ajax frameworks - compilation to Javascript - are: | |||
| * the developer can effectively create their own Ajax framework using programming concepts and techniques appropriate to the high-level language (e.g. modules and classes) which are simply not present in the Javascript language. | |||
| * the to-javascript compiler can enforce strong type-checking and definition rules that standalone javascript does not | |||
| * a developer can program the web front-end in the same programming language as that which the server-side code is written in. | |||
| * the high-level web widget sets of the Indirect Ajax frameworks have far more in common with ] than they do with "traditional" web development. | |||
| * the framework, through the compiler, can create code that takes care of browser incompatibilities at run-time, and thus can present a common browser-independent API to the developer. | |||
| Indirect Ajax frameworks have distinct and significant advantages: | |||
| * Compared to Ajax component frameworks, the developer can use the available base class widgets to create their own widgets, in the high-level language with which they are familiar, instead of trying to get to grips with javascript. | |||
| * The developer is therefore neither burdened by the bloat of Ajax component frameworks nor bound by their rigidity. | |||
| * The developer has both the advantages of the Ajax component frameworks, and their associated widgets, as well as the advantages of the freedom of Direct Ajax frameworks. | |||
| * Indirect Ajax frameworks can be used to even greater effect in combination with a Server-driven framework (typically using ] or ]). | |||
| The main disadvantage of an Indirect Ajax framework is that debugging is more difficult because the Javascript produced by a compiler such as Google Web Toolkit results in somewhat obfuscated Javascript. | |||
| ===Ajax component frameworks=== | |||
| These frameworks offer pre-built components, such as tabbed panes, which automatically create and manage their own HTML. Components are generally created via JavaScript or XML tags, or by adding special attributes to normal HTML elements. These frameworks are generally larger, and intended for web ''applications'' rather than web ''sites''. | |||
| Some component frameworks require the developer to have extensive HTML/CSS/Ajax experience and to do cross-browser testing. For example, grids, tabs, and buttons may be provided, but user input forms are expected to be authored directly in HTML/CSS and manipulated via Ajax techniques. Other frameworks provide a complete component suite such that only general XML and/or JavaScript abilities are required. | |||
| Ajax component frameworks can enable more rapid development than direct Ajax frameworks, but with less control, hence it is key that an Ajax component framework provides the following: | |||
| * customization APIs, e.g., an event that fires when the user stops editing within a grid | |||
| * skinning facilities, where appearance can be changed without affecting behavior or layout | |||
| * programmatic control, e.g., dynamically adding tabs or dynamically creating components based on user data | |||
| * extensibility—creation of new components based on other components, so that the benefits of a component-based framework are not lost | |||
| ===Server-driven Ajax frameworks=== | |||
| Several frameworks offer a server-side component-based development model with some degree of Ajax support. | |||
| Components are created and manipulated on the server using a server-side programming language. Pages are then rendered by a combination of server-side and client-side HTML generation and manipulation. User actions are communicated to the server via Ajax techniques, server-side code manipulates a server-side component model, and changes to the server component model are reflected on the client automatically. | |||
| These frameworks offer familiarity and efficiency for server-side developers at the possible expense of power and performance. Ajax frameworks that handle presentation completely within the browser may offer greater responsiveness if they handle more user interactions without server involvement. In a server-driven model, some UI interactions can react slowly, for example when an input field is dynamically enabled based on server-requests. Furthermore, server-dependent Ajax frameworks can not offer ] support. The approach is still popular for situations where the benefits of a full Ajax architecture can't be captured or where server interaction is needed anyway. | |||
| Extending a framework may require the developer to understand which parts of the presentation are handled on the client vs on the server, and to code in JavaScript/Ajax as well as server-side code (an issue which can be overcome through the use of an Indirect Ajax framework, by choosing an Indirect Ajax framework. | |||
| ==See also== | |||
| ⚫ | |||
| *] | |||
| *] | |||
| *] | |||
| *] | |||
| *] | |||
| ==References== | |||
| {{Reflist}} | |||
| ==External links== | |||
| * Listing of hosted by the ] | |||
| {{DEFAULTSORT:Ajax Framework}} | |||
| ] | |||
| ] | |||
| ] | |||
| ] | |||
| ] | |||
| ] | |||
Latest revision as of 19:48, 8 August 2016
Redirect to: