You may very well be right; every time I think that somethin can be just a warning, it turns out to do more harm than good. Upgrading these kinds of conflicts to errors may be a good idea.
I have also though about adding additional methods to the Configuration interfaces, override() methods that would operate on a second pass after the add() methods have their chance. But then you fall off a cliff .. how do you detect and handle override() conflicts? Do you need override2(), override3()? Probably a single level of override() would be nice. For OrderedConfiguration, some ability to override just the ordering of an existing named element might be handy. On Jan 31, 2008 11:28 AM, Kevin Menard <[EMAIL PROTECTED]> wrote: > 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] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
