Tapestry
  1. Tapestry
  2. TAPESTRY-1682

Parameters with defined with a default-value counted as "invariant"

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.1.2
    • Fix Version/s: 4.1.3
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      Even though I found this problem with Dialog component it seems to affect any similar component parameter, that is an optional component parameters with a constant default value, take as an example Dialog:

      <parameter name="hidden" default-value="true" />

      Unless the optional parameter is configured with a ognl method binding the parameter itself is somehow regarded as "Invariant" by ExpressionBinding class that will throw a ReadOnlyBindingException when trying to use a setter on it. In particular, for Dialog component this mean to fail everytime the component is show()/hide() as setHidden has to be called to set the actual status for the component.

      There seems to be some kind of confusion between the component parameter method and the binding method/default value here when creating the binding. In my opinion a "default-value" should be just a default value if the parameter is configured/initialized but this shouldn't prevent to use setters and getters on the parameter after the component is created. And this is the same thing that thought the creator of Dialog component I think

      The way to repeat this is very simple: just use the Dialog component anywhere without using the hidden parameter and using hide() or show() at some time.

        Activity

        Hide
        Martino Piccinato added a comment -

        I, this ticket was closed as as "fixed" but I can't find where and how it was fixed (or if it was just an invalid ticket)
        Also for some strange reason a comment I had attached was removed:

        A possible solution to this problem might be to replace in ExpressionBinding

        public void setObject(Object value)
        {
        initialize();

        if (_invariant)
        throw createReadOnlyBindingException(this);
        ...

        with

        public void setObject(Object value)
        {
        initialize();

        if (_invariant)
        return;

        Actually I don't understand at all the advantage of throwing here a BindingException if the binding is invariant.

        The other solution would be to change the behaviour of ParameterPropertyWorker for parameters without bindings or the behaviour of EstablishDefaultParameterValuesVisitor to work on component parameter property instead of creating an expression binding. All in all I don't understand why it creates a binding for a parameter that does not have any, the correct behaviour would be to set to "true" by default the parameter property.

        Show
        Martino Piccinato added a comment - I, this ticket was closed as as "fixed" but I can't find where and how it was fixed (or if it was just an invalid ticket) Also for some strange reason a comment I had attached was removed: A possible solution to this problem might be to replace in ExpressionBinding public void setObject(Object value) { initialize(); if (_invariant) throw createReadOnlyBindingException(this); ... with public void setObject(Object value) { initialize(); if (_invariant) return; Actually I don't understand at all the advantage of throwing here a BindingException if the binding is invariant. The other solution would be to change the behaviour of ParameterPropertyWorker for parameters without bindings or the behaviour of EstablishDefaultParameterValuesVisitor to work on component parameter property instead of creating an expression binding. All in all I don't understand why it creates a binding for a parameter that does not have any, the correct behaviour would be to set to "true" by default the parameter property.

          People

          • Assignee:
            Unassigned
            Reporter:
            Martino Piccinato
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development