GeoServer
  1. GeoServer
  2. GEOS-1393

Templates do break when an attribute contains a boolean value

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.3, 1.6.0-beta3
    • Fix Version/s: 1.6.0-beta4
    • Component/s: WMS
    • Labels:
      None
    • Number of attachments :
      0

      Activity

      Hide
      Gabriel Roldan added a comment - - edited

      to summarize from the above indicated email thread and what I've found on the code:

      • If in a template <td>$ {attribute.value}</td> is used, and value is boolean, the following exception is thrown:
        freemarker.core.NonStringException: Error on line 19, column 3 in description.ftl
        Expecting a string, date or number here, Expression a.value is instead a freemarker.ext.beans.BooleanModel
        - quote: "..Unlike numbers, booleans has no commonly accepted format, not even a
        common format within the same page. Like when you show on a HTML page.."
        "...The common way of formatting a boolean is like ${washable?string("yes", "no")},
        ${caching?string("Enabled", "Disabled")}, ${heating?string("on", "off")}, etc..."
        - By the other hand, the Features used in the unit test for FeatureTemplate contained no boolean properties. Adding a boolean property to the test data still didn't make the error to show up, as the template used uses <td>${attribute.value.toString()}</td>. Changing the template to use <td>${attribute.value}

        </td> exposes the error.

      • FeatureWrapper, the freemarker BeansWrapper used for Feature, builds a map of <Attribute Name, Object value>, but wraps java.util.Date to String using a formatter. Other value object types get untouched.
      Show
      Gabriel Roldan added a comment - - edited to summarize from the above indicated email thread and what I've found on the code: If in a template <td>$ {attribute.value}</td> is used, and value is boolean, the following exception is thrown: freemarker.core.NonStringException: Error on line 19, column 3 in description.ftl Expecting a string, date or number here, Expression a.value is instead a freemarker.ext.beans.BooleanModel - quote: "..Unlike numbers, booleans has no commonly accepted format, not even a common format within the same page. Like when you show on a HTML page.." "...The common way of formatting a boolean is like ${washable?string("yes", "no")}, ${caching?string("Enabled", "Disabled")}, ${heating?string("on", "off")}, etc..." - By the other hand, the Features used in the unit test for FeatureTemplate contained no boolean properties. Adding a boolean property to the test data still didn't make the error to show up, as the template used uses <td>${attribute.value.toString()}</td>. Changing the template to use <td>${attribute.value} </td> exposes the error. FeatureWrapper, the freemarker BeansWrapper used for Feature, builds a map of <Attribute Name, Object value>, but wraps java.util.Date to String using a formatter. Other value object types get untouched.
      Hide
      Gabriel Roldan added a comment -

      all in all, given that freemarker only knows how to properly present Strings and Numbers, I wonder if using <td>$

      {attribute.value?string}

      </td> or any other formatting strategy/workaround is not such a common need that whomever uses freemarker has to deal with that.
      If so, do we really need to care about wrapping booleans as strings so one can simply use <td>$

      {attribute.value}

      </td> ?

      • pros: easy for users to handle booleans (they'll get "true" or "false")
      • cons: do they loose the ability of doing $ {attribute.value?string("Enabled", "Disabled")}
      Show
      Gabriel Roldan added a comment - all in all, given that freemarker only knows how to properly present Strings and Numbers, I wonder if using <td>$ {attribute.value?string} </td> or any other formatting strategy/workaround is not such a common need that whomever uses freemarker has to deal with that. If so, do we really need to care about wrapping booleans as strings so one can simply use <td>$ {attribute.value} </td> ? pros: easy for users to handle booleans (they'll get "true" or "false") cons: do they loose the ability of doing $ {attribute.value?string("Enabled", "Disabled")}
      Hide
      Gabriel Roldan added a comment -

      When asked Andrea if this behaviour is actually a bug or a feature,.. he didn't need to answer as he had a nice idea: to keep around both the original attribute value and a default string representation, so users can choose between, say,

      {attribute.value}

      and

      {attribute.rawValue}

      Waiting for comments from Justin...

      Show
      Gabriel Roldan added a comment - When asked Andrea if this behaviour is actually a bug or a feature,.. he didn't need to answer as he had a nice idea: to keep around both the original attribute value and a default string representation, so users can choose between, say, {attribute.value} and {attribute.rawValue} Waiting for comments from Justin...
      Hide
      Gabriel Roldan added a comment -
      Show
      Gabriel Roldan added a comment - Fixed for 1.5.x and 1.6.x, and accordingly updated the documentation for http://docs.codehaus.org/display/GEOSDOC/GetFeatureInfo+templates and http://docs.codehaus.org/display/GEOSDOC/01-Placemark+Templates

        People

        • Assignee:
          Gabriel Roldan
          Reporter:
          Andrea Aime
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved: