Blogs: To have or not have a template language

  1. To have or not have a template language (5 messages)

    Richard McMahon's blog, posted in response to a comparison of Rails and Django, questions the actual value of taglibs over scriptlets.
    For the longest time I've been questioning the value of the whole JSP taglib malarky we have in the J2EE world. I wonder what percentage of Java web apps actually involve these mythical designers who are repulsed by scriptlet markup, but will feel at home weaving their graphical magic around. We've been conditioned (very effectively I might add) to believe that scriptlet usage should be punishable by death. I agree with DHH above - it's not that scriptlet use is bad, it's when it becomes business logic that things become a problem.
    McMahon argues for sticking with scriptlets because scriptlets more effectively manage code, and the extra metadata and packaging surrounding a taglib hurts "immediacy and agility," which McMahon says "encourages laziness," which can lead to repetition. McMahon also applauds Rails' tendency toward using Ruby syntax where possible, along with the "helper" modules it ships with. What do you think - Django or Rails? Taglibs or scriptlets?
  2. In the past I liked the idea to abbandone scriptlet code from JSPs in favour of custom tags. But recently I used velocity templates for a generator project and I found it very easy to distinguish between the template and the template control code (scriptles/macros). You can quickly navigate through your template and clearly find the template control logic. I don't like business logic here either. Just the if/then/elses and iterators to control the templates flow. That should be fairly simple. In JSPs with custom tags you only see tags within tags within tags. What's your HTML/XML output and what's your template control code? It's hard to see.
  3. Taglibs do have their place[ Go to top ]

    In a project I'm working on currently, I have a tag library that creates UI components, one example being a sortable table that follows the Swing pattern of a TableModel/TableCellRenderer/etc. The custom tag defines everything, with easy to read markup, but then the tag handler class uses a Velocity template to generate the HTML. This way you've got (1) the custom tag which doesn't clutter up the page, but also (2) the Velocity template where you can better control what is being generated.
  4. jsp 2.0[ Go to top ]

    with the easy .tag files, you can dump your scriptlets into a file and suddenly have the whole thing behave much cleaner. a front end language shouldn't ever implement the business language, but taglibs PLUS scriptlets are an extremely powerful way to develop web applications. they are not well-exploited by the java community at large who continue to chase "best practices" into enterprise vendor specification hell.
  5. Taglibs is a reaction to some of thousands of JSP we have all seen containing not maintainable code with several hundreds of lines of scriptlet mixed with html tags, or worse generating also some tags. In scriptlet, we must apply many do-not-do-that rules to ensure maintainability. Or use a proper framework. In the trainings we can see that many bad practices are taken by beginners with scriplets. Using taglibs, they concentrate on there tag implementation understanding better the modularity. But both solutions need more tools and a better support by the language. A template language replacing taglibs, and not allowing any scriplets, would remove the current "mix up all" situations.
  6. Templating: Your going to have a template language somewhere. You just migh use Java directly. Scriplets: JSPs with a bunch of if/else scriplets are hard to maintain. Plus JSPs limit your business logic usage to JSP only requests. I don't use scriplets in Customer Modified JSPs. It will make fixing it for them a pain when they mess it up. Although, I do use scriptlets for my own pages, but it's always temporary code for working out a future custom tags. Conclusion: Scriplets are needed, but they are ugly and temporary place holders. My Methodology: My Issue with PHP/JSP/ASP lack of cheap validation. So I ended up using XSLT I generate my JSP/PHPs with XSL. Here is my flow: Request->*(Build Data Model->Generate View)->Return View = Generated JSP->*XSLT or PHP