Table of Contents
Wedge framework came out of the desire to have a very simple way of building web applications. Its main two goals are to make the development simple both on the java side and web designer side. Existing frameworks like JavaServer Faces or Tapestry although popular and very good in their own way, have some disadvantages that makes them difficult to use without very good programming skills or very good design tools.
JavaServer Faces is a framework that uses JSP like templates that are hard to write by a web designer and hard to maintain and modify. Tapestry, the rival of JavaServer Faces, has simpler philosophy regarding the xhtml templates but is much more complicated in the java side of the application and in the required configurations. It requires the java classes for the application pages to be abstract and to extend a framework specific class. This is a serious intrusion into your application code and overcome the basic principals of object oriented programming.
Wedge framework is meant to solve the two disadvantages mentioned above: the object hierarchy of the java model behind the pages and the form of the templates.
In a classic MVC architecture, all the three parts - the model, the views and the controller - would be written by the programmer. Wedge framework brings out a slightly different perspective on this situation in order to realize its goals:
To achieve its goals wedge generates code. For each part, page or frame there is a class that is generated in order to bind the template and the backing bean into a single entity that will render the output. Thus, a lot of code that the programmer would have to write gets generated at runtime. This approach have several advantages over the usual ones, approach that will be sumarize in the next sections.
In a component centric perspective, a framework that follows this paradigm must deal with components that might have other components embedded within, such that in the end there will be a tree of components that need to be rendered into xhtml code. The render process asks for a lot of runtime reflection for initialization, dependency injection and parameters value setting. This slows down the process of rendering as all this operation needs to be done each time the components are rendered.
Unlike others frameworks that get into your application code, asking you extends its classes and implement some methods it knows about, wedge framework actually takes your code inside it. The generated code contains information both on the framework and your application code.
You are now alowed to focus only on what your application needs to do and write the minimum amount of code that will get the things done. The synbiosis between the framework and your application code is based on to aspects: 1. The information contained into the templates and 2. The naming convention that allow the application to run with less configuration. Simply by specifing a Spring bean with a given unique name and a java class will give wedge just enouch information to know where to look for the template and what to do with it.
When wedge framework parser loads the components templates and parses them, only the information on the components tags is considered. The rest of the tags are simply merged into large portions of text. So, instead of a huge tree of tags that needs to be traversed will get a simpler tree with fewer tags. Even more, for the component tags, only those attributes that need special treatment will be considered separately. The rest are merged into a single portion of text.
Because all the information is translated into java code, at runtime there will be no need to gather this information again and again at each page rendering or maybe to store it somewhere to make available when it’s needed. The generated code will contain all the information on rendering, page workflow, validation and other aspects. I believe that is somehow an implementation of Aspect Oriented Programming paradigm where various aspects of the application are compiled, merged together into a single structure that constitutes the application.
Another important aspect is that of the generated URL’s. Other frameworks need to store information in their generated URL’s in order to be able to make decisions on runtime. In the case of the wedge URL’s this does not happens because much the information exists in the generated code. The amount of information stored in the URL is minimized to only few regular request parameters. In most cases there will be just one parameter, denoting the target page or the triggered event id . This is a very elegant way of avoiding ugly URL’s that would be hard to understand and formed from a non-wedge page. This way you can easily have portion of an application written in wedge and others in other frameworks.
At runtime, when an error occurs, you will get a stack trace that will show exactly the problem’s cause and nature. In case the code that generated the problem is your code or is closely connected with it will be able to localize the problem very fast because you have access the generated code. For example, the assessors of certain properties are not used somewhere inside the framework but rather in the generated code and you have access to this code. In the same time, the generated code is something that you get rapidly get used with. Its structure is pretty simple and quite well documented although is generated!