Alternative to JSP templates

Question

[This is a cross post. I posted the same thing over at the coderanch: http://www.coderanch.com/t/554956/JSP/java/Alternative-JSP-templates]
Hey,
I've built and worked on quite a number of web applications using JSP for HTML templates.
I always found that the templates would get quite messy and confusing even if you use JSTL instead of scriptlets.
In a few projects I used other libraries for the HTML templates, Velocity for example.
Though, that's just the same in a slightly different syntax. I've also worked with numerous other technologies in Ruby land,
but I'm not happy with them either.
To come to the point of this post: I don't like it very much and so I've created an alternative: Wandledi
To describe it shortly: Instead of including scriptlets or custom tags into HTML files Wandledi uses a separate layer that's only responsible
for transforming HTML markup in order to fill it with dynamic data and so on.
For further information please have a look at http://wandledi.org *.
The idea isn't entirely new, though I don't know any other library that implements it in this way and not only for Java,
but for Scala, too.
The reason I post this here is that I was hoping to get some feedback from Java (and possibly Scala) developers on the whole thing.
Do you find the idea totally ludicrous or do you think it could make sense?
I for one am actually using Wandledi in several projects and I like it very much.
However, I might be a little biased. ;)
Regards,
Markus
* For an actual Java example see: http://wandledi.org/spells/duplication.html
Edited by: user5480329 on 06.10.2011 12:25
Edited by: user5480329 on 06.10.2011 13:33

Answer 1

First off: Thank you for your input.
Please let me point out that Wandledi is in no way a web framework. It is a rather small library merely 'living in the presentation layer'.
889994 wrote:
+"The HTML markup stays clean and can even be edited with HTML editors such as Dreamweaver without getting confused.+" - This kind of argument is pretty widespread. Both ways. If there is some existing text editor for a given format they say - you may use editor XXX. If the format is too new they will tell - you do NOT need any special editor and sell that as an advantage. As of me I call that a "tools oriented approach" - as if starting a brand new technology we should first of all take a decision which editors it will comply to.
In reality developing a technology as a whole (really new ideas included) costs non less than 50 times more than any editor. Editors must follow technology, not vice verse.I agree. This point I added because I thought of it as a little bonus.
It's not something I had considered in the design of Wandledi. I use redcar for everything anyway! ;o
889994 wrote:
HTML files can be changed directly and the view is updated without recompilation. No compilation or runtime errors as a result of changes to templates - they may tell this. If is not a case they may tell something about how it is reliable when everything is compiled in advance.
My 15 years of contact to JSP pages tells me that all end-up with including compilation of JSP as a step of a build. Otherwise you have a convenience of extra redeployments to production.Well, in the end the only thing that brings relative security are integration tests, I suppose.
Cucumber to the rescue.
Still the point of making recompilation unnessary is pretty valuable for development,
because it makes it way quicker if you only make changes to the markup, which happens rather often
when you're trying to circumvent another IE6 bug. ;)
889994 wrote:
"By putting the transformation logic into plain classes you can use the full power of the language (Java, Scala, ...) to describe the view transformations.
This includes inheritance, composition and polymorphism to build up larger, more complex transformations OOP-style." - I have strong doubts that transformation logic is something needed for presentation. What about "the markup is also easier to read for humans, too."? - once you hide all under Java-coded transformations.This is a valid point. You can do all sorts of mischief with those transformations. But that's possible with any technology and it lies in the responsibility
of the developer to be reasonable about it. It's important to point out that you usally do not want to generate HTML with Wandledi (referring to your print("<html>") statement). You merely transform. That is add, remove or change HTML attributes or duplicate portions of markup that is already there.
One of the motivations behind Wandledi is that you should be able to express conditions and loops in an actual programming language instead of a cumcersome surrogate language or tags. The framework you suggested also makes this possible, which is good.
To bring an example of Wandledi for loops.
When you usally would do something like this:
JSP:
&lt;ul class="users"&gt;
  &lt;% for (String user : users) { %&gt;
    &lt;li&gt;&lt;%= user.name %&gt;&lt;/li&gt;
  &lt;% } %&gt;
&lt;/ul&gt;I find this very ugly. The use of EL only improves the situation mildly.
With Wandledi this would look like this:
HTML:
&lt;ul class="users"&gt;
  &lt;li&gt;Hans&lt;/li&gt;
&lt;/ul&gt;
Scala:get("ul.users li").foreachIn(users)( (li, user) => li.text = user.name )What I hope is that already in this small example the markup is more comfortable to read without the obfuscation through JSP. It is to me.
Also it isn't more code, less even in this example. Just put into another file.
Of course this would be less consise in Java. You would need about 5 lines of Java to express the same thing.
889994 wrote:
"The web designer can start building a functioning HTML page locally first without needing a server. Also they don't need to know jack about Java, JSP, JSTL, etc.." I agree. But. That may be said about ANY technology, including the JSP itself.That's not entirely true. What I mean is that the web designer can actually build the page locally and view it in his browser, simply by opening the file he is working on. Of course that is no longer possible once you start building stuff by including other files and so on.
But you can build the components and simply view them in the browser. You can build concrete instances.
Just as I did in the example above by inserting "Hans" instead of some variable name.
You can show the page to anyone with a browser, no fragments. But mock content which will later get replaced with actual content.
889994 wrote:
One big piece missing in your proposal is about components and code reuse in general. That's the thing. It isn't. Because it is already there. You just do it the same way you would do it with your normal Java code.
Because it is normal Java code.