Re: [Springframework-developer] Portlet and JSFs

[William G. T. Jr. <wg...@ru...>]

jürgen höller [werk3AT] wrote:
> But what criteria do you base your dispatching on when there's no URL? Request parameters?

yes, plus perhaps the Portal Mode (edit,view,help,...) and maybe some 
state...

and of course the other tricky bit is the two step 
call...ActionRequest/Response and then some time later the 
RenderRequest/Response.

>  
> Juergen
>  
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von Eduardo Issao Ito
> Gesendet: Di 13.04.2004 22:15
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Portlet and JSFs
> 
> 
> 
> jürgen höller [werk3AT] wrote:
> 
>>>Portlets can not access the URL that the client used to initiate the request on the portal.
>>
>>
>>While that makes sense, it effectively makes me wonder whether we need a Portlet dispatcher: With Servlets, dispatching is all about flexible URL mapping. AFAIK, Portlets have doView, doEdit etc callbacks, similar to doGet, doPost, etc from the Servlet API.
>>
>>So for typical Portlets, it's probably most important to allow for easy access to Spring facilities from those methods, rather than dispatch to some other components from a Portlet doView method. Portlet support classes similar to the ones I just added for Struts come to my mind.
>>
>>This doesn't seem to be much effort at all. Am I on the wrong track here?
>>
>>Juergen
> 
> 
> While in most cases a Portlet should be simple (just display some info),
> sometimes one portlet can be a complete web application in itself. In this case,
> having an MVC framework can make a huge difference. Imagine implementing a whole
> web application inside a servlet doPost(), and no framework underneath. With
> portlets you only have doView() to do the same thing...
> 
> A PortletDispatcher should be very similar to ServletDispatcher and reuse
> everything that is possible from the actual mvc framework. Ideally, implementing
> a portlet with Spring should be the same as implementing a servlet.
> 
>