DisplayTag
  1. DisplayTag
  2. DISPL-143

Table does not use decorators when providing implicit objects

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.0 RC2
    • Fix Version/s: 1.0 RC2
    • Component/s: Decorators
    • Labels:
      None
    • Application server:
      Tomcat 5.5

      Description

      When doing something along the lines of:

      <display table id="row" name="mylist" decorator="bar.FooDecorator>
        <display:column title="name" >
          <c:out value="${row.name}"/>
        </display:column>
      </display:table>

      then the implicit 'row'-object used in the JSTL tag is not the FooDecorator instance but the object from the list.

        Activity

        Hide
        fabrizio giustina added a comment -
        Table decorators are not esposed in column body.
        If you use the "property" attribute the tag look for the bean property both in the original object and in the decorator, but this can't be done in column body, since displaytag directly esposes the original bean.

        So, if you have a bean with a "name" property and a decorator with a "decoratedName" property there is no way to expose an object which will allow both:
        bean.getName()
        decorator.getDecoratedName()

        Anyway, if you use a table decorator there is no reason to also use the column body instead of the (faster) property attribute.
        Show
        fabrizio giustina added a comment - Table decorators are not esposed in column body. If you use the "property" attribute the tag look for the bean property both in the original object and in the decorator, but this can't be done in column body, since displaytag directly esposes the original bean. So, if you have a bean with a "name" property and a decorator with a "decoratedName" property there is no way to expose an object which will allow both: bean.getName() decorator.getDecoratedName() Anyway, if you use a table decorator there is no reason to also use the column body instead of the (faster) property attribute.
        Hide
        Thomas Dudziak added a comment -
        The problem is that there are reasons to use the column body instead of coding it into the decorator. Take for example the famous link example.
        Now if I want to create a struts link for the column using a forward (<html:link forward="...>) where a property of the decorator (e.g. "name" which is not present in the original bean) is required, then I cannot easily do this in the decorator. However if the decorator is exposed then this is rather easy in the column body:

        <jsp:useBean name="props" class="java.util.HashMap"/>
        <!-- Init link parameter map with common parameters: -->
        ...

        <display table id="row" name="mylist" decorator="bar.FooDecorator>
          <display:column title="name" >
            <!-- Add current name to the link parameters -->
            <c:set target="props" property="name" value="${row.name}"/>
            <html:link forward="/showFoo" name="props"/>
          </display:column>
        </display:table>
        Show
        Thomas Dudziak added a comment - The problem is that there are reasons to use the column body instead of coding it into the decorator. Take for example the famous link example. Now if I want to create a struts link for the column using a forward (<html:link forward="...>) where a property of the decorator (e.g. "name" which is not present in the original bean) is required, then I cannot easily do this in the decorator. However if the decorator is exposed then this is rather easy in the column body: <jsp:useBean name="props" class="java.util.HashMap"/> <!-- Init link parameter map with common parameters: --> ... <display table id="row" name="mylist" decorator="bar.FooDecorator>   <display:column title="name" >     <!-- Add current name to the link parameters -->     <c:set target="props" property="name" value="${row.name}"/>     <html:link forward="/showFoo" name="props"/>   </display:column> </display:table>

          People

          • Reporter:
            Thomas Dudziak
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: