Something about mapped configurations doesn't feel right to me with regards to overriding values.
You are not allowed to override an existing value. This seems to break with Map semantics, but I can see the argument that it's an "add" method and not a "put". Fair enough. So, I guess the next logical question is why not? Presumably it's so that different libraries don't squash each other and so that Tapestry itself gets first stab at a configuration key. I can accept that it's a valid error condition, but, attempting to override a value does nothing but log a warning. The log4j properties file generated with the maven archetype won't log this, either, since it's not an error. So, this can be a bit frustrating to a new user. Now, it's hard to complain too much. The docs are quite clear on how everything works, even if a bit short on rationale. I just think that if it truly is an error condition, it should be made explicitly so. Or, if it's really all that bad of a thing, then overrides should be allowed. For what it's worth, I started thinking about this more as I tried to contribute a new NullFieldStrategy for the key "default" in an attempt to fix my TextFields, BeanEditForms, etc. in one spot. I went with the approach that felt most natural at the time, and ran into that. So, it's more a usability observation. -- Kevin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
