Ajax frameworks
From Giews
Contents |
[edit] News
See latest email of Erik regarding Ajax Frameworks.
[edit] Argumentation
A framework is needed to prevent a lot of low level nasty work which lower down the speed of development. Of course it has to be said that all Ajax frameworks at the moment are immature, strongly under development and therefore quite unpredictable.
The first distinction is high level and low level frameworks. High level frameworks like jsf and gwt are hiding the developer from javascript and the servlet api. Low level frameworks like Dojo and Rico are javascript based and will call do gets and do posts directly on the server. High level frameworks in general are preferred for development speed but can be immature for the advanced UI functions needed.
[edit] Options
- Java server faces JSF is a component framework and is a high level framework. See the jsf matrix for the components available (http://www.jsfmatrix.net/).
- Dojo Salvatore is using Dojo for the HTML prototype.
- DWR Can be used in combination with Dojo. Programming is done in Java and DWR exposes the functions build in Java as JavaScript functions in the client. Spring has good integration with DWR. DWR is well supported by Tibco. Bram Smeets is a developer for both Spring and DWR.
- Rico used by OpenLayers (very basic framework).
Subsequent options for JSF
[edit] Criteria
- Sustainability and usability (consistency of the development community, supporters, maturity of the framework and opinion of the users)
- Performance
- Learning curve (level of difficulty in implementing the application using the framework)
- Completeness (to evaluate how much the framework meets our needs in terms of tools, functionalities, etc.)
- Compatibility with other frameworks (establish whether it might enter in conflict with other frameworks that we could use)
[edit] Decision
For Map related functions OpenLayer has to be used. For the other part of the application DOJO/DWR will be used. In addition SpringWebFlow might be used to organise MVC on the server behind DWR.
[edit] Argumentation
OpenLayers is known very well by Lorenzo and Andrea. OpenLayers is missing good functions functions for the Layer Manager GIEWS needs. Lorenzo has recently been accepted as OpenLayers developer and will add the layer function to OpenLayer.
JSF is mature but not yet for the Ajax part. We may migrate to JSF in the future. At the moment every JSF is passing every browser event to the server. JSF is stressing the server more and that's a disadvantage for the developing countries which tend to do not have fast servers.
| Criteria | Criterum weight | jsf-ajax | dojo/dwr | ||
| performance | 10 | 6 | 9 | 60 | 90 |
| development speed | 7 | 8 | 5 | 56 | 35 |
| ajax functionality | 10 | 6 | 10 | 60 | 100 |
| ide tooling | 5 | 7 | 4 | 35 | 20 |
| java compliance | 4 | 10 | 6 | 40 | 24 |
| future robustness | 8 | 8 | 7 | 64 | 56 |
| maturity | 8 | 6 | 9 | 48 | 72 |
| maintainability | 6 | 10 | 5 | 60 | 30 |
| Score | 61 | 55 | 423 | 427 |
We used the above spreadsheet to rationalize the decision. Missing is learning curve, browser load and server load, which the meeting made decide for Dojo/DWR.
[edit] Lorenzo
I've put a lot of emphasis on the risk to use javascript frameworks but this doesn't mean we cannot start using them and then rewrite needed functions during final refining as many other projects do.
Risks I see:
- In the past has been often documented collision between different JS frameworks as Prototype and Dojo (maybe...).
- javaDoc is not always supported in this frameworks and their syntax can conflict with javaDoc application that's so important when we'll need to publish the API.
- ... maybe others
