Fatwire/Sites API offers too many options that are confusing, and do not lead developers to follow best practices.

AgileSites API can overcome many of the complexities of Fatwire API, like the different way to access basic and flex attributes. The goal is to provide 80% of functionality with 20% of complexity. However, all existing Fatwire APIs are kept accessible and available, and can be used, if required.

A Fatwire website is typically very complex to deploy, since it includes many different components: library jars, customization jars, css and javascript files, CSElements, templates, database tables and some contents that must always be available.

AgileSites is provided from the ground up with an automated build system that performs all the steps necessary for installation and updates. Everything is kept in source form and can be deployed in an unchanged blank system. To install a new whole site you need only two commands, and another one to update it. You won't need to restart the application server after an update.

Usually a company already has a Sites/Fatwire application and is only looking for a better way to manage it. If you decide to give a try to AgileSites, you will be able to keep your existing site without having to rewrite everything.

AgileSites is totally compatible with any existing project. It implements templates in Java, but templates are called by standard JSP, so you can freely mix framework managed templates with existing templates. You can even write templates partially in JSP and partially in Java using the entire hot deploy infrastructure of the framework.

Continuous Integration is one of the key practices in Agile development. Every developer should work in isolation on his own computer, but when many developers are working at the same time, the full test suite must be run by a single development server.
Because of the limitations of the CMS, usually developers share a common development environment and rely on this to work as a team. This practice has a lot of shortcomings, including the possibility that the server becomes unavailable due to mistakes, conflicts while accessing the same template or definitions, the inability to work without a working internet connection and so on.

The entire framework is built in order to enable Agile Development and Test Driven practices. With AgileSites every developer can work on his local machine quickly and easily without the need to share a development environment.
Since there is a build, writing tests is easy, and a version control system can be used, every developer has just to commit his changes to a version control system like Git.

Coding in JSP with Fatwire/Sites has the advantage that you can see immediately the result without restarting the application server. Traditionally, when coding in Java, a major hassle is the need to restart the application server to see the code change.

One of the AgileSites key feature is hot deploy. After any code change, a jar is automatically built and copied in place, and the code is picked up immediately. No need to restart anything. So you have the advantage of being able to use full java without losing the immediate gratification of seeing the result without any delay that usually breaks the development flow and is a productivity killer.

The choice of development tools usable with Fatwire has been traditionally very limited. You have to use the windows-only and limited Content Server Explorer. More recently a few plugins have been made available, all of them Eclipse based, including the CSDT tool, but they are not completely satysfying.

An application built with AgileSites is a completely standard Java application which does not require any plugin to be edited: just add the relevant jars in the classpath. A tool to generate the correct classpath and downloading them from repositories is included. As a result, nothing else but any java IDE is required, and this can be Eclipse without plugins, NetBeans, Idea or even nothing at all. Compilation, packaging and deploying is included by a command line tool that is part of the framework.

Sites/Fatwire requires that developers implement templates either using JSP or the proprietary XML based language. JSP are great to implement a simple rendering logic, and JSPs are dynamic in that they are recompiled “in the blink of an eye”. Developers enjoy instant gratifications seeing immediately the results of their efforts. The problem with JSPs is that they are really meant to implement only a simple rendering logic. A normal Java Web Application uses also servlet as controller, and very often MVC frameworks to better organize the code. With Sites/Fatwire unfortunately JSP is the only method to develop a code.

The fundamental features of AgileSites is that it allows developers to write templates directly in Java, and provides APIs to render the view from an unchanged HTML (the typical HTML that you receive from web designers). Since accessing to the content model in Fatwire/Sites is usually done by using JSP tags, a specific API has been developed to provide easy invocation of JSP tags directly in Java. You have all the Java power in your hands. However, templates are still templates, and they are invoked by a JSP. The stub code to generate the JSP is managed automatically by the framework so you won't have to worry about it.

A common problem in Fatwire/Sites development is that templates do not implement a Model-View-Controller pattern. Instead, a template is just a JSP where you mix the rendering logic (view), the content reading logic (model) and some specific business logic (control)

AgileSites framework enables you to write your code in Java, not in JSP. Each template now has a corresponding class that acts as a controller. A specific API to define the content (model) and retrieve it, is provided, separating the model from the controller. Furthermore, also the view is kept separated, and in its original form: the view is indeed the original HTML as provided by web designers. Developers write all the template code in plain Java, implementing a controller that collect data from the model and place it in the view as needed.

In any large web development project, web designer are different from web developers, since different skills are required. Usually Web Designer delivers their work as a set of html/css/javascript files that are used by web developers to implement the web site in the CMS. Major problems arise when Web Designers update the web design, since at every update developers have to track down html changes and update the code following the changes in the design.

AgileSites allows developer to use unchanged original HTML files. A specific API, using jquery-like CSS based selectors allows you to pick specific pieces of html, replace them with content and render them without having to mix code and HTML. In this way web designers can freely update the html and the CSS and, as long as id and classes are kept unchanged, there is no need to change the business logic code.

Deploying code through publishing templates is error prone, does not capture real dependencies in code and is very hard to track.

The deployment of an AgileSites project is a single jar containing both source code and html resources. The jar is automatically packaged and deployed just copying it on his final destinations. Changes are picked when the jar is deployed.

If you pick the framework, you may want to keep getting support from the vendor, and using this framework should not be a reason to loose that support. Furthermore you want to use all the available features of Fatwire/Sites without being limited in any way.

AgileSites does not change the Fatwire/Sites way of operate in any way. Templates are still invoked using JSP, and JSP code is standard Java code, so nothing is different from standard practices. The entire hot deploy api is actually a standard feature of Java that exists since Java 1.0: it is implemented using the standard class loader used for applets. Everything else is provided either by java classes that extend existing api (but don't change it) and by a standard external build tool that packges your code and deploy it. Finally, the asset model update is implemented using standard Fatwire/Sites Elements and SiteEntries, invoked through the Catalog Manager. In conclusion, all the framework is a layer built on top of standard Fatwire/Sites and nothing is "invalidating your guarantee", except you may not ask support for the specific framework to the Vendor. Support for the framework however is provided by Sciabarra.com.

Agile programming mandates you to write tests for every features you implement. In addition to unit tests, is is important to be able to perform integration tests in an automated way. Unfortunately, with Fatwire/Sites templates live inside the CMS and are almost impossible to test: they can be called only through HTTP and often not directly. Templates depends on the current content model so you cannot reproduce their behaviour unless you initialise the whole content in an expected way, that can be very time consuming.

AgileSites keeps everything in source form in Java code, including metadata for templates. Developers work entirely outside of the CMS, then update metadata and deploy code with a single command, without having to restart the application server. The development lifecycle is pretty fast. However, since everything is still in source format and not kept outside the CMS, it can be modified, shared, merged and tracked using any standard version control system, either subversion, git, mercurial or proprietary systems.