Ajax Framework

From Wikipedia, the free encyclopedia

An Ajax framework is a framework that helps to develop web applications that use Ajax, 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 process Ajax requests. The goal of the framework is to provide the Ajax engine described below and associated server and client-side functions.

Benefit of a framework

In the article that coined the "Ajax" term, J.J. Garrett describes the technology as "an intermediary...between the user and the server."^[1] This Ajax engine is intended to suppress the delays perceived by the user when a page attempts to access the server. A framework eases the work of the Ajax programmer at two levels: on the client side, it offers JavaScript functions to send requests to the server. On the server side, it processes the requests, searches for the data, and transmits them to the browser. Some frameworks are very elaborate and provide a complete library to build web applications.

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.

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 for server-side developers at the expense of some degree of power and performance. Ajax frameworks that handle presentation completely within the browser offer greater responsiveness because they handle many more user interactions without server involvement. In a server-driven model, some UI interactions can become chatty, for example an input field that is dynamically enabled or disabled based on server-side code may cause many network requests. Furthermore, server-dependent Ajax frameworks will never be able to offer offline support. Still, this approach is popular, especially in situations where the benefits of a full Ajax architecture can't be captured anyway.

Extending such a framework may require the developer to understand which parts of the presentation are handled on the client vs on the server, and to write a mixture of Ajax and server-side code.

Frameworks and languages/platforms

JavaScript

JavaScript utilities run browser-side and are very commonly used in Ajax development. There are many JavaScript utilities available. Prototype is a JavaScript extension that provides utilities to compensate for the shortcomings of JavaScript. Script.aculo.us is used with the Prototype Framework, mainly providing utilities for animations. Yahoo! UI Library is a set of utilities and controls for building richly interactive web applications using techniques such as DOM scripting, DHTML and Ajax. In addition to JavaScript utilities there are more complete Ajax Frameworks that provide utilities, pre-built widgets, debugging tools and visual Ajax development tools and client-server sync capabilities. Dojo Toolkit is a Javascript library and widgets architected to provide semantic extensions to HTML. ^[2]

PHP

A PHP framework is able to deal with database, search data, and build pages or parts of page and publish the page or return data to the XMLHttpRequest object. PHP 5 specifically, thanks to its SimpleXML class, is able to create XML files that may be returned to the object. However, the use of a framework will make the process easier for a developer.

Java

Such frameworks use Java for server-side AJAX operations. The Google Web Toolkit, a widget library with Java to JavaScript compiler is widely used by webmasters.

.NET

The Ajax.NET Professional and ASP.NET AJAX (previously Microsoft Atlas) frameworks are available for the Windows .NET platform. .NET framework 3.5 and Visual Studio 2008 come with many components that make an ajax developer's life easier such as the UpdatePanel. This panel captures all postback events fired by components in it and triggers a special postback that instead of rendering the whole page updates only the content of the panel. All events including Page_Load are still fired and the entire page is still sent back, just that the user will not be bothered with a flickering associated with a postback. While some believe this component to be a bad compromise between speed and javascript programming skills it improves efficiency by not spending valuable time working on client side scripting and focusing on the business logic. More traditional solutions such as asynchronous calls are still offered, plus the new possibility of and calling a JSON webservice and of course writing your own javascript code to handle the response

C++

C++ Toolkits are interfaces to Ajax technology. For example Wt (witty) is a WebToolkit allowing programmers to write code in C++ (without real knowledge of Ajax), generating content rich Ajax GUI. OpenSource Licence.

See also

• Ajax
• List of Ajax frameworks
• List of web application frameworks
• Comparison of JavaScript frameworks
• Content management framework
• JavaScript library

Hot Feature Of CakePHP

Basic Features

• Model, View, Controller Architecture
• Application Scaffolding
• Code generation via Bake
• Helpers for HTML, Forms, Pagination, AJAX, Javascript, XML, RSS and more
• Access Control Lists and Authentication
• Simple yet extensive validation of model data
• Router for mapping urls and handling extensions
• Security, Session, and RequestHandler Components
• Utility classes for working with Files, Folders, Arrays and more

There's More

• Internationalization and Localization with static translations in gettext style or dynamic translations of model data.
• Full Console environment with support for multiple tasks. Included shells: bake, schema, acl, i18 extractor, api
• CSRF protection via Security Component
• HTTP Authentication via Security Component
• Flexible Caching: use memcache, apc, xcache, the file system, or a model to speed up your application
• Configure class to provide dynamic handling of configuration settings and App class to handle importing required classes

Hot Features

• No Configuration - Set-up the database and let the magic begin
• Extremely Simple - Just look at the name...It's Cake
• Active, Friendly Community - Join us #cakephp on IRC. We'd love to help you get started.
• Flexible License - Distributed under the MIT License
• Clean IP - Every line of code was written by the CakePHP development team
• Best Practices - covering security, authentication, and session handling, among the many other features.
• OO - Whether you are a seasoned object-oriented programmer or a beginner, you'll feel comfortable

From : http://www.cakephp.org/

Why Zend Framework

Extending the art & spirit of PHP, Zend Framework is based on simplicity, object-oriented best practices, corporate friendly licensing, and a rigorously tested agile codebase. Zend Framework is focused on building more secure, reliable, and modern Web 2.0 applications & web services, and consuming widely available APIs from leading vendors like Google, Amazon, Yahoo!, Flickr, as well as API providers and cataloguers like StrikeIron and ProgrammableWeb.

Expanding on these core themes, we have implemented Zend Framework to embody extreme simplicity & productivity, the latest Web 2.0 features, simple corporate-friendly licensing, and an agile well-tested code base that your enterprise can depend upon.

Extreme Simplicity & Productivity

We designed Zend Framework with simplicity in mind. To provide a lightweight, loosely-coupled component library simplified to provide 4/5s of the functionality everyone needs and that lets you customize the other 20% to meet your specific business needs. By focusing on the most commonly needed functionality, we retain the simplified spirit of PHP programming, dramatically lower the learning curve, and your training costs – so developers get up-to-speed quickly. We do this with:

• Extensible and
  well-tested code base
• Flexible architecture
• No configuration files
  necessary to get going

Frameworks and best practices mean reduced training costs and quicker time-to-market – important factors in adoption decisions. Built so you can pick and choose just the pieces you need to turbocharge your web applications – all your developers know where to find their PHP / Zend Framework code, speeding new development and reducing maintenance costs.

Latest Web Development Features

• AJAX support through JSON – meet the ease-of-use requirements your users have come to expect
• Search – a native PHP edition of the industry-standard Lucene search engine
• Syndication – the data formats & easy access to them your Web 2.0 applications need
• Web Services – Zend Framework aims to be the premier place to consume & publish web services
• High-quality, object-oriented PHP 5 class library – attention to best practices like design patterns, unit testing, & loose coupling

Friendly & Simple Licensing, Safe for the Enterprise

Based on the simple and safe new BSD license, with Zend Framework's License, you rest assured that your code is compliant, unimpeachable, and protected as you see fit. We also require all contributors to the open source Zend Framework to complete and sign a Contributor License Agreement (CLA) — which is based on the standard open-source Apache license — protecting your own intellectual property (that is, your added-value) built on Zend Framework.

Fully Tested – Extend Safely and Easily

Tested. Thoroughly. Enterprise-ready and built with agile methods, Zend Framework has been unit-tested from the start, with stringent code coverage requirements to ensure that all code contributed has not only been thoroughly unit-tested, but also remains stable and easy for you to extend, re-test with your extensions, and further maintain.

From : http://framework.zend.com/whyzf/

Action Helpers in Zend Framework

Action Helpers in Zend Framework are often considered a fairly arcane subject, something for experts only. However, they are meant to be an easy way to extend the capabilities of Action Controllers, negating the need to create your own base controller with custom functionality. The aim of this tutorial is to show you how to quickly and easily create and use Action Helpers to your advantage.

Basics

Many tutorials on Zend Framework would have you believe you should create a base class extending Zend_Controller_Action to provide base functionality for your controllers:

/**
* Your concrete controllers would now extend My_Controller_Action
*/
abstract class My_Controller_Action extends Zend_Controller_Action
{
  // create your utility methods here...
}

However, this is not only not necessary, but typically not a great move for extensibility. You may find later that a given controller only needs a subset of the methods in your base controller -- or that you're constantly adding methods that only a few of your controllers need, creating bloat.

The better solution is to use action helpers. Action helpers are intended to provide run-time, use-at-will capabilities to action controllers. In other words, you can use them if you need them, but they aren't loaded by default.

Action helpers are handled by a broker. Zend_Controller_Action_HelperBroker maintains a static registry of registered helpers, and also serves as a factory for loading helpers on demand. By default, the $_helper property of Zend_Controller_Action contains an instance of the broker.

When an action controller is instantiated, a new broker instance is registered with it, and the action controller is in turn registered with the broker. When you retrieve or access helpers, they then have access to the controller -- allowing integration with it. So, for example, you can set public properties or call public methods on the action controller via your helper -- and vice versa.

In general, you retrieve your helper by using the last segment of the class name. So, for example, if your helper is named 'Foo_Helper_Bar', you'd refer to it as 'bar'. You then have two options for retrieving it: as a property of the broker, or via the getHelper() method:

$bar = $this->_helper->bar;
$bar = $this->_helper->getHelper('bar');

However, this is just the tip of the iceberg.

The direct() Method

Action helpers can use the Strategy Pattern. If you define the method direct() in your helper, you can call your helper as if it were a method of the broker.

An illustration is worth a thousand words. Let's look at the Url helper, which returns a URL based on the input received:

$url = $this->_helper->url('bar', 'foo'); // "/foo/bar"

Implementing the direct() method in your action helpers is an easy way to add virtual functionality to your actions.

Event Hooks

As if that wasn't enough, Action Helpers also have several event hooks to help automate functionality. The three hooks provided are:

• init(): called when the action controller is intialized (but only if an instance of the helper already exists in the broker)
• preDispatch(): called after plugin preDispatch() routines, but prior to the action controller preDispatch() routines -- but only if an instance of the helper already exists in the broker.
• postDispatch(): called after the action controller postDispatch() routines, but prior to plugin postDispatch() routines -- but only if an instance of the helper already exists in the broker.

Note the caveat on each: only if an instance of the helper exists in the broker already. Typically, you'll load helpers on-demand -- i.e., only when you need them. However, there are some cases where you may want to add automatic functionality similar to plugins -- but with the ability to introspect the current controller. This is where the action helper hooks come in handy.

As an example, the ViewRenderer, which is enabled by default in the ZF MVC, is an action helper. It uses the hooks as follows:

• init(): Initializes the view object, sets appropriate script, helper, and filter paths for the current controller, and registers the current view object as the controller's "view" member.
• postDispatch(): determines if it should render anything, and, if so, renders a view script based on the current (or requested) action to the appropriate response segment.

As another example, you could add a preDispatch() hook to an action helper that checks a public member of your action controller to determine which actions require authentication -- and redirect to a login form when a match is made. This works better than using a standard plugin, as it allows you to keep the information about authentication requirements with the controller -- where it belongs.

Registering Helpers with the Broker

If you want to make use of hooks, you will need to register your helpers early -- typically in the bootstrap or an early running plugin. To do this, you register them with the broker:

Zend_Controller_Action_HelperBroker::addHelper(
  new Foo_Helper_Bar()
);

However, another reason to register with the broker is to ensure that your custom helpers are found. To this end, you can simply tell the helper broker the class prefix of your helpers, so it knows where to find them:

// By class prefix:
Zend_Controller_Action_HelperBroker::addPrefix('Foo_Helper');

// Alternately, providing the path to classes with that prefix, if they
// are not on the include_path:
Zend_Controller_Action_HelperBroker::addPath($path, 'Foo_Helper');

Adding a path or prefix only tells the broker where to look for helpers -- it doesn't instantiate them. If you want a helper loaded before the dispatch cycle, so that event hooks can be utilized, you will still need to either add an instance of the helper to the broker, or attempt to retrieve it (which will create an instance). Which brings us to our next topic.

Retrieving Helpers from the Broker Statically

Sometimes you may find that you want to utilize an action helper outside an action controller -- perhaps to configure it, or because it offers functionality you need. The static method getStaticHelper() is used to perform this.

As an example, I often find I need to configure the ViewRenderer -- for instance, to set some default view helper paths. I can do so as follows:

$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('ViewRenderer');

$viewRenderer->initView(); // make sure the view object is initialized
$viewRenderer->view->addHelperPath($path); // set a helper path

It's a lot to type, but you typically won't need such functionality often. However, the functionality it provides is useful -- since only one instance of a particular helper can exist in the broker at any given time, you can be assured that you're configuring it globally.

