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. 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.
by adding process() to irequesttarget and a separate step on the request cycle we can remove IEventProcessorStrategy and IEventProcessor no? -igor
