1:21 a.m.
Hi Gerhard,
I thin I've not yet totally understood what you have in mind.
Maybe you could create a proposal for BVAL-217 describing things more in
detail (interaction between resolver and interpolator, integration with BV
1.0 interpolators etc.)?
I also think using resource bundles is not totally optional as there is the
ValidationMessages bundle.
--Gunnar
Am 25.06.2012 18:49 schrieb "Gerhard Petracek"
<gerhard.petracek(a)gmail.com>:
1:35 p.m.
New subject: MessageResolver vs ResourceBundleLocator
On Jun 26, 2012, at 8:21 AM, Gunnar Morling wrote:
I thin I've not yet totally understood what you have in mind.
AFAIU Gerhard proposes a more general interface which is independent from ResourceBundles.
Underneath you still can use them, in fact you would have to for
ValidationMessages.properties. We would have to to define the MessageResolver interface
and then also define that the default implementation of this interface
resolves against ValidationMessages.properties. Even with the ResourceBundleLocator
interface you need to somehow specify that a default implementation exists
which uses ValidationMessages.properties. Is this what you have in mind Gerhard?
Maybe you could create a proposal for BVAL-217 describing things more
in detail (interaction between resolver and interpolator, integration with BV 1.0
interpolators etc.)?
+1 That would be the best.
I also think using resource bundles is not totally optional as there
is the ValidationMessages bundle.
Right. For that reason using ResourceBundleLocator still feels a little more
"natural" to me.
--Hardy
6:46 a.m.
New subject: MessageResolver vs ResourceBundleLocator
hi hardy,
thx for moving it to an own thread!
a copy of my last answer:
...
it's just about:
- an interface which directly allows simple but still flexible custom
implementations of (custom) message-sources (including a simple delegation
to a ResourceBundle) - see [1].
vs.
- an interface which is restricted to ResourceBundle. -> if it isn't
possible to use ListResourceBundle or PropertyResourceBundle, users have to
implement #getKeys which might not be possible (/ that easy) for some
advanced use-cases.
the rest is more or less the same - if the MessageInterpolator receives a
key, it uses the new interface for the lookup (if there is no custom
implementation of the new interface or no result for the given key, the
existing default bundle (ValidationMessages) is used as a fallback).
regards,
gerhard
[1]
https://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/core/...
2012/6/26 Hardy Ferentschik <hardy(a)hibernate.org>
On Jun 26, 2012, at 8:21 AM, Gunnar Morling wrote:
> I thin I've not yet totally understood what you have in mind.
AFAIU Gerhard proposes a more general interface which is independent from
ResourceBundles. Underneath you still can use them, in fact you would have
to for
ValidationMessages.properties. We would have to to define the
MessageResolver interface and then also define that the default
implementation of this interface
resolves against ValidationMessages.properties. Even with the
ResourceBundleLocator interface you need to somehow specify that a default
implementation exists
which uses ValidationMessages.properties. Is this what you have in mind
Gerhard?
> Maybe you could create a proposal for BVAL-217 describing things more in
detail (interaction between resolver and interpolator, integration with BV
1.0 interpolators etc.)?
+1 That would be the best.
> I also think using resource bundles is not totally optional as there is
the ValidationMessages bundle.
Right. For that reason using ResourceBundleLocator still feels a little
more "natural" to me.
--Hardy
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
6:32 a.m.
New subject: Bean Validation 1.1 early draft 1 is out
hi gunnar,
since it isn't a complicated topic, we can write a proposal as soon as we
have a basic agreement about the approach.
imo it's pretty easy - it's just about:
- an interface which directly allows simple but still flexible custom
implementations of (custom) message-sources (including a simple delegation
to a ResourceBundle).
vs.
- an interface which is restricted to ResourceBundle. -> if it isn't
possible to use ListResourceBundle or PropertyResourceBundle, users have to
implement #getKeys which might not be possible (/ that easy) for some
advanced use-cases.
the rest is more or less the same - if the MessageInterpolator receives a
key, it uses the new interface for the lookup (if there is no custom
implementation of the new interface or no result for the given key, the
existing default bundle (ValidationMessages) is used as a fallback).
regards,
gerhard
2012/6/26 Gunnar Morling <gunnar(a)hibernate.org>
Hi Gerhard,
I thin I've not yet totally understood what you have in mind.
Maybe you could create a proposal for BVAL-217 describing things more in
detail (interaction between resolver and interpolator, integration with BV
1.0 interpolators etc.)?
I also think using resource bundles is not totally optional as there is
the ValidationMessages bundle.
--Gunnar
Am 25.06.2012 18:49 schrieb "Gerhard Petracek" <gerhard.petracek(a)gmail.com
>:
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
4529
days inactive
4533
days old
beanvalidation-dev@lists.jboss.org
3 comments
3 participants
participants (3)
-
Gerhard Petracek -
Gunnar Morling -
Hardy Ferentschik