8 Replies Latest reply: Oct 19, 2011 3:19 AM by gimbal2 RSS

    Alternative to JSP templates

    892936
      [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
        • 1. Re: Alternative to JSP templates
          892997
          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?
          • 2. Re: Alternative to JSP templates
            892936
            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.
            • 3. Re: Alternative to JSP templates
              892997
              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.
              • 4. Re: Alternative to JSP templates
                892936
                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.
                • 5. Re: Alternative to JSP templates
                  892997
                  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.
                  • 6. Re: Alternative to JSP templates
                    892936
                    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!
                    • 7. Re: Alternative to JSP templates
                      892997
                      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.
                      • 8. Re: Alternative to JSP templates
                        gimbal2
                        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.