Skip to content

Combine multiple InputTypeFactories #2177

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

Open
kalgon opened this issue Jul 25, 2024 · 1 comment
Open

Combine multiple InputTypeFactories #2177

kalgon opened this issue Jul 25, 2024 · 1 comment
Assignees

Comments

@kalgon
Copy link

kalgon commented Jul 25, 2024

Currently, only the first InputTypeFactory loaded from spring.factories is loaded.

I would like to provide custom types while keeping the existing ones in place, or combine multiple factories. Therefore, it would be nice to have some sort of CompositeInputTypeFactory which will use all available factories (which can be ordered with the @Order annotation, HtmlInputTypeFactory should have the lowest priority).

@odrotbohm odrotbohm self-assigned this Aug 12, 2024
@odrotbohm odrotbohm added type: new feature in: mediatypes Media type related functionality labels Aug 12, 2024
@odrotbohm
Copy link
Member

That's an interesting suggestion. I guess this might be an edge case, but currently, registering a custom one would disable the default ones completely. As the only indicator whether to proceed consulting further ones is if the getInputType(…) method returns null, I wonder how a delegating approach would allow users to disable the default ones then. I guess it's not a problem if the ones registered collectively handle all types currently handled in the HTML one, but we'd “break” the current overriding behavior.

I wonder if we could resolve this by making the default implementation public, so that whether you want to trigger it can be in the hand of the developer. But I guess this would still carry the (already existing) issue forward, that “use the first implementation found” might depend on the order of libraries on the classpath, which is not ideal either.

Maybe we can introduce a dedicated token unlikely to ever be used as an actual input type string, that can be returned from a custom implementation that aborts the iteration over the delegates. That — while requiring a change to an existing custom implementation that wants the entirely overriding behavior — would at least allow users to return to the previous behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants