Integrated Development Environments in general and Eclipse/Aptana Studio specifically provide tree-based project explorers used to locate and launch files by displaying the file system that contains your project code. Typically the simple directory and file tree is marked up with:

• Icons for different file extensions
• Version information about the directories and files if connected to a version control system
• Context menus specific to each directory and file

This widely accepted approach to represent code files in a project has worked well in the past because projects and project components were typically:

• Written in one or several complementing programming languages
• Largely self-contained with required libraries imported into the project
• Mostly closed off to the outside and interacting with other applications through interfaces available only when the application is running in a development, testing or production environment
• Left for the developer to locate on the internet, download, import, maintain, test and publish

The traditional project explorer worked well for traditional web applications because it left application and file structure completely up to the developer. This was important because there were few frameworks available that combined HTML, CSS, JavaScript and PHP code into a cohesive architecture. The developer was able to structure code based on experience, trial and error and best practices where existent.

The downside of this approach to project structuring is that there is little standardization between projects making code sharing difficult and increasing the learning curve for new developers learning an existing application.

While code and component re-use and standardization across projects was and still is desirable the traditional project explorer offers little support to the developer in keeping things standardized. After all it only mirrors what was on the file system without any manipulation of the directory structure.

The need for a new kind of project explorer for web applications is primarily driven by forces such as:

• Increasing standardization in web technology library distribution and project integration
• Application deployment to standardized cloud environments
• Platform-as-a-service offerings
• Open source movement with many contributors to many project components

The AJAX-based Project Explorer

The purpose of the AJAX-based Project Explorer (APE) is to:

Liberate application architecture and lifecycle possibilities by lifting code organization from the file system.

For an APE the local (or remote) file system is no longer the source of data for the project explorer. Furthermore the APE does not dictate how a project’s directories and files are displayed allowing for an application-specific user interface. The interface would of course be an AJAX app that is fed from a server.

Thinking this through from a traditional web application development perspective makes little sense. Where would the AJAX app be hosted? How will the AJAX app know about the project files? Where do the project files reside?

The key to the APE is standardization and the use of a framework or a platform as a service. The framework would provide the AJAX app for the APE and the developer would write the application within the possibilities of the framework.

Advantages (Local Development)

The advantages to an APE are numerous and significant. Let’s say you want to develop a PHP application. You choose Zend Framework (ZF) as your framework because it provides ultimate flexibility and power and is supported by a large and active community.

ZF is a good choice because it imposes some standards on you including a well-debated recommended project structure that can be described via an XML definition file. The definition file can be used by Zend_Tool to make changes to your project.

ZF would provide an AJAX app for the APE (ZF-APE) that would be hosted on the same development server as your project code. The AJAX app would integrate with Zend_Tool to gain access to the project files in a standardised fashion via the XML project definition.

In it’s simplest form the ZF-APE would provide a traditional view into the project files using a file system based tree. Things start to get interesting when more meta information about code files, directory structure conventions, file contents, etc… is spliced into the ZF-APE. This information can be made available because the AJAX app is specific to the framework and the framework provides tools to reflect project meta data.

You could, for example offer:

• Filters on the file tree that would only display library files, controller files, view scripts or unit tests.
• Recognize components (as a collection of files following certain conventions) and displaying the components in more intuitive ways rather than a simple list of files.
• Different context menus for different files, directories and components allowing arbitrary execution of Zend_Tool features such as component creation, running of unit tests and packaging of project.
• A view that shows all controllers and actions in a tree that will launch the appropriate code file and position the cursor to the correct line when clicking on an action.
• Coding standard validation information for each file and component (using server-based or thrid party validation services)
• Unit test coverage information
• Integration with a debugger showing which file you are currently stepping through

The possibilities are endless. The point to note is that the APE will allow more intuitive project navigation and abstraction of standards away from files by focusing on logical entities instead. It enables simple means to acess a diverse set of files that may be spread all over the project codebase but belong together in a logical unit.

Advantages (Platform-as-a-Service)

Arguably the largest benefactor of the APE will be platform-as-a-service vendors. A service offering PHP, Ruby, Python, server-based JavaScript, some standard way to include common client-based JavaScript libraries, a database abstraction layer and content delivery network could provide an APE AJAX app that ties all these services into one coherent interface.

Rather than requiring the developer to use some online portal or vendor-specific IDE that is tied into their service (because project files are spread over several file systems in their internal system) the developer can acces the service via APE and a familiar IDE.

In this scenario the developer can write code, instantly preview the application on a development server provided by the vendor, publish the app to production servers and monitor it all without needing a local development environment. The vendor could even tie billing and account information into the APE to make the experience as seemless as possible.

Technical Requirements

Making APE a reality is actually a lot simpler than one may think. Let’s briefly examine what it will take:

• A new APE view for eclipse that loads any URL in an embedded browser (ideally Firefox)
• Several API’s to bridge between the loaded AJAX app (JavaScript) and eclipse (Java)
• A component for eclipse that communicates via the AJAX app with the project server allowing eclipse to mirror the logical project file system.

Important to note is that the project server provides a LOGICAL file system to eclipse. Eclipse editors and tools are based around files and directories. Changing this would be utterly impractical and is not necessary. So we need a way to mirror the actual distributed project files from the remote system via a unified logical tree to the local eclipse environment.

All project files would always be present locally and sent to the server when modified. This would allow existing eclipse tools such as search and many different project inspectors to continue to function.

One last important point to note is the directory and file structure will be less important to the developer over time. Absolute file locations in the project will become less important and relative location to a specific context (group of files) will become the focus. The actual mirrored directory structure will be optimized for eclipse tools and not for the purpose of having an easily comprehensible directory structure as is the case in traditional project explorers.

The code within files must not be complete in a traditional sense as the file is only a logical bucket. For example a file can contain code for only one specific controller action without all the plumbing code to wrap the action code. By itself the code would not run. However the project server knows where the code belongs in the project, what it needs to be wrapped with and how it needs to be organized relative to other actions.

Call to Action

If anyone out there is interested in exploring the APE concept by building the required view into eclipse and developing the necessary API’s and sync manager I would be very interested in building the first APE AJAX app to integrate with Zend Framework.