Tapestry
  1. Tapestry
  2. TAPESTRY-1598

Tapestry should not require explicit value encoders (via the encoder parameter) where it can automatically coerce the value between string and the appropriate server-side type

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 5.0.5
    • Fix Version/s: 5.0.8
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      (This could be considered an enhancement except that it worked in a previous snapshot.)

      Summary says it all but here's a simple example:

      html:
      <select t:type="select" t:value="someIntegerProperty" t:model="selectModelList"></select>

      java:
      public List getSelectModelList() // note list is currently broken as per TAPESTRY-1597

      { List<Integer> model = new ArrayList<Integer>(); model.add(new Integer(1)); model.add(new Integer(2)); return model; }

      Now results in the following exception:
      org.apache.tapestry.ioc.internal.util.TapestryException
      No adapter from type java.lang.Integer to type org.apache.tapestry.services.ValueEncoderFactory is available (registered types are java.lang.Enum, java.lang.String).

      Defining ValueEncoders for all the simple wrapper types used in domain objects defeats the purpose of all the smart type conversion Tapestry does elsewhere.

      Cheers,
      Nick.

        Activity

        Nick Westgate created issue -
        Nick Westgate made changes -
        Field Original Value New Value
        Component/s tapestry-ioc [ 12311284 ]
        Howard M. Lewis Ship made changes -
        Assignee Howard M. Lewis Ship [ hlship ]
        Howard M. Lewis Ship made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Howard M. Lewis Ship made changes -
        Summary Trivial SelectModels (e.g. Lists of Integer objects) now require a ValueEncoder whereas before they "just worked". Tapestry should not require explicit value encoders (via the encoder parameter) where it can automatically coerce the value between string and the appropriate server-side type
        Hide
        Howard M. Lewis Ship added a comment -

        Ah the joys of TypeCoercer. If you have a type that does not have a natural coercion to and from string (for example, a database entity type) you will see ugly strings on the client and failure when the form is submitted.

        Show
        Howard M. Lewis Ship added a comment - Ah the joys of TypeCoercer. If you have a type that does not have a natural coercion to and from string (for example, a database entity type) you will see ugly strings on the client and failure when the form is submitted.
        Hide
        Howard M. Lewis Ship added a comment -

        FYI: I added a test case based on your example ... and you can use int[] rather than List<Integer> if you so wish (it's often easier). More joys of TypeCoercer.

        Show
        Howard M. Lewis Ship added a comment - FYI: I added a test case based on your example ... and you can use int[] rather than List<Integer> if you so wish (it's often easier). More joys of TypeCoercer.
        Howard M. Lewis Ship made changes -
        Resolution Fixed [ 1 ]
        Status In Progress [ 3 ] Closed [ 6 ]
        Fix Version/s 5.0.8 [ 12312898 ]
        Mark Thomas made changes -
        Workflow jira [ 12406984 ] Default workflow, editable Closed status [ 12567639 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12567639 ] jira [ 12591968 ]

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Nick Westgate
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development