what i would like is something like this (keeping in mind its just a quick outline)requestcycle.process() { IRequestCodingStrategy strategy=resolveStrategy(request); RequestParameters params=strategy.decode(request); IRequestTarget target=resolveTarget(params); respond(target); }
The process events step was specifically designed to facilitate a processing model where the event handling and render step were separate, i.e. portlets. Besides, I think it is pretty clean to have that distinction. Also, we might get rid of the crazy loop that is now used for processing, but the request cycle needs to have some awareness of what kind of processing it is currently delegating. Particularly for deciding what should happen when setRequestTarget is called.
i would like to remove the default onruntimeexception handler, and let users wrap this method themselves if they wish
I would like to guarantee that Wicket at least intercepts the exception, if only to log it properly. I think I prefer the callback to telling people that they should put a try/ catch block about method x if they want to log the exception or do other stuff with it. But maybe I don't understand what you're proposing.
so now we have the workflow encapsulated in request cycle and it should be pretty easy to add pre/post processing.
The workflow already is encapsulated in the request cycle, it is too much delegation/ indirection that makes it ugly. Supporting portlets was one of the major drivers to start the refactoring that resulted in IRequestCycleProcessor. The original idea behind IRequestCycleProcessor isn't bad. It is basically a formalization of the steps RequestCycle typically executes when handling a request and put in an interface so that the actual execution can be delegated. Now, more than a year and a lot of tweaks of various people further, I think we can conclude that IRequestCodingStrategy takes a much more central place than the one it got initially assigned, and is too hard/ ugly to configure right now. Another thing I see now is that I gave in too easily on people's request to provide more flexibility through interfaces. This is exactly the kind of sh*t you end up by making everything an interface rather than keeping stuff together in a base class. So while I think the steps defined in request cycle processor are good - which the exception that the encoder should get a more prevalent place - I think that one of the best starts we can make is to get rid of the IRequestCycleProcessor interface and get back to something basic again. I think IRequestTarget is something we still need. I do feel sorry about having to much interfaces there too, so we could consider going back to base classes there as well, but the idea of RequestCycle working with (potentially a stack of) request target(s) is good.
as for the timeframe i am also not sure when is the best time to do this is.
I think if we try not to come up with the crazy ultra-perfect solution for a change, but just try to simplify what we have (basically keep the algorithm, but go loose some of the interfaces) and only put some extra thinking into how we can keep all the URL handling better together we could probably do it pretty soon. And it is probably worth it to do it now, as our and our users' projects can benefit from it and it will be a lot easier explaining that stuff in the book (though I'd have to rewrite a couple of pages). Also, getting rid of some interfaces isn't that drastic and I think it is unlikely we break a lot of users. Only the ones that did really crazy stuff, but they'll be able to fix those couple of occasions (like one a project?) where they actually used a customized processor. Eelco
