Yes, that is often the reality: it reveals the conception problems of an application.
But in my case, it was to change the behavior of Tapestry, for example, replacing the DefaultValidationDecorator by another one for a component library. If I use configuration override, it means that no one else will ever be able to replace my implementation by a custom one. On Fri, Feb 26, 2010 at 1:55 PM, Christian Riedel <cr.ml...@googlemail.com>wrote: > I think it could be useful to add a method like configuration.exists(key) > Once I had a problem where this feature would have helped me but I had to > improve the architecture of the application instead (which was actually a > good thing ^^ ) > > > Am 25.02.2010 um 13:23 schrieb Robin Komiwes: > > > Yes, I was pretty sure it was the problem. Too bad :( > > > > On Thu, Feb 25, 2010 at 11:40 AM, Kristian Marinkovic < > > kristian.marinko...@porsche.co.at> wrote: > > > >> hi Robin, > >> > >> imagine you have 2 overrides. which one is the correct one. > >> it will processed in the order the module classes are loaded. > >> and the order is not defined, it depends on the jvm, the os, the > >> file system,.... > >> > >> i guess you get the problem :) > >> > >> g, > >> kris > >> > >> > >> > >> Robin Komiwes <odiss...@gmail.com> > >> 25.02.2010 10:41 > >> Bitte antworten an > >> "Tapestry users" <users@tapestry.apache.org> > >> > >> > >> An > >> Tapestry users <users@tapestry.apache.org> > >> Kopie > >> > >> Thema > >> About configuration override > >> > >> > >> > >> > >> > >> > >> Hi there, > >> > >> I was wondering why configurations are only overridable only once? > >> > >> Regards, > >> > >> Robin > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
