MyFaces CODI
  1. MyFaces CODI
  2. EXTCDI-175

introduce @ViewParam annotation for page beans

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      When using the ViewConfig in CODI we not only get type safe navigation but also know the 'connection' between views and their backing beans. We already support annotations like @PreRenderView and likes for such beans.

      We should also support the direct annotation of view parameters directly in the backing beans.

      instead of declaring the view parameters in the xhtml:

      <f:metadata>
      <f:viewParam id="versionParam" name="version" value="#

      {backingbean.versionString}

      " required="false"/>
      <f:viewParam id="searchString" name="s" value="#

      {backingbean.searchString}

      " required="false"/>
      </f:metadata>

      we can maybe use an annotation directly in the backing bean:

      @Named
      @RequestScoped
      public class Backingbean {
      @ViewParam(required=false, name="version")
      private String versionString;

      @ViewParam(required=false, name="s")
      private String searchString;

      @PreRenderView
      private void dosomeinit()

      { ... }

      }

        Activity

        Hide
        Gerhard Petracek added a comment -

        that's more or less our original @RequestParameter idea.

        'name' could be optional -> the name of the field is auto. the view-param.-name

        we have to come up with a nice approach for converters. imo we will need custom meta-annotations which provide information for the converter.

        e.g.

        @RequestParam
        @CustomDateConverter(pattern = "dd.MM.yyyy")
        private Date date;

        @Target(

        {TYPE, METHOD}

        )
        @Retention(RUNTIME)
        @Documented

        @CodiFacesConverter(CustomDateConverterImpl.class)
        public @interface CustomDateConverter

        { String pattern(); }

        we don't need such an annotation for validators - we can use bv (if present)

        Show
        Gerhard Petracek added a comment - that's more or less our original @RequestParameter idea. 'name' could be optional -> the name of the field is auto. the view-param.-name we have to come up with a nice approach for converters. imo we will need custom meta-annotations which provide information for the converter. e.g. @RequestParam @CustomDateConverter(pattern = "dd.MM.yyyy") private Date date; @Target( {TYPE, METHOD} ) @Retention(RUNTIME) @Documented @CodiFacesConverter(CustomDateConverterImpl.class) public @interface CustomDateConverter { String pattern(); } we don't need such an annotation for validators - we can use bv (if present)
        Hide
        Gerhard Petracek added a comment -

        since it's annotation based, we have to provide the following approaches
        #1 @RequestParam for view-controllers - manual injection before @InitView -> for errors we might need e.g. an additional context which provides more details than FacesContext#isValidationFailed
        later we can think about:
        #2 @Inject has to be used if it should be used outside of a view-controller -> lazy injection outside of the corresponding lifecycle-phase -> might be too complex

        Show
        Gerhard Petracek added a comment - since it's annotation based, we have to provide the following approaches #1 @RequestParam for view-controllers - manual injection before @InitView -> for errors we might need e.g. an additional context which provides more details than FacesContext#isValidationFailed later we can think about: #2 @Inject has to be used if it should be used outside of a view-controller -> lazy injection outside of the corresponding lifecycle-phase -> might be too complex
        Hide
        Gerhard Petracek added a comment -

        the only direct approach which works without problems is:
        using a request scoped bean and only strings. esp. the restriction to request-scoped beans might be a problem for users who aren't aware of it or in case of refactorings (because the behaviour wouldn't be expected in a cdi app). furthermore, the impl. of such simple cases is very simple (we can include a description in the wiki)

        that means: with a producer method with the return-type string, we would produce a dependent bean -> injection in beans with longer scopes than request scope won't work correctly/as expected.

        with view-controllers it works (already prototyped) in combination with annotated setter methods. for fields it's possible to add an interceptor dynamically which can do the injection. but therefore we would have to inject the values for every method call or a marker method would be needed. since we would also need something like a RequestParameterContext to query if there was an error in case of converting to a different type than a string or a validation violation, we could specify a method which has to be implemented. but in the end that's also not that nice. (or the RequestParameterContext could be used for requestParameterContext.update(this) to update the values in beans with scopes longer than the request scope. however, that isn't nice as well)

        -> a part of it works without problems, but requires annotated setters and the real goal - manual (without producers to support custom types) field injection - won't work without a workaround.

        an alternative:

        like javax.enterprise.inject.Instance we could provide:

        @Inject
        private RequestParameter<MyCustomType> param1;

        in this case every use-case (mentioned above) would work and we don't need an additional context, because we could implement everything as a part of RequestParameter.

        e.g.:
        RequestParameter#isValid
        RequestParameter#get //converted value
        RequestParameter#getSubmittedValue //not converted
        RequestParameter#getConstraintViolations
        RequestParameter#getConversionError
        ...

        Show
        Gerhard Petracek added a comment - the only direct approach which works without problems is: using a request scoped bean and only strings. esp. the restriction to request-scoped beans might be a problem for users who aren't aware of it or in case of refactorings (because the behaviour wouldn't be expected in a cdi app). furthermore, the impl. of such simple cases is very simple (we can include a description in the wiki) that means: with a producer method with the return-type string, we would produce a dependent bean -> injection in beans with longer scopes than request scope won't work correctly/as expected. with view-controllers it works (already prototyped) in combination with annotated setter methods. for fields it's possible to add an interceptor dynamically which can do the injection. but therefore we would have to inject the values for every method call or a marker method would be needed. since we would also need something like a RequestParameterContext to query if there was an error in case of converting to a different type than a string or a validation violation, we could specify a method which has to be implemented. but in the end that's also not that nice. (or the RequestParameterContext could be used for requestParameterContext.update(this) to update the values in beans with scopes longer than the request scope. however, that isn't nice as well) -> a part of it works without problems, but requires annotated setters and the real goal - manual (without producers to support custom types) field injection - won't work without a workaround. an alternative: like javax.enterprise.inject.Instance we could provide: @Inject private RequestParameter<MyCustomType> param1; in this case every use-case (mentioned above) would work and we don't need an additional context, because we could implement everything as a part of RequestParameter. e.g.: RequestParameter#isValid RequestParameter#get //converted value RequestParameter#getSubmittedValue //not converted RequestParameter#getConstraintViolations RequestParameter#getConversionError ...
        Hide
        Gerhard Petracek added a comment -

        +1 for the approach of @Inject private RequestParameter<MyCustomType> param1;

        Show
        Gerhard Petracek added a comment - +1 for the approach of @Inject private RequestParameter<MyCustomType> param1;

          People

          • Assignee:
            Unassigned
            Reporter:
            Mark Struberg
          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development