> 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.
But it is not. The event processing is done in IEventProcessorStrategy
for which the portlet stuff provides an implementation (only processes
PortletMode and WindowState changes) that is different from the normal
implementation. Putting it in IRequestTarget would only make sense if
there was a different hierarchy for portlets and for normal web apps.
Which wouldn't really make sense considering the actual code that is
in PortletRenderRequestEventProcessorStrategy. So I think a separate
step for that is fine, but it could just be part of the request cycle.
> > 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 {
...
}
}
Yeah, that would be nice. +1 on that.
> 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
Exactly. Or just the methods of the interface and throw away
IRequestCycleProcessor and friends and move the logic to RequestCycle
and a few subclasses.
After that, we could take a look at how we can simplify configuring
the IRequestCodingStrategy. Or maybe we look back and decide that it
is easy enough after the refactoring.
Eelco
