On 3/11/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > On Tue, Mar 11, 2008 at 3:51 AM, James Carman > <[EMAIL PROTECTED]> wrote: > > By the way, I can create a patch for this stuff if you like. I guess > > the decision needs to be made about where the "registry" > > (Map<Class,IRuntimeExceptionHandler) needs to go. Does it belong in > > IRequestCycleSettings or IExceptionSettings? > > > i think you should hold off on the patch until you have settled down > on how you want to do this
Well, that's what I'm trying to figure out. How do you guys think this should be done? IRequestCycleSettings or IExceptionSettings? > > > > And, do you want me to > > apply it to my already existing code which splits up Settings into > > multiple default implementations (which you guys said we should hold > > off on for 1.4.x)? > > > we havent decided if we are going to apply that patch or not, just > that we cant even start thinking about it until 1.4. i would say its > safer to create a patch off standard trunk. > Well, that patch lets us Spring folks configure our applications much easier via Spring. The Application's settings objects are settable, so you could configure a DefaultRequestCycleSettings bean in Spring and add in your global handlers there (then set it on your Application bean). It also shouldn't break any existing code, because the API doesn't change. > > > Perhaps there could be logic in there that checks to see if the > > requested Page object which caused the RuntimeException implements > > IRuntimeExceptionHandler also. That way, an individual page could > > override the "global" behavior if they wish. Just a thought. > > > that might make sense. but you have to realize that Page is a pretty > coarse scope for something like this. a lot of applications consist of > few pages that only act as containers for panels that are swapped in > and out, so i can have an application that is made up of one page and > everything else is madeup of panels that i swap in and out in that > main container page... > It was just a suggestion. Perhaps we could start with the global level and then allow customizing at some finer granularity later (if needed). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
