Tapestry
  1. Tapestry
  2. TAPESTRY-994

component types unnecessary for annotations

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 4.0.2
    • Fix Version/s: 4.1.1
    • Component/s: Annotations
    • Labels:
      None

      Description

      Why do I have to type @Component(type = "TextField") when the return type of the abstract method below it is TextField? Can't this be inferred?

        Activity

        Hide
        Brian Ross added a comment -

        I agree. We don't need to be that smart about this. The default if no type annotation is specified is the return type of the method. If there is a special case where this is not correct, then the type annotation will need to be specified in order to handle it. It is no worse for the special cases than the current behavior and is better for the typical case.

        Show
        Brian Ross added a comment - I agree. We don't need to be that smart about this. The default if no type annotation is specified is the return type of the method. If there is a special case where this is not correct, then the type annotation will need to be specified in order to handle it. It is no worse for the special cases than the current behavior and is better for the typical case.
        Hide
        Andreas Andreou added a comment -

        I don't think there's a list of the components of the framework or the included libraries
        anywhere at the time this enhancement worker processes the annotation.
        So, complete component guessing is out of the question anyway...
        We're simply talking about having a nice default here - not a complete
        discovery service...

        Show
        Andreas Andreou added a comment - I don't think there's a list of the components of the framework or the included libraries anywhere at the time this enhancement worker processes the annotation. So, complete component guessing is out of the question anyway... We're simply talking about having a nice default here - not a complete discovery service...
        Hide
        Norbert Sándor added a comment -

        I think that handling the name of the method's return type as component type may be misleading...

        Show
        Norbert Sándor added a comment - I think that handling the name of the method's return type as component type may be misleading...
        Hide
        Norbert Sándor added a comment -

        If the type parameter is missing then the framework can iterate through all components of the given namespace.

        • if there is exactly 1 component with the given Java class then it should be used
        • otherwise an exc. should be thrown

        I'm not sure if this feature worth the effort...

        Show
        Norbert Sándor added a comment - If the type parameter is missing then the framework can iterate through all components of the given namespace. if there is exactly 1 component with the given Java class then it should be used otherwise an exc. should be thrown I'm not sure if this feature worth the effort...
        Hide
        Andreas Andreou added a comment -

        I don't see any special handling...
        If type is left blank, the framework fills it with method.returnType.simpleName
        An exception would have been thrown anyway...

        Show
        Andreas Andreou added a comment - I don't see any special handling... If type is left blank, the framework fills it with method.returnType.simpleName An exception would have been thrown anyway...
        Hide
        Andreas Andreou added a comment -

        The type parameter of Component annotation is in fact necessary in some cases,
        i.e. when the component name is different that the component classname (@If and class IfBean)
        or when the component is part of a library (and thus needs a prefix)

        However, i too believe that if type is left blank the framework should try to fill in the details...

        Show
        Andreas Andreou added a comment - The type parameter of Component annotation is in fact necessary in some cases, i.e. when the component name is different that the component classname (@If and class IfBean) or when the component is part of a library (and thus needs a prefix) However, i too believe that if type is left blank the framework should try to fill in the details...
        Hide
        Norbert Sándor added a comment -

        I think it will not be appropriate because of how component libraries work: two components in two separate libraries can easily share the same Java class.

        It may work in some cases (for example in case of framework components) but it would introduce the special handling of those components...

        Show
        Norbert Sándor added a comment - I think it will not be appropriate because of how component libraries work: two components in two separate libraries can easily share the same Java class. It may work in some cases (for example in case of framework components) but it would introduce the special handling of those components...
        Hide
        Jesse Kuhnert added a comment -

        Sounds reasonable to me.

        Show
        Jesse Kuhnert added a comment - Sounds reasonable to me.

          People

          • Assignee:
            Andreas Andreou
            Reporter:
            Brian Ross
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development