Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade BeanNameViewResolver to support XML and Java Config bean definitions [SPR-14022] #18594

Closed
spring-projects-issues opened this issue Mar 5, 2016 · 1 comment
Labels
in: web status: declined type: enhancement

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Mar 5, 2016

Paul Chapman opened SPR-14022 and commented

Currently the BeanNameViewResolver supports finding beans by name from the same ApplicationContext that it is defined in. This can lead to lots of View beans in the context that only the BeanNameViewResolver needs to know about. It also means that a given view name can only be resolved to a single View bean. If I have a PDF generating bean and an Excel generating bean I can't use this approach.

The XmlViewResolver solves this problem by allowing the View beans to be specified in a dedicated bean XML file, just for the View beans, reducing bean-clutter. By having two such resolvers I can have two view Beans with the same name. But, as the name implies, this resolver only supports beans defined using XML.

I propose enhancing the BeanNameViewResolver to optionally support both beans defined in XML files and/or in dedicated Java Configurations. This enhancement would make the XmlViewResolver obsolete.

I anticipate something like this:

@Configuration {

    @Bean ViewResolver bnvr() {
        return new BeanNameViewResolver(ExcelViewBeans.class, PdfViewBeans.class);
    }
}

I would expect BeanNameViewResolver to provide both constructors and setLocation() methods that take an array of Resource (for XML bean files) or an array of @Configuration classes.

The default behaviour of the BeanNameViewResolver can remain the same to ensure backwards compatibility.

The ViewResolverRegistry should be enhanced similarly to provide beanName(Resource ...) and beanName(Class<?>...).

And the equivalent change to <mvc:resolvers>.


Reference URL: #987

@spring-projects-issues spring-projects-issues added type: enhancement in: web labels Jan 11, 2019
@rstoyanchev
Copy link
Contributor

@rstoyanchev rstoyanchev commented Nov 19, 2021

XmlViewResolver has been deprecated in 5.3 and I'm not sure it makes sense to enhance BeanNameViewResolver with this functionality. Between view resolver implementations that match to the request path and those that use serialize to non-HTML content types like JSON, I'd expect the number view beans to be manageable with the current functionality of BeanNameViewResolver.

@rstoyanchev rstoyanchev added the status: declined label Nov 19, 2021
@rstoyanchev rstoyanchev removed this from the General Backlog milestone Nov 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web status: declined type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants