Most of the application frameworks are slow to develop with. Typically they have heavy APIs that the programmer must know before start developing. Moreover, there are a lot of configurations and they to tend to be stored on XML files with convoluted structures the developer is forced to understand prior to coding.
Right from its inception the framework has been thought up to become a RAD (Rapid Application Development) tool. As such, a great deal of effort was put on making the framework to adapt to the developer and not the other way around. DIF uses automatic code generation via Java annotations to spare the programmer from writing repetitive code and configurations. It also provides a convention over configuration over coding philosophy to make automatic everything that is standard, leaving for the programmer just the "fill in the blanks". This goal applies not only to the project itself but to the IDE, the project management, documentation, unit testing, etc. This is possible not only due to the framework's architecture but also to the use of the project management tool: Maven.
All these features help the development process faster and more to the point.
DIF is a set of modules that can be assembled in different ways to adapt the framework to a particular need. For distinct customers there are often diverse realities and requirements. The programmer can easily customize the framework to those requirements and even provide its own implementations of some modules and have them working on DIF. These modules can go from framework architectural modules to high-tech end-user features, such as LDAP or Kerberos authentication.
This flexibility comes in the form of IoC. There's an IoC abstraction layer so you can use different implementations, see it here. DIF itself was designed to support integration of distinct technologies and to interact with them in a transparent way. Even the extension or creation of a new module is very easy so you can integrate it even with YOUR proprietary technology.
One DIF's main concerns is execution speed. To attain such levels of performance, DIF uses automatic code generation. Several code optimizations are made by the framework without any programmer's intervention thus increasing performance and response time on critical execution time spots.
Another performance optimization mechanism is the use of Java-based caches for significant data. Since the data is available on RAM there will be no performance hit due to accessing the data on an external repository.
The framework's modular architecture also enables the configuration for different environments allowing clients to have the thinnest system as their needs requires. This capability permits the framework to be adjusted to the user's exact needs in terms of software and even in terms of hardware. The latter would mean having the framework configured to use heavily the Java-based caches if a great deal of RAM is available, or even the other way around if a fast database server is available. If this doesn't suffices, it is possible to extend some of the framework modules to support a user-specific implementation or requirement set.
A quality assurance guide was developed to make sure that the framework presents a good level of robustness and correctness. The guide defines a set of best practices that make the product trustworthy. To get to know these practices please read this document.
A test-driven development methodology was used on all framework components. The extended use of unit and integration tests guarantees that every module works correctly and fits within the remaining structure. Testing is integrated in the development cycle and a new distribution can only be provided if the testing phase concludes with good results. The tested code coverage is monitored with dedicated tools and the coverage results are published in public domain sites (see it here). Moreover, a goal of "> 80%" tested code coverage implies a solid product.
There was a strong effort put on project documentation. As such, there are tutorials, FAQs and even more theory-oriented documentation for every framework module. Because this is an open-source project, several people from around the world will be accessing the source code and even extending it. As such, it is important to have well-documented source code. Every Java element and lesser-obvious code sections have javadoc comments. The SDK was even configured to issue errors on inexistant or malformed javadoc comments.
DIF's presentation layer offers full Web 2.0 support in the form of a ready-to-use set of reusable components. These components can be used "as shipped" or extending to suit one's particular needs. Also, using the components makes the development process faster and up to date. Despite being RIA-oriented, the presentation layer offers simpler component versions for accessibility-concerned environments.
Internationalization is common market trend nowadays and as such DIF could not ignore it. An efficient system of message customization was devised and implemented making very simple the translation of application contents. This mechanism also offers a great level of flexibility to expand the application contents. It is possible to extend the contents without interference in the remaining application parts.
With DIF you are not limited to have your applications running on the Web. A channel abstraction mechanism was implemented to let you go wherever you need to go! Do you need to integrate your application with Web Services? SMS? No problem! With DIF you can. You develop the service abstracted from the client channel and the framework will know how to render and transmit the contents the proper way.
The render engine is tied to the channel but not in an exclusive way. The channel abstraction is provided by two core modules that are hot spots and thus can be extended to provide support for new channels. The rendering engines can also be extended to support different view technologies.
The Web channel is provided out-of-the-box but soon you can expect support to other channels such as Web Services and portlets.