Tapestry
  1. Tapestry
  2. TAPESTRY-1931

Add an annotation to allow explicit setting of property types

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.0.6
    • Fix Version/s: 5.0.7
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      Currently, there's a fairly simple mapping from Java property type to Tapestry property type ... the latter being a string used to select appropriate components to display the value of a property or edit the value of a property.

      However, type is not always enough. For example, String and Number both map to "text", but a String could also be a long text field (use a <textarea>) or perhaps a rich text field (we will eventually add a rich text editor to Tapestry). Likewise, Date maps to "date" but that doesn't allow for time input, just the date portion.

      How about:

      public class MyBean {
      private String _password;
      private String _note;

      public String getPassword()

      { return _password; }

      @PropertyType("password")
      public void setPassword(String password)

      { _password = password; }

      public String getNote()

      { return _note; }

      @PropertyType("longtext")
      public void setNote(String note)

      { _note = note); }

        Activity

        Hide
        Christian E Gruber added a comment -

        My only concern with this is if it becomes too view-centric within your model classes. however, I think sufficient decoupling is allowed by having a richer set of types than String would normally allow, as you have done here.

        Frankly, as long as the view can treat this as a set of hints by which it can provide sane default views, that's great. And if it can override the display in the view, then even better.

        I do think this will simplify development, however, as I think sane defaults are achievable, and these two types are probably most of what's needed.

        What would be best, though, is if these mechanisms were extensible, so you could contribute new bean types and default renderings.

        Show
        Christian E Gruber added a comment - My only concern with this is if it becomes too view-centric within your model classes. however, I think sufficient decoupling is allowed by having a richer set of types than String would normally allow, as you have done here. Frankly, as long as the view can treat this as a set of hints by which it can provide sane default views, that's great. And if it can override the display in the view, then even better. I do think this will simplify development, however, as I think sane defaults are achievable, and these two types are probably most of what's needed. What would be best, though, is if these mechanisms were extensible, so you could contribute new bean types and default renderings.
        Hide
        Howard M. Lewis Ship added a comment -

        Actually, the mechanisms for (a) analyzing the property to determine its type and (b) providing display and/or edit blocks are both extensible already. I think part of it is even documented. There's a chain of command for analyzing the property, the changes I propose will fit in towards the front of the chain.

        Show
        Howard M. Lewis Ship added a comment - Actually, the mechanisms for (a) analyzing the property to determine its type and (b) providing display and/or edit blocks are both extensible already. I think part of it is even documented. There's a chain of command for analyzing the property, the changes I propose will fit in towards the front of the chain.
        Hide
        Ognen Ivanovski added a comment -

        Tagging something with a property type of 'password' or 'currency' is actually quite something the domain model should be concerned about, its' not that view-centric.

        Tag annotations could also be used here:

        @Password
        public void setPassword(String password)

        { _password = password; }

        Also, please allow third parties to be able to examine the class under investigation and have a say on the property type. Trails does this nicely with enabling you to write rules such as "type is password if property name ends with password".

        Show
        Ognen Ivanovski added a comment - Tagging something with a property type of 'password' or 'currency' is actually quite something the domain model should be concerned about, its' not that view-centric. Tag annotations could also be used here: @Password public void setPassword(String password) { _password = password; } Also, please allow third parties to be able to examine the class under investigation and have a say on the property type. Trails does this nicely with enabling you to write rules such as "type is password if property name ends with password".
        Hide
        Howard M. Lewis Ship added a comment -

        The DataTypeAnalyzer service's configuration supports any number of DataTypeAnalyzer instances, each of which can set the type. So a contribution to the DTA could check for names ending in password, etc.

        Show
        Howard M. Lewis Ship added a comment - The DataTypeAnalyzer service's configuration supports any number of DataTypeAnalyzer instances, each of which can set the type. So a contribution to the DTA could check for names ending in password, etc.
        Hide
        Howard M. Lewis Ship added a comment -

        The annotation name shall be @DataType.

        Show
        Howard M. Lewis Ship added a comment - The annotation name shall be @DataType.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development