Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.1-EDR
    • Fix Version/s: 2.1
    • Component/s: EL
    • Labels:
      None
    • Environment:

      Operating System: ALL
      Platform: ALL

    • Issuezilla Id:
      147

      Description

      Posted by Stephen Colebourne on this thread:
      http://www.theserverside.com/news/thread.tss?thread_id=33990#171185

      Joda-Time provides great interoperability methods called toDate() and
      toGregorianCalendar() which are designed to be used in cases like this (and
      which follow the Sun naming conventions for methods of this type). However, EL
      (and thus JSP/JSF) can't use these methods because of the spec writers 'holier
      than thou' attitide against method calls.

      Thus, instead of:<br />
      <fmt:formatDate value="$

      {myBean.startDate.toDate()}

      "/><br />

      I have to do:
      <% MyBean bean = (MyBean)pageContext.findAttribute("myBean");
      java.util.Date startDate = bean.getStartDate().toDate();
      pageContext.setAttribute("startDate", startDate);
      %>
      <fmt:formatDate value="$

      {startDate}

      "/>

      The good news is that another alternative is to write my own ELResolver. The bad
      news is that I have to code it, maintain it, make it available from the
      Joda-Time website, teach people to use it and thats its 'non-standard'. (Code
      and effort that will probably be dupilcated by many people across many projects)

      So, are you still convinced that You're right and all of us developers need to
      be constrained?


      Posted by Colin Sampaleanu on this thread:
      http://www.theserverside.com/news/thread.tss?thread_id=33990#171263

      I have to agree with Stephen here. Every single time I've had to write a
      serious app using JSPs and JSTL, I've cursed the inability in JSTL to call more
      than basic getter methods and access collection elements, to get at part of my
      doomain object graph that is being exposed to the view as model data. This is
      not about the view being able to modify data, but simply about being able to
      access that data. Consider the simple example of a variant of a 'getter' method
      that needs to take one or two 'qualifiers' or key values. A typical domain
      object graph will have a decent number of access mechanism for objects in the
      graph that are not expressed as simple JavaBean getter methods or collection access.

      So over and over again I find myself in the situation where my service layer has
      passed up what should be a perfectly usable object graph to my view layer, and
      then I have to morph that to another object hierarchy or or stuff it in some
      collections, etc., just so my JSTL code can access it.

      On the other hand, I've used and seen used OGNL in Tapestry apps, with full
      access to the methods of objects being exposed to the view, with no ill effects,
      and a lot less hassles and unneeded code.

      To me, this is a sign of a fundamentally bad assumption on the part of the spec
      team, that people using the expression language can not be trusted, so their
      access should be limited. The onus of trust should instead be placed on what
      object graph is exposed to the view template technology (i.e. limit that object
      graph), and then letting the view template technology fully access that object
      graph.

        Activity

        Hide
        kchung added a comment -

        This was fixed in JSP 2.1

        Show
        kchung added a comment - This was fixed in JSP 2.1

          People

          • Assignee:
            pierre
            Reporter:
            pierre
          • Votes:
            5 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: