Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 5.3.3
    • Fix Version/s: None
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      I am quite unhappy with the naming of the component used for server side comments/annotations attached to a template.
      t:remove seems a bit awkward, albeit it does reflect on what the template engine actually does.
      I would recommend deprecating t:remove and introduce a t:annotation component in its favor.

        Issue Links

          Activity

          Hide
          Bob Harner added a comment -

          The same functionality is available in most if not all template-based web frameworks. Carsten, can you cite any that use "annotation" for this purpose? I like that Tapestry, JSF and Wicket all use the same word.

          I'm marking this issue as "Won't Fix", for the reasons cited. Reopen if you really feel strongly about it.

          Show
          Bob Harner added a comment - The same functionality is available in most if not all template-based web frameworks. Carsten, can you cite any that use "annotation" for this purpose? I like that Tapestry, JSF and Wicket all use the same word. I'm marking this issue as "Won't Fix", for the reasons cited. Reopen if you really feel strongly about it.
          Hide
          Bob Harner added a comment -

          In JSF the equivalent tag is <ui:remove>

          In Wicket it's <wicket:remove>

          In JSP, Struts & Grails it's <%-- ..... --%>

          I'm liking <t:remove> more and more.

          Show
          Bob Harner added a comment - In JSF the equivalent tag is <ui:remove> In Wicket it's <wicket:remove> In JSP, Struts & Grails it's <%-- ..... --%> I'm liking <t:remove> more and more.
          Hide
          Thiago H. de Paula Figueiredo added a comment -

          On Sat, 05 May 2012 23:51:47 -0300, Carsten Klein (JIRA) <jira@apache.org>

          I don't think what you're saying is correct. Since Tapestry 5.2, there's a
          single instance of each page loaded in memory and there's no per-thread
          copy of template of pages nor components, so you're concern is not valid
          AFAIK.


          Thiago H. de Paula Figueiredo
          Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
          and instructor
          Owner, Ars Machina Tecnologia da Informação Ltda.
          http://www.arsmachina.com.br

          Show
          Thiago H. de Paula Figueiredo added a comment - On Sat, 05 May 2012 23:51:47 -0300, Carsten Klein (JIRA) <jira@apache.org> I don't think what you're saying is correct. Since Tapestry 5.2, there's a single instance of each page loaded in memory and there's no per-thread copy of template of pages nor components, so you're concern is not valid AFAIK. – Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br
          Hide
          Robert Zeigler added a comment -

          Your proposed renaming assumes that the only use for <t:remove> is to annotate some piece of the template. Although that is certainly one potential use of <t:remove>, it's not the only use. I'm -1 on a rename to "annotation". It's confusing, overloaded, and less general than "remove". I've never found "remove" unintuitive:

          <t:remove>
          A bunch of stuff to remove from the template
          </t:remove>

          Seems pretty obvious.

          Show
          Robert Zeigler added a comment - Your proposed renaming assumes that the only use for <t:remove> is to annotate some piece of the template. Although that is certainly one potential use of <t:remove>, it's not the only use. I'm -1 on a rename to "annotation". It's confusing, overloaded, and less general than "remove". I've never found "remove" unintuitive: <t:remove> A bunch of stuff to remove from the template </t:remove> Seems pretty obvious.
          Hide
          Carsten Klein added a comment -

          Not an option – cf. SaxTemplateParser which removes the content during template parse.
          The least I wanted to have was an otherwise useless component consuming valuable memory,
          and you know that comments can get rather lengthy. Your approach would keep all of this
          in memory for all templates loaded on a per thread basis...

          Show
          Carsten Klein added a comment - Not an option – cf. SaxTemplateParser which removes the content during template parse. The least I wanted to have was an otherwise useless component consuming valuable memory, and you know that comments can get rather lengthy. Your approach would keep all of this in memory for all templates loaded on a per thread basis...
          Hide
          Bob Harner added a comment -

          The term "annotation" already has a different meaning in the Java world, so although I agree with you that "remove" is a little unintuitive, I think "annotation" might be worse.

          However, if you want to make an "annotation" component of your own, feel free. It would be truly trivial to do:

          package com.mycompany.myapp.components;
          public class Annotation
          {
          boolean setupRender()

          { return false; }

          }

          Show
          Bob Harner added a comment - The term "annotation" already has a different meaning in the Java world, so although I agree with you that "remove" is a little unintuitive, I think "annotation" might be worse. However, if you want to make an "annotation" component of your own, feel free. It would be truly trivial to do: package com.mycompany.myapp.components; public class Annotation { boolean setupRender() { return false; } }

            People

            • Assignee:
              Unassigned
              Reporter:
              Carsten Klein
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development