Why aren't multiple Converters allowed on a single value holder?
up vote
3
down vote
favorite
This morning I had reason to try using multiple Converters on an inputText component and realized that this doesn't work.
Does anyone who why JSF only allows a single Converter per ValueHolder? It seems that using a series of Converters would be elegant in several situations.
jsf jsf-2 converter
add a comment |
up vote
3
down vote
favorite
This morning I had reason to try using multiple Converters on an inputText component and realized that this doesn't work.
Does anyone who why JSF only allows a single Converter per ValueHolder? It seems that using a series of Converters would be elegant in several situations.
jsf jsf-2 converter
1
Actually, I see the issue -- I was thinking of a chain of converters where values were manipulated but not Type converted. If converter1 changes the type then converter2 isn't dealing with a String any longer and thus chaining wouldn't work.
– Dave Maple
Jul 12 '11 at 16:35
add a comment |
up vote
3
down vote
favorite
up vote
3
down vote
favorite
This morning I had reason to try using multiple Converters on an inputText component and realized that this doesn't work.
Does anyone who why JSF only allows a single Converter per ValueHolder? It seems that using a series of Converters would be elegant in several situations.
jsf jsf-2 converter
This morning I had reason to try using multiple Converters on an inputText component and realized that this doesn't work.
Does anyone who why JSF only allows a single Converter per ValueHolder? It seems that using a series of Converters would be elegant in several situations.
jsf jsf-2 converter
jsf jsf-2 converter
asked Jul 12 '11 at 16:07
Dave Maple
4,41212554
4,41212554
1
Actually, I see the issue -- I was thinking of a chain of converters where values were manipulated but not Type converted. If converter1 changes the type then converter2 isn't dealing with a String any longer and thus chaining wouldn't work.
– Dave Maple
Jul 12 '11 at 16:35
add a comment |
1
Actually, I see the issue -- I was thinking of a chain of converters where values were manipulated but not Type converted. If converter1 changes the type then converter2 isn't dealing with a String any longer and thus chaining wouldn't work.
– Dave Maple
Jul 12 '11 at 16:35
1
1
Actually, I see the issue -- I was thinking of a chain of converters where values were manipulated but not Type converted. If converter1 changes the type then converter2 isn't dealing with a String any longer and thus chaining wouldn't work.
– Dave Maple
Jul 12 '11 at 16:35
Actually, I see the issue -- I was thinking of a chain of converters where values were manipulated but not Type converted. If converter1 changes the type then converter2 isn't dealing with a String any longer and thus chaining wouldn't work.
– Dave Maple
Jul 12 '11 at 16:35
add a comment |
1 Answer
1
active
oldest
votes
up vote
11
down vote
accepted
In JSF, the Converter
interface is designed with the following sole purpose:
Converter is an interface describing a Java class that can perform Object-to-String and String-to-Object conversions between model data objects and a String representation of those objects that is suitable for rendering.
...
getAsObject
Convert the specified string value, which is associated with the specifiedUIComponent
, into a model data object that is appropriate for being stored during the Apply Request Values phase of the request processing lifecycle.
getAsString
Convert the specified model object value, which is associated with the specifiedUIComponent
, into a String that is suitable for being included in the response generated during the Render Response phase of the request processing lifeycle.
Neither the javadoc nor the JSF spec tells about the possibility to chain converters.
Your best bet is to solve this problem at the implementation level. If you want to extend an existing converter, then you should just do so and then call super
methods whenever appropriate. E.g.
public class SomeExtendedConverter extends SomeBasicConverter {
@Override
public Object getAsObject(FacesContext context, UIComponent component, String value) {
Object basicConvertedValue = super.getAsObject(context, component, value);
// ... manipulate more ...
return extendedConvertedValue;
}
// ...
}
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
11
down vote
accepted
In JSF, the Converter
interface is designed with the following sole purpose:
Converter is an interface describing a Java class that can perform Object-to-String and String-to-Object conversions between model data objects and a String representation of those objects that is suitable for rendering.
...
getAsObject
Convert the specified string value, which is associated with the specifiedUIComponent
, into a model data object that is appropriate for being stored during the Apply Request Values phase of the request processing lifecycle.
getAsString
Convert the specified model object value, which is associated with the specifiedUIComponent
, into a String that is suitable for being included in the response generated during the Render Response phase of the request processing lifeycle.
Neither the javadoc nor the JSF spec tells about the possibility to chain converters.
Your best bet is to solve this problem at the implementation level. If you want to extend an existing converter, then you should just do so and then call super
methods whenever appropriate. E.g.
public class SomeExtendedConverter extends SomeBasicConverter {
@Override
public Object getAsObject(FacesContext context, UIComponent component, String value) {
Object basicConvertedValue = super.getAsObject(context, component, value);
// ... manipulate more ...
return extendedConvertedValue;
}
// ...
}
add a comment |
up vote
11
down vote
accepted
In JSF, the Converter
interface is designed with the following sole purpose:
Converter is an interface describing a Java class that can perform Object-to-String and String-to-Object conversions between model data objects and a String representation of those objects that is suitable for rendering.
...
getAsObject
Convert the specified string value, which is associated with the specifiedUIComponent
, into a model data object that is appropriate for being stored during the Apply Request Values phase of the request processing lifecycle.
getAsString
Convert the specified model object value, which is associated with the specifiedUIComponent
, into a String that is suitable for being included in the response generated during the Render Response phase of the request processing lifeycle.
Neither the javadoc nor the JSF spec tells about the possibility to chain converters.
Your best bet is to solve this problem at the implementation level. If you want to extend an existing converter, then you should just do so and then call super
methods whenever appropriate. E.g.
public class SomeExtendedConverter extends SomeBasicConverter {
@Override
public Object getAsObject(FacesContext context, UIComponent component, String value) {
Object basicConvertedValue = super.getAsObject(context, component, value);
// ... manipulate more ...
return extendedConvertedValue;
}
// ...
}
add a comment |
up vote
11
down vote
accepted
up vote
11
down vote
accepted
In JSF, the Converter
interface is designed with the following sole purpose:
Converter is an interface describing a Java class that can perform Object-to-String and String-to-Object conversions between model data objects and a String representation of those objects that is suitable for rendering.
...
getAsObject
Convert the specified string value, which is associated with the specifiedUIComponent
, into a model data object that is appropriate for being stored during the Apply Request Values phase of the request processing lifecycle.
getAsString
Convert the specified model object value, which is associated with the specifiedUIComponent
, into a String that is suitable for being included in the response generated during the Render Response phase of the request processing lifeycle.
Neither the javadoc nor the JSF spec tells about the possibility to chain converters.
Your best bet is to solve this problem at the implementation level. If you want to extend an existing converter, then you should just do so and then call super
methods whenever appropriate. E.g.
public class SomeExtendedConverter extends SomeBasicConverter {
@Override
public Object getAsObject(FacesContext context, UIComponent component, String value) {
Object basicConvertedValue = super.getAsObject(context, component, value);
// ... manipulate more ...
return extendedConvertedValue;
}
// ...
}
In JSF, the Converter
interface is designed with the following sole purpose:
Converter is an interface describing a Java class that can perform Object-to-String and String-to-Object conversions between model data objects and a String representation of those objects that is suitable for rendering.
...
getAsObject
Convert the specified string value, which is associated with the specifiedUIComponent
, into a model data object that is appropriate for being stored during the Apply Request Values phase of the request processing lifecycle.
getAsString
Convert the specified model object value, which is associated with the specifiedUIComponent
, into a String that is suitable for being included in the response generated during the Render Response phase of the request processing lifeycle.
Neither the javadoc nor the JSF spec tells about the possibility to chain converters.
Your best bet is to solve this problem at the implementation level. If you want to extend an existing converter, then you should just do so and then call super
methods whenever appropriate. E.g.
public class SomeExtendedConverter extends SomeBasicConverter {
@Override
public Object getAsObject(FacesContext context, UIComponent component, String value) {
Object basicConvertedValue = super.getAsObject(context, component, value);
// ... manipulate more ...
return extendedConvertedValue;
}
// ...
}
answered Jul 12 '11 at 20:37
BalusC
837k29531043186
837k29531043186
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f6667394%2fwhy-arent-multiple-converters-allowed-on-a-single-value-holder%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Actually, I see the issue -- I was thinking of a chain of converters where values were manipulated but not Type converted. If converter1 changes the type then converter2 isn't dealing with a String any longer and thus chaining wouldn't work.
– Dave Maple
Jul 12 '11 at 16:35