as per my comment at : https://issues.apache.org/jira/browse/TAP5-721
I just started looking for a way on how to make this work and have an architecture question. The logic to handle a missing key message or exception lives in AbstractMessages and is quite straight forward. Adding a boolean field exceptionOnMissingKey which defaults to false and providing an extra constructor taking both the Locale and this boolean. The tricky part however is that all Messages are instantiated using a static forClass() method which obviously cant pass any System runtime property like this one along. In my oppinion this only leaves me with the option of making the exceptionOnMissingKey a static field and setting it in the TapestryModule, depending on SymbolConstant.EXCEPTION_ON_MISSING_KEY == "true". I don't particularly like the idea of a static field though and can imagine more people with me. So my question; What would be the best way to go about this problem? Is there a singleton service we can always assume present for all of Tapestry which could be accessed by the AbstractMessages? Or would there need to be a complete rethink of how Messages are instantiated in order to cater for Exceptions on missing keys? Cheers, Joost On Wed, May 27, 2009 at 9:14 AM, Joost Schouten (mailing lists) <joost...@jsportal.com> wrote: > I just created a jira issue > (https://issues.apache.org/jira/browse/TAP5-721) and will have a look > over the weekend to see if I can supply a patch for this. I thought > adding a boolean symbol along the lines of > MISSING_MESSAGE_KEY_FAIL_WITH_EXCEPTION which defaults to false. > > Cheers, > Joost > > On Wed, May 27, 2009 at 1:10 AM, Thiago H. de Paula Figueiredo > <thiag...@gmail.com> wrote: >> On Tue, May 26, 2009 at 10:01 AM, Ulrich Stärk <u...@spielviel.de> wrote: >>> On the other hand, Howard has modified Tapestry several times in order for >>> minor errors to be thrown as exceptions early on so that developers fix >>> their mistakes right away. Throwing an exception on a missing label seems to >>> fit in, at least for me. Maybe we can make it configurable so that everyone >>> can be happy :) >> >> Thiago H. de Paula Figueiredo: +1 :) >> >> -- >> Thiago >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
