Forum Stats

  • 3,815,605 Users
  • 2,259,059 Discussions
  • 7,893,185 Comments

Discussions

Alternative to JSP templates

892936
892936 Member Posts: 5
edited Oct 19, 2011 4:19AM in JavaServer Pages (JSP) and JSTL
[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
Tagged:

Comments

  • 892997
    892997 Member Posts: 5
    The world needs an alternative to JSP and from time to time gets one. Recently JSF has dropped JSP as obsolete and has replaced it with Facelets. There are better alternatives to JSP than Facelets but that is their choice and they will get all the profit appropreate for such a choice.

    We need not just "an alternative to JSP" but the one that may suggest some better solutions to the week points of JSP. May you explain in which sences your technology is better than JSP?
  • 892936
    892936 Member Posts: 5
    Thanks for your reply.

    As opposed to JSP you don't obfuscate your HTML markup with scriptlets or foreign tags to include dynamic data or display
    different portions of it depending on certain conditions.
    Instead you create the HTML file first, writing pure HTML. No foreign fragments whatsoever.

    Additionally to your HTML file you then may create an accompanying class containg instructions as to how transform that HTML.
    This is similar to XSLT. Though everything is expressed Java.

    I consider this better for the following reasons:

    - The HTML markup stays clean and can even be edited with HTML editors such as Dreamweaver without getting confused.
    The latest version of it actually supports JSP I think. But nontheless the markup is also easier to read for humans, too.

    - 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
    possible.

    - 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.

    - 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..
    They can use mock data and examples in the page, which are easily replaced by Wandledi, to create concrete, working instances.
    The real data can be inserted later.

    Wandledi is in fact not only an alternative to JSP, but an alternative approach to the whole MVC template business as it is commonly done.
  • 892997
    892997 Member Posts: 5
    edited Oct 7, 2011 10:04PM
    There were tons of discussions I read on this Java Web Frameworks who's better issue. So maybe I have already some opinions for some of the points that I may tell upfront. To comment on others I may need time to think.

    +"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.

    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.

    +"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.

    There are technologies that use only code like "print("<html">)"; but that is what the word went way from long ago towards using markup languages. So there is some contradiction here in your points above and the attempt to resolve exactly this contradiction was a kind of engine of progress in frameworks for the last decade.

    +"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.

    One big piece missing in your proposal is about components and code reuse in general.

    I suggest you have a look at the Java Web Framework I like - http://www.hybridserverpages.com/ . IMHO that one gives the best alternative to JSP. Better than JSF/Facelets for sure.
  • 892936
    892936 Member Posts: 5
    edited Oct 8, 2011 4:43AM
    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;
    &nbsp;&nbsp;&lt;% for (String user : users) { %&gt;
    &nbsp;&nbsp;&nbsp;&nbsp;&lt;li&gt;&lt;%= user.name %&gt;&lt;/li&gt;
    &nbsp;&nbsp;&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;
    &nbsp;&nbsp;&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.
  • 892997
    892997 Member Posts: 5
    machisuji wrote:
    I agree. This point I added because I thought of it as a little bonus.
    Yes, it is.
    Still the point of making recompilation unnessary is pretty valuable for development,
    I bet we've both put it at a wrong angle. What is valuable is making linking and packaging unnecessary after each change of code. Compilation usually takes a small fraction of time and more that that - you have it either way. That is a good though not a critical feature. In fact you may use it only when you do not fix code besides JSP at the same moment.
    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
    That may NOT happen with technology that does not perform "transformations" at all. Not sure if I've ever seen any valid reasons for doing "transformations" at run-time. In particular for those that use XSLT.
    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.
    No need to generate but no need to transform either. The whole idea of mark-up language is about doing none of that. When you put a plain HTML file on your web server all you have is tag <html> in that file. HybridJava in fact generalizes the mark-up approach.
    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.
    Your example splits the information into two files. You may like it, but for me that is a whole bunch of additional implicit cross-references between those files. Besides that you can not put your get("ul.users li").foreachIn ... in the air, you will most probably have to create an instance of Java class not always a necessary instance.

    Though I do not like Wicket I feel that you approach is close to theirs.
    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.
    Please read what is written about VB approach versus mar-up approach on HybridJava site. If you limit yourself with "normal Java code" then of course you have classes and thus you may think you are OK regarding components. If your technology includes (as yours does and thus, by the way, it is already not about a "normal Java code") additional information in a markup form the question arises immediately - what is an adequate definition of a component that embraces that information and apparently that definition is something different than a plain OOP paradigm of Java.
  • 892936
    892936 Member Posts: 5
    You're right. There are cross-references between markup and transformation logic.
    I don't see a problem with that. Others might disagree.

    I agree with you on the composition part, too. You have markup in addition to your plain classes.
    So the composition question in this setup might require a little more work down the road.

    Wicket seems to be similar indeed. I should take a look at that.
    Maybe I can learn something from them that I could apply to Wandledi.

    You don't seem to like the whole direction.
    I'm not particularly fond of the HybridJava approach either.
    But that's ok. Diversity is good, so there's something for everyone.

    Thanks for your input!
  • 892997
    892997 Member Posts: 5
    machisuji wrote:
    I agree with you on the composition part, too. You have markup in addition to your plain classes.
    So the composition question in this setup might require a little more work down the road.
    Oops! Here you got VERY close to the point. BUT at this exactly point comes the difference. "My markup" is NOT an addition to plain classes. On the contrary, plain classes sometimes come as an addition to markup.

    Exactly it means that to add a component to a page you do exactly as much work as you do if you want to add a &lt;p> ... &lt;/p> or any other HTML tag. You put it into markup - and that is it! That establishes the parent-child relation. In Wicket (and I recall in Tapestry and Click too) you have to repeat the relation in the Java code and possibly in an XML file too. That approach by the way creates too many quite unnecessary Java instances, in particular those for buttons, loops and (god knows what for) events. All because they all inherit from the VB/SWING ideology (and openly confirm that).
    Wicket seems to be similar indeed. I should take a look at that.
    Maybe I can learn something from them that I could apply to Wandledi.
    Am afraid that way you will come to a direct copy of Wicket 8-). Here is my article of 2009 comparing Wicket and HybridJava, maybe you'll find it helpful. I would fix some places now, but anyway: http://www.theserverside.com/news/thread.tss?thread_id=54866
    You don't seem to like the whole direction.
    I would not tell that. I do not see HybridJava as a different direction than Wicket etc. Just some details designed a bit more clear.
    I'm not particularly fond of the HybridJava approach either.
    I hate computers in general. That is a necessary precondition to make them work.
  • gimbal2
    gimbal2 Member Posts: 11,949 Gold Trophy
    889994 wrote:
    I hate computers in general. That is a necessary precondition to make them work.
    Hmm, not really a healthy attitude. When you hate something you will be more inclined to blame it unreasonably. But you ain't going to get anywhere until you realize the problem is usually between the keyboard and the chair.
This discussion has been closed.