The unification makes sense. But how would intentional overriding (as is
usual for messages) versus unintentional collisions be handled? Conventions
or some kind of extra scoping?
Cheers,
Nick.
Howard Lewis Ship wrote:
I don't see this as a problem, message catalog and symbols are very closely
tied together.
An interesting possibility would be for each component to have its own
symbol source, derived from a related file, that tied into the global
SymbolSource ... but that looks *exactly* (well almost, leave out
localization) the same as having the messages catalog chain up to the symbol
source.
So go ahead!
On 10/19/07, Dan Adams <[EMAIL PROTECTED]> wrote:
So right now I have a situation where I need my library to provided some
default values for some things it provides. The natural place for this
seems to be FactoryDefaults. The problem is that certain things are only
looked up in the component messages when determining defaults and it
doesn't appear that symbols and included when searching for messages
(ComponentMessageSourceImpl uses an AssetFactory and the application
properties file). So the question is:
Is it appropriate to have the global SymbolSource included when looking
for component messages? Perhaps after the assets and application
properties file?
Some background on the issue:
I'm adding a validator that takes an optional constraint. Rather than
changing Validator to support this I just want to include a blank
default constraint value for the validator in the library that
contributes it. But I know this issue of looking up defaults is going to
come up for other components.
--
Dan Adams
Senior Software Engineer
Interactive Factory
617.235.5857
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
