In order to create such framework, we set our mind and efforts to certain vision, which indeed needs defining mission to accomplish. We give ourselves the time to think and visualize the purpose and the main characteristic of this framework, then we defined our mission bounded by the ideas were set when we first started this framework.
Jspx Live Demo »
Although the main slogan Java technology is announcing is the portability of the developed code to run on various platforms, some of the java products themselves failed to run everywhere and by EverywhereI mean every application server. Let's be more accurate, some of these products required a lot of efforts to deploy on various application servers. A simple example on this is JSF. When you develop web application with JSF and you want to deploy it on JBoss application server, it is required to put the two jars of the faces implementation in the server lib directory. I remember that migrating from JBoss 4.0.5 to 4.2.0 caused us a headache to figure out the problem with JSF implementation library. We can consider Oracle ADF as another example, where the products runs perfectly on OC4J you can see you best nightmares putting it to run on JBoss. Away from web tier, we all know the compatibility issue when deploying EJB JPA project build for JBoss to run on OC4J. All this in mind we decided to make JSPX really portable. We had to make the code very thin, requires lees number of third party jars and can be understood by every application server. So far we employed JSPX on projects that run on both OC4J and JBoss. We did not face any problem reading this portability, and we don't except any due to the simplicity and independency nature of the framework.
The main bias of developing such framework is to ease the web development tasks. Hence we grouped all common tasks into the framework. We also started to add some business cases that we used to developed regularly into the framework. Some of these tasks were new like Export to Excel feature. Also some utilities were added like Captcha and validators.
The basic idea about dynamic web application is to deliver dynamic content. This is simply manipulating the HTML interactively to the end user actions. Back into the age of JSP this feature was supported through FOP or structured code, your scripting HTML along with Java code were all merged into one big java method. JSF came to eliminate this wrong way by providing java classes representing each HTML element. In JSPX we provided the same concept through constructing concrete object for each HTML element declared on the jspx file. More over we provided a very important feature which is PassThrough Elements. That is whenever there is a tag that has no corresponding WebControl Class; a generic Implementation is given so that this new unknown tag is still accessible from the java controller.
One statement I read once in a book about OSB (Oracle Service Buss)
There's nothing that the engineers at Oracle can write that you cannot write yourself, given enough time, money, and training.
These words represented the best nature ever exists in a framework. Hence we insisted on putting JSPX in a very simple, clear, easy to maintain, and good way. So that with the minimum efforts you can understand the code behind the scene, and participate in.
Most of our concerns about web layer framework are how easy it is to use. Most of our colleagues crashed into nonsense errors, misleading messages and of course the wired and freaky way to develop using this framework. In JSPX we tried as much as possible to eliminate such thing. We tried to put the framework as we Developers understand. We tried to make its error messages more informative. We expecting the forums messages sent for support will be limited to noticeable little number.
jspx