On 16 févr. 2010, at 09:58, Max Rydahl Andersen wrote:
>
> ----- "Emmanuel Bernard" <emman...@hibernate.org> wrote:
>
>> I don't see i18n as something that should necessarily be packaged
>> inside a component. Resource keys are generally grouped in one or two
>> files for the overall application (so that fixing a typo is quick).
>
> You must be developing small or monolith applications then ;)
>
> The common way I know of (from eclipse apps) is that the resource bundles
> *specific* to that module/plugin is stored in the module and if there are
> some common phrases/messages they are simply put into separate module/plugin
> or you simply depend on that module/plugin you want to share that common
> phrase
> with.
>
Do you have some docs on how Eclipse handles it?
What's a module? a UI-less element whereas a plugin has a UI?
>> If
>> you have to dig into individual or even third party components, it
>> becomes a pain point. So I don't see that as encapsulation violation
>> (or at this stage, you have to consider that displaying the error
>> message to the user is violating encapsulation).
>
> Not following this, additional resource bundles is/should be possible to add
> translations
> to 3rd party components without changing it.
>
> -max
>
>
>>
>> You would put the @ResourceBundle on the constraint annotation? I
>> don't like the idea, it would encourage the creation of a myriad of
>> different resource bundle files. Also today the spec allows to inject
>> your own ResourceBundle implementation via the MessageInterpolator
>> (will even be better in Hibernate Validator after HV-238). Adding a
>> @ResourceBundle will clash with this freedom.
>>
>> Another point I want to mention, Hibernate Validator 3.x had support
>> for a more sophisticated RB approach but it turned out to be a big
>> ball of inconsistency and holes and I purposely simplified the model
>> in Bean Validation.
>>
>> On 15 févr. 2010, at 21:36, Hardy Ferentschik wrote:
>>
>>> Hi,
>>>
>>> Having multiple resource bundles and some custom way of specifying
>> these bundles is
>>> related to HV-238 and HV-251.
>>>
>>> Having a ResourceBundleLocatorStrategy should solve your problem
>> Gunnar, right?
>>>
>>> The default strategy could behave like it does now and we can
>> provide an additional strategy
>>> which allows for multiple resource bundles. You would specify the
>> strategy in the hibernate
>>> config file. The names for the different resource files could also
>> be specified in the
>>> config (or maybe there is a better way!?)
>>>
>>> --Hardy
>>>
>>>
>>> On Mon, 15 Feb 2010 16:51:13 -0300, Gunnar Morling
>> <gunnar.morl...@googlemail.com> wrote:
>>>
>>>> I agree, there probably won't be that many 3rd-party constraint
>> vendors :-)
>>>>
>>>> Nevertheless I think the problem is not too exotic. In my day job
>> for
>>>> example we're building a large-scale enterprise application, which
>> is made
>>>> up of multiple JARs ("components") developed by multiple,
>> independent
>>>> development teams.
>>>>
>>>> Now it would be great, if two teams could develop independently
>> their custom
>>>> constraints, specific to their component. As of now they would have
>> to
>>>> provide a unified ValidationMessages.properties, violating the
>> encapsulation
>>>> of the components.
>>>>
>>>> A rather simple solution might be a meta-annotation @MessageBundle,
>> which
>>>> optionally could be used at constraint annotation type declarations
>> to
>>>> specify the name of the message bundle to be used. That way name
>> collisions
>>>> between constraints from different JARs still could occur, but
>> finding
>>>> unique names should not be too hard. If that meta-annotation is not
>> given, a
>>>> fallback to ValidationMessages.properties might be used.
>>>>
>>>> WDYT?
>>>>
>>>> Cheers, Gunnar
>>>>
>>>>
>>>> 2010/2/15 Emmanuel Bernard <emman...@hibernate.org>
>>>>
>>>>> Yes, you need to copy it over or more likely adapt the messages to
>> your
>>>>> application (in which case you don't care).
>>>>> The problem with listing the resource bundle is that you need an
>> order to
>>>>> specify which has precedence over which.
>>>>>
>>>>> Another solution could be some sort of plugin system where 3rd
>> party
>>>>> constraint makers can reference automatically a resource bundle.
>> But
>>>>> realistically, how many 3rd party constraint makers will there
>> be?
>>>>>
>>>>> The question is: is the additional complexity for the solution
>> worth the
>>>>> current problem?
>>>>>
>>>>> On 14 févr. 2010, at 22:00, Gunnar Morling wrote:
>>>>>
>>>>>> Hello you two,
>>>>>>
>>>>>> recently I thought about the following situation:
>>>>>>
>>>>>> * I have a JAR containing a custom constraint on the class path
>> (could be
>>>>> a constraint provided by some 3rd-party constraint vendor)
>>>>>> * I have another custom constraint within the actual project
>> itself (and
>>>>> therefore a ValidationMessages.properties as well)
>>>>>>
>>>>>> Now the ValidationMessages.properties provided by the 3rd-party
>> vendor is
>>>>> hidden by my own ValidationMessages.properties, which - if I'm not
>> mistaken
>>>>> - requires me to copy the contents of the first to the latter.
>>>>>>
>>>>>> Is there any better solution to this problem?
>>>>>>
>>>>>> Maybe BV/HV should provide some means for constraint vendors to
>> specify
>>>>> the resource bundle containing messages? If you think, that's
>> useful I'd
>>>>> create a JIRA issue for that one.
>>>>>>
>>>>>> Thanks for any ideas,
>>>>>>
>>>>>> Gunnar
>>>>>
>>>>>
>>>
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> --
> /max
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
