[
https://issues.apache.org/jira/browse/EXTCDI-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104122#comment-13104122
]
Gerhard Petracek commented on EXTCDI-175:
-----------------------------------------
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
...
> introduce @ViewParam annotation for page beans
> ----------------------------------------------
>
> Key: EXTCDI-175
> URL: https://issues.apache.org/jira/browse/EXTCDI-175
> Project: MyFaces CODI
> Issue Type: New Feature
> Reporter: Mark Struberg
>
> 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() {
> ...
> }
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