Creating Your Own Helper

Action helpers should extend the Zend_Controller_Action_Helper_Abstract class. That class contains the following utility methods:

• setActionController(), for setting the current action controller
• getActionController(), for retrieving the current action controller
• getFrontController(), for retrieving the current front controller instance
• getRequest(), for retrieving the current request object (uses the action controller first, then looks in the front controller)
• getResponse(), for retrieving the current response object (uses the action controller first, then looks in the front controller)
• getName(), to return the name of the helper

In addition, you can also define any of the event hook methods as listed previously.

You can have your action helper do anything you want at this point. If it will have a common action, you may want to expose it via the direct() method, as detailed earlier. Otherwise, anything goes.

Example: Form Retrieval Helper

Now that we've learned about action helpers, let's create one.

For our example, let's say you have a suite of controllers that each use one or more forms; furthermore, let's say that a given form may be used in multiple controllers. We're going to create a helper that allows you to fetch a form by class name.

We'll assume that form classes are stored in the 'forms' subdirectory of the current module. We'll also assume that they are namespaced with the current module (unless we're in the default module), plus the prefix 'Form_'; e.g., if we had a 'news' module, forms would be prefixed with 'News_Form_'. Finally we'll use the name passed to the helper to determine which form class to load, using the prefix. We'll primarily use the direct() method to interact with the helper, as we only really have one thing we want the helper to do -- load forms.

/**
* Action Helper for loading forms
*
* @uses Zend_Controller_Action_Helper_Abstract
*/
class My_Helper_FormLoader extends Zend_Controller_Action_Helper_Abstract
{
  /**
   * @var Zend_Loader_PluginLoader
   */
  public $pluginLoader;

  /**
   * Constructor: initialize plugin loader
   *
   * @return void
   */
  public function __construct()
  {
      $this->pluginLoader = new Zend_Loader_PluginLoader();
  }

  /**
   * Load a form with the provided options
   *
   * @param  string $name
   * @param  array|Zend_Config $options
   * @return Zend_Form
   */
  public function loadForm($name, $options = null)
  {
      $module  = $this->getRequest()->getModuleName();
      $front   = $this->getFrontController();
      $default = $front->getDispatcher()
                       ->getDefaultModule();
      if (empty($module)) {
          $module = $default;
      }
      $moduleDirectory = $front->getControllerDirectory($module);
      $formsDirectory  = dirname($moduleDirectory) . '/forms';

      $prefix = (('default' == $module) ? '' : ucfirst($module) . '_')
              . 'Form_';
      $this->pluginLoader->addPrefixPath($prefix, $formsDirectory);

      $name      = ucfirst((string) $name);
      $formClass = $this->pluginLoader->load($name);
      return new $formClass($options);
  }

  /**
   * Strategy pattern: call helper as broker method
   *
   * @param  string $name
   * @param  array|Zend_Config $options
   * @return Zend_Form
   */
  public function direct($name, $options = null)
  {
      return $this->loadForm($name, $options);
  }
}

Place the above in a file named 'FormLoader.php' in the "My/Helper/" directory of your library (or any directory on your include_path).

Okay, now, how would we use it? Let's assume we're in the LoginController in the default module, and want to load the 'login' form. We'd name it 'Form_Login', and place the class file in 'forms/Login.php' in our application directory:

application/
  controllers/
      LoginController.php
  forms/
      Login.php - Contains class 'Form_Login'

In our bootstrap file or an early-running plugin, we'd make sure that we tell the broker where to find our helpers:

Zend_Controller_Action_HelperBroker::addPrefix('My_Helper');

And, finally, in our controller, we can now grab our form using the helper:

$loginForm = $this->_helper->formLoader('login');

Seem like a lot of work to simply load a form? Consider this: as long as you follow the rules outlined by our FormLoader helper, you can now use this in all your action controllers. So, you may have a UserController, and need to grab the registration form:

$regForm = $this->_helper->formLoader('registration');

Additionally, once you've registered a particular helper prefix (e.g., 'My_Helper'), you can drop other helpers in that same location, and they'll automatically be found by the broker -- you won't have additional setup past that original call to add the prefix to the broker.

The point here is that action helpers help you DRY up your code -- you push the bits and pieces you think you'll use again and again in your controllers to your action helpers. After a while, you'll have a library of controller-related functionality that you can draw on for other projects -- without needing your own, custom base class for action controllers, which ultimately leaves your library more extensible and flexible.

CodeIgniter is right for you if...

CodeIgniter is a powerful PHP framework with a very small footprint, built for PHP coders who need a simple and elegant toolkit to create full-featured web applications. If you're a developer who lives in the real world of shared hosting accounts and clients with deadlines, and if you're tired of ponderously large and thoroughly undocumented frameworks

CodeIgniter is right for you if...

• You want a framework with a small footprint.
• You need exceptional performance.
• You need broad compatibility with standard hosting accounts that run a variety of PHP versions and configurations.
• You want a framework that requires nearly zero configuration.
• You want a framework that does not require you to use the command line.
• You want a framework that does not require you to adhere to restrictive coding rules.

• You are not interested in large-scale monolithic libraries like PEAR.
• You do not want to be forced to learn a templating language (although a template parser is optionally available if you desire one).
• You eschew complexity, favoring simple solutions.
• You need clear, thorough documentation.

From : http://codeigniter.com/

About symfony

Symfony is a web application framework for PHP5 projects.

It aims to speed up the creation and maintenance of web applications, and to replace the repetitive coding tasks by power, control and pleasure.

The very small number of prerequisites make symfony easy to install on any configuration; you just need Unix or Windows with a web server and PHP 5 installed. It is compatible with almost every database system. In addition, it has a very small overhead, so the benefits of the framework don't come at the cost of an increase of hosting costs.

Using symfony is so natural and easy for people used to PHP and the design patterns of Internet applications that the learning curve is reduced to less than a day. The clean design and code readability will keep your delays short. Developers can apply agile development principles (such as DRY, KISS or the XP philosophy) and focus on applicative logic without losing time to write endless XML configuration files.

Symfony is aimed at building robust applications in an enterprise context. This means that you have full control over the configuration: from the directory structure to the foreign libraries, almost everything can be customized. To match your enterprise's development guidelines, symfony is bundled with additional tools helping you to test, debug and document your project.

Last but not least, by choosing symfony you get the benefits of an active open-source community. It is entirely free and published under the MIT license.

Symfony is sponsored by Sensio, a French Web Agency well known for its innovative views on web development.

From : http://www.symfony-project.org/about

Kohana "The Swift PHP Framework"

Kohana is a PHP 5 framework that uses the Model View Controller architectural pattern. It aims to be secure, lightweight, and easy to use.

Features

• Highly secure
• Extremely lightweight
• Short learning curve
• Uses the MVC pattern
• 100% UTF-8 compatible
• Loosely coupled architecture
• Extremely easy to extend

Technology

• Strict PHP 5 OOP
• Simple database abstraction using SQL helpers
• Multiple session drivers (native, database, and cookie)
• Powerful event handler allows small modifications dynamically
• Originally based on CodeIgniter

How is Kohana Different?

Although Kohana reuses many common design patterns and concepts, there are some things that make Kohana stand out:

1. Community, not company, driven. Kohana development is driven by a team of dedicated people that need a framework for fast, powerful solutions.
2. Strict PHP 5 OOP. Offers many benefits: visibility protection, automatic class loading, overloading, interfaces, abstracts, and singletons.
3. Extremely lightweight. Kohana has no dependencies on PECL extensions or PEAR libraries. Large, monolithic libraries are avoided in favor of optimized solutions.
4. GET, POST, COOKIE, and SESSION arrays all work as expected. Kohana does not limit your access to global data, but offers filtering and XSS protection.
5. True auto-loading of classes. True on-demand loading of classes, as they are requested in your application.
6. No namespace conflicts. All classes are suffixed to allow similar names between components, for a more coherent API.
7. Cascading resources offer unparalleled extensibility. Almost every part of Kohana can be overloaded or extended without editing core system files. Modules allow multi-file plugins to be added to your application, transparently.
8. Library drivers and API consistency. Libraries can use different "drivers" to handle different external APIs transparently. For example, multiple session storage options are available (database, cookie, and native), but the same interface is used for all of them. This allows new drivers to be developed for existing libraries, which keeps the API consistent and transparent.
9. Powerful event handler. Observer-style event handlers allow for extreme levels of customization potential.
10. Rapid development cycle. Rapid development results in faster response to user bugs and requests.

From : http://kohanaphp.com/home.html