jsp-spec-public
  1. jsp-spec-public
  2. JSP_SPEC_PUBLIC-159

MethodExpression should explicitly support a java method call

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • 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:
      158

      Description

      Going in the same direction as
      https://jsp-spec-public.dev.java.net/issues/show_bug.cgi?id=147 ), we should be
      able to use a method as valid EL and write :

      #

      {OrderManagerControler.delete(order.identifier)}

      In this case, the resolution has to be done first on row.identifier expression
      as per the context content to find the type of the parameter.
      Those types will then be used to call the factory and get the right
      MethodExpression.

      But as we are in deferred mode, the "test.activate" call will be still deffered
      when "needed", but we need the exact value now (for variable saving purposes),
      hence the row.identifier has to be immediatly evaluated and its value "stored"
      for the deferred call.

      Assuming we are on the first row (row with identifier property value = 1 ), the
      expression will be the same as :

      #{OrderManagerControler.delete(1)}

      Major benefit is that you can then call any method on any class !

      Example of direct major improvement to JSF for instance of this is that instead
      of passing parameters to actions as "hack parameters" :

      <h:dataTable id="interventions" styleClass="liste"
      value="#{OrderManagerControler.interventions}" var="order">
      ...
      <h:column>
      <f:facet name="header">Commands</f:facet>
      <input id="send" jsfc="h:commandButton" type="submit" value="Delete"
      action="#{OrderManagerControler.delete}" />
      <f:param name="orderId" value="#{order.identifier}"/>
      </h:commandLink>

      <h:outputText value="#{intervention.slotBegin}"/>
      </h:column>


      </h:dataTable>

      Having a "fake" delete() method calling an helper to get from the facet context
      a parameter named "orderId".


      We could just write :

      <h:dataTable id="interventions" styleClass="liste"
      value="#{OrderManagerControler.interventions}" var="order">
      ...
      <h:column>
      <f:facet name="header">Commands</f:facet>
      <input id="send" jsfc="h:commandButton" type="submit" value="Delete"
      action="#{OrderManagerControler.delete(order.identifier)}

      " />
      <f:param name="order" value="#

      {order.identifier}

      "/>
      </h:commandLink>

      <h:outputText value="#

      {intervention.slotBegin}

      "/>
      </h:column>

      </h:dataTable>

      And then only need the class OrderManagerControler got a simple method
      delete(long orderIdentifier) that will perform the expected task on the element !

      Grammar for this "MethodInvocation" expected is the same kind of grammar already
      found for "FunctionInvocation", so no major changes are expected to the EL
      grammar but introduction to the same existing mechanism on the method invocation.

      Example of impact on Collected Synthax §1.18 (ValueSuffix updated and
      introducted MethodInvocation) :
      ValueSuffix ::= ‘.’ Identifier | ‘[‘ Expression ‘]’ | MethodInvocation
      MethodInvocation::=(Identifier ‘:’)? Identifier ‘(‘ ( Expression ( ‘,’
      Expression )* )? ‘)’

        Activity

        Hide
        jluehe added a comment -

        Assigning to Kin-Man.

        Show
        jluehe added a comment - Assigning to Kin-Man.
        Hide
        kchung added a comment -

        This issue is beyond the scope of the current spec, so it is not a bug but a
        request for enchancement.

        Show
        kchung added a comment - This issue is beyond the scope of the current spec, so it is not a bug but a request for enchancement.
        Hide
        kchung added a comment -

        EL 2.2 supports general method invocations with arguments.

        Show
        kchung added a comment - EL 2.2 supports general method invocations with arguments.

          People

          • Assignee:
            kchung
            Reporter:
            bjb
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: