Table of Contents
An wedge 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.
|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
There is some concepts that wedge 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!
Wedge introduces a simpler way to develop web application by not forcing you to extends or implement framework specific classes or interfaces. Wedge 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!.
Wedge 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, wedge 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 wedge, 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. Wedge 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!