Chapter 4. Wedge Framework

Table of Contents

4.1. Introduction
4.2. Wedge Elements
4.2.1. Using Naming Conventions
4.2.2. Java Classes Reloading
4.2.3. Wedge Pages
4.2.4. Wedge Frames
4.2.5. Wedge User Defined Components
4.3. Framework Components
4.3.1. Code Components
4.3.2. Links
4.3.3. Forms

4.1. Introduction

An application consists of several pages, each of them having a frame in which it will be embedded and also a list of parts (components) which can be emebedded either in a page, a frame or another components.

[Note] Why 'part' and not 'component'?

Because it's a smaller word and it's easier to write. Thus, in a configuartion file (if needed) you write <wedge:part ... > instead of <wedge:component ... >. And, from an aesthetic point of view, the word 'part' aligns better with the words 'page' and 'frame'.

There is some concepts that framework introduces whose meaning may not be so obvious for a developer that has some knowledge on other frameworks like Tapestry or Wicket (both of them are component centric java web frameworks).

That's why we will try to present the main concepts of the framework and what each of them means. And, of course, why reinvent the wheel!

Java Side of the Problem

introduces a simpler way to develop web application by not forcing you to extends or implement framework specific classes or interfaces. is commited to provide a POJO (Plain Old Java Object) based application framework. Contrary, frameworks like Tapestry or Wicket impose a rather unnatural programming model by forcing you to write classes that extends their specific classes. More that this, Tapestry advice that the classes be abstract.

Wicket framework made the choice of moving most of the development on the java side. Components are wired programatically by the developer in a Swing like manner. The events are also handled in the well known swing style. Wicket framework also managed of providing a configuration free application development. However, the amount of code that is needed and the fact that the code is aware of page/components classes, links, forms and all that, this is a problem that Wedge tries to solve. We'll see how right away.

Tapestry works with abstract classes for pages or components. This classes are enhanced at runtime by the framework in order to inject specific functionality. The next generation of Tapestry will address this problem by allowing you to have annotated POJO's instead of framework specific classes. This will be a major step forward and Tapestry will be fully rewritten for this. If we may express ourself like this, Tapestry will reinvent the wheel itself, too!.

How solves the problem?

framework inspires from both frameworks mentioned above and tries to solve problems that (altough both frameworks are mature and powerfull) still make application development hard.

In order to realize this, makes strong use of runtime code generation. It generates classes at runtime, as needed, and loads them in separate class loader.

In development mode, wedge may detect changes in templates and reload that template and regenerate the class with a different name. This process is totaly transparent to the developer as she never gets to see or use that code directly.More than this, wedge is capable to reload the java classes for the pages, parts and frames.

Thus, you may modify both the template and the java class and see the result right away by simply refreshing browser window.

In a application that uses , the classes behind the pages are simple POJO's. As in Tapestry, event listeners are simple methods that are called when the user clicks on a link or submit a form. There is no restriction on the signature of the listener methods. This event listeners are not declared in the java class but rather in the template that stands in front of the class. still makes use of OGNL expression to make the connection between the template and the class behind it. However, these OGNL expressions are transformed into the corresponding java code. Thus, they are not evaluated again and again at runtime like in Tapestry but rather are executed as normal java code.

Example 4.1. OGNL Expression Evaluation

	// For a expression like 'book.author.name'
	// OGNL evaluation is
	Ognl.getValue("book.author.name", instance); // Slower!
	
	// But in wedge generated code it evaluates like this:
	instance.getBook().getAuthor().getName(); // Faster!