having a single override possibility sounds ok.... like symbol source logic... FactoryDefaults ApplicationDefaults
and definitely an error for conflict Davor Hrg On 1/31/08, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
