I recently attended the Rich Web Applications course given by Spring Source, and I was surprised that the technology stack employed in the course was "equivalent" to what I used 8 years ago!
It's equivalent in the sense that:
It's equivalent in the sense that:
- Struts 1.2 was then the framework for implementing the Front Controller pattern
- Tiles with JSPs and JSTL was the view mechanism
The course used Spring MVC which is the MODERN equivalent of Struts. Spring MVC is much more powerful but the functionality it provides is about the same as Struts.
The element that really surprised me was the fact that Tiles was the proposed mechanism for the view layer. I personally find Tiles to be powerful but given the elapsed time, I was expecting something new to replace it.
Why Tiles may not be so appropriate these days?
- It relies on JSPs which are not trivial to test outside a web container.
- The tiles XML where definitions go, is very similar to a Spring beans file. Nowadays you could expect a namespace for tiles within a spring config, rather than a standalone XML.
- Tiles require a mini framework on top to be effective. For instance if your tile requires some java script to be downloaded in the HTML head section, you need to put in place something yourself to deal with this situation, unlike the @Require instruction in the google sitebricks project .
- No clear separation between HTML design and scripting. See paper on the necessity of separation between view and model.
These days where where we are supposed to produce a decent UI (i.e. possibility of auto-complete, selecting a date on a calendar, affecting the default value of another calendar on the same form) in a quick way, Tiles will not be the answer. I will be looking around at what is available.
Comments
Post a Comment