History

jWic is based upon our experience in developing java based web applications. We have created it as a response to the emerging requirements of our customers, to create increasingly complex but comfortable web applications.

The jWic framework has been developed from our own projects as part of our proprietary toolbox a few years ago. In 2004, we extracted it from our toolbox and released it as a stand alone framework under an OSI compliant licence in May 2005. Here is the full story:

Where everything began ...

The development of the internal web framework started in winter 1999 by Florian Lippisch. It was built to meet the needs of our projects that required database access, security, resource management, multilingual support and separation of content from layout through a template utility called the skeleton parser. It was using modules to process requests and render responses using templates (so called skeletons).

The framework was initially Lotus Notes based using Lotus Script. It was ported to Java in spring 2000 and used the Servlet API of the Lotus Domino server. In winter 2000 we decoupled the framework from Lotus Notes. The framework was now running on any servlet container (we used JServ) and was developed using the IBM VisualAge IDE. Jens Bornemann joined the project around this time together with Adi Nitzu to implement all the features requested by the projects that were using the framework. Several other developers joined the project over time.

Cracks in the seams

In autumn 2002, the framework started to become a "heavyweight" with lots of modules and features, some developed on purpose that way and others that where contributed back from the projects. The number of dependencies between modules grew fast and started to become very difficult to handle (for example, some modules where often called by simple links in the templates. The developers of the modules specified their expected parameters in the URL, but they never knew who else was using the module. Refactoring of those modules produced unforseeable exceptions that were only detectable at runtime).

The problems increased when one of the main projects based upon the framework became very dynamic. The customer expected rich client like behaviour in the browser and the specifications changed often. Reusability was only possible on a page-level basis, which was inefficient as a number of features had to be combined into one page. The application had to remember the user inputs and states somehow while the user navigated through other forms but returned to a page later. This ended up in a overblown HttpSession to make the application stateful and each module ended up managing this "on its own".

The Answer was ...

Our response to these problems was the introduction of a component and event oriented API invented by Florian Lippisch and Jens Bornemann. Elements should become components that rendered themselves using the internal template language. Components should be able to be nested into containers and be used with other components on a page, without interferring with them. The components should "talk" to each other using events or access the API instead of building URLs with parameters. This component/event driven concept was not new for rich client programming (fat clients) - but this was new to the web application world.

We called the technology eWic and started to use it in our projects. There it had a major impact on the way that we worked. It solved a lot of our problems and brought back the joy of development. Components where easily developed by our off-shore partners with a clear API. Refactoring processes where no pain anymore and since the state handling was managed by the framework, the developers had less stuff to care about. Even our consultants who were out gathering specifications from our customers, found life easier as they could simply arrange the components together with the customer on paper to specify forms and workflows that looked similar to how they would be in the final system.

Keep what is good, throw away the rest

While this technology was still quite unique, other parts of the framework became old and obsolete as new products (both open source and commercial) came on the market that fulfilled the requirements we had. This was the time where we've put a lot of effort into investigating other technologies like hibernate, spring, JSF specs, velocity and others. We decided to extract eWic to run stand-alone with a minimum amount of dependencies as possible. Lightweight was the new direction to go and it felt good. The rendering was separated from the controls to allow users to use JSPs, the old fashion skeletons or velocity templates for their controls. Velocity became the default rendering engine as it fits very well into the concepts.

The extraction was done in summer 2004, which was basically a re-write of the whole engine. That was the reason why we renamed the project to jWic, as we felt that it fits better now that it is a light-weight java library for component and event oriented web programming.

After using jWic in several projects, we simply enjoyed working with it so we kept thinking about ways how to further improve it. This was the time we came up with the idea to release jWic as an open source project under a fully OSI compliant licence. Our goal was that this step would increase the quality of jWic, which indeed happened. A further motivation was, we wanted to give something back to the open source community. If jWic gains some recognition and people that use it find it helpful, maybe they too will contribute something to the project so we all can benefit from this collaborative effort.

Share it!

It took about 3 month after this decision until we released the first public version under an open source licence, which was in May 2005. Unfortunately, we had a lot of work-pressure from other projects in this time so that we did not put so much effort into telling the community about jWic. Our first public posting announcing the latest release happened in August 2006, almost 1 1/2 years after the first release.

We do now plan to make the project more transparent and to further inform the community about what happens around jWic. We really want to get in touch with you, discuss with you and provide a high quality framework, that brings the joy of development back.

The jWic Team!