one of the shorcomings i would like to address is that there is no way to
introduce try/catch easily around the entire request processing
the other one is the rediculous amount of indirection and also the number of
steps involved
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);
}
i would like to remove the default onruntimeexception handler, and let users
wrap this method themselves if they wish
so now we have the workflow encapsulated in request cycle and it should be
pretty easy to add pre/post processing.
im not sure if i would like to keep irequesttargetresolverstrategy, the
different impls can be different subclasses of webrequestcycle i think. its
not as reusable, but it removes a lot of complexity from tracing the code.
as for the timeframe i am also not sure when is the best time to do this is.
-igor
On 2/6/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
i would fold the IRequestCycleProcessor (or better said the abstract
methods
of AbstractCompoundRequestCycleProcessor)
into the RequestCycle i think But i dont know if we have to do it now.
johan
On 2/6/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> There is regularly some complaining about too much indirection and
> complexity when it concerns IRequestCycleProcessor. We went from a too
> monolithic RequestCycle to a too complex one, where we probably don't
> need half of the flexibility.
>
> The discussion I'd like to start here is whether people have ideas to
> do some basic damage control for 1.3 and 2.0. I think we already have
> too much on our plates to work for 4 months to get the
> ultimate-mother-of-all request cycle implementations (and even that
> one would probably get people in the curtains within a year... it's
> just how writing software works), but what we can do is see whether we
> can do some simple refactorings that takes away 50% of the pain.
>
> So... any ideas anyone?
>
> Eelco
>
