On 2/6/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
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.
while it might be clean, the code does not communicate this at all. the
process+render functionality is encapsulated in IRequestTarget,respond()
method instead of two seperate methods which would much better parallel your
idea.
> 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.
that is fine, what i want to make trivial is code like this
requestcycle.process() {
Transaction txn=new Transaction();
try {
super.process();
} catch (RuntimeException e) {
txn.markRollback();
} finally {
...
}
}
right now its pita, because exception handling is routed elsewhere.
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.
right, i guess what i was trying to say that right now this workflow is
mapped onto a requestprocessor, what we want to do is something like
RequestCycle implements IRequestCycleProcessor and call it a day
-igor
