Menu
▾
▴
springframework-developer
|
From: Nick L. <nic...@es...> - 2004-12-12 23:19:44
|
Someone (I think it was Rainer?) sent in a patch for SimplePortletFormController to fix the problem he discusses below. I don't think this has been applied, but it looks like a good change to me. (BTW, my name is spelt Lothian - not Lothiam. Could http://opensource.atlassian.com/confluence/spring/display/JSR168/Home be corrected?) Nick > -----Original Message----- > From: William G. Thompson, Jr. [mailto:wg...@ru...] > Sent: Friday, 10 December 2004 11:31 PM > To: spr...@li... > Subject: Re: [Springframework-developer] Portlet support (again) > Importance: Low > > > Folks, > > I have updated the PortletMVC[1] project page to reflect the current > status. At this point we need to indentify what is left to do to get > out of the Sandbox...here is what is on my mind: > > Are we happy with the ViewServlet solution/work-around? > > Are we Feature Complete? > > Is the Code Quality up to snuff for Spring? > > later. > Bill > > [1]http://opensource.atlassian.com/confluence/spring/display/J > SR168/Home > > > Rainer Schmitz wrote: > > > > Nick Lothian wrote: > > > >> Portlet support (in the sandbox) has been fairly stable > for the past > >> couple > >> of months. I've been finding it works well and I think a > few other people > >> have used it successfully, too. > > > > > > Is it stable or is just no-one working at it? > > > > Anyway, I'm using it and made quite a few changes mainly regarding > > forms. Also I added a PortletControllerMapping to map by request > > parameters. > > > > One general problem: > > In the current CVS version form handling takes place totally in the > > render phase, request parameters being forwarded by the > action phase. > > This approach does not work in all cases. E.g. if you want > to redirect > > to another URL the response.sendRedirect(URL) call has to > be made on the > > ActionResponse. > > > > The code is working for me, but not production ready and > certainly needs > > some clenup. > > > > Cheers, > > Rainer > > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Nick L. <nic...@es...> - 2004-12-13 01:18:28
Attachments:
SimplePortletFormController.java
|
> > Nick Lothian wrote: > > Someone (I think it was Rainer?) sent in a patch for > > SimplePortletFormController to fix the problem he discusses > below. I don't > > think this has been applied, but it looks like a good change to me. > > I don't recall this patch going by...do you still have it? > The updated file is attached - I don't have a patch file. > > > (BTW, my name is spelt Lothian - not Lothiam. Could > > > http://opensource.atlassian.com/confluence/spring/display/JSR1 > 68/Home be > > corrected?) > > fixed. sorry about that. > Thanks Nick |
|
From: Rainer S. <Rai...@ab...> - 2004-12-13 09:19:29
|
Aloha! I sent a patch, but meanwhile I've done more. I've attached a zip file containing my changed and added files to confluence: http://opensource.atlassian.com/confluence/spring/display/JSR168/Home?showComments=true#comments Below is a copy of the comment I posted there. Cheers, Rainer This zip contains some (many) changes to the CVS code. Mainly the form handling code is affected, trying to build a form controller hierarchy similiar to the servlet tree. A new controller type is ActionFormController for forms requiring processing in the action phase, e.g. to call ActionResponse.sendRedirect(String), ActionResponse.setPortletMode(PortletMode), or link ActionResponse.setWindowState(WindowState). A controller extending this is RedirectFormController. Another new class is ParameterControllerMapping to map controllers by a given request parameter, and ParameterMappingInterceptor to intercept those parameters in ActionRequests and forward it to the according RenderRequest. The code works for me but needs some more testing and documentation. Generally it might be necessary to change some method signatures in base classes from using ActionRequest/Response or RenderRequest/Response to use the more general PortletRequest/Response. Then implementing controllers have more freedom to choose wether the processing will take place mainly in the render phase (as proposed in the original code) or in the action phase (as implementd by ActionFormController). After implementing a few portlets I can imagine the need for portlets doing more work in the action phase and forward the result to the render phase as parameter or even in the portlet session. In addition the next version of the portlet specification might relax the communication constraints between action and render phases (e.g. by allowing to set RenderReuqest attributes). The proposed changes will make it easier for implementing controllers to implement those extensions. |
|
From: Nick L. <nic...@es...> - 2004-12-13 23:13:29
|
Comments inline. > > Aloha! > > I sent a patch, but meanwhile I've done more. > I've attached a zip file containing my changed and added files to > confluence: > http://opensource.atlassian.com/confluence/spring/display/JSR1 > 68/Home?showComments=true#comments > Below is a copy of the comment I posted there. > > Cheers, > Rainer > From a quick look this looks pretty promising. Does org.springframework.web.portlet.mvc.SimpleFormController replace org.springframework.web.portlet.SimplePortletFormController? If not then when should SimplePortletFormController be prefered? > > This zip contains some (many) changes to the CVS code. > Mainly the form handling code is affected, trying to build a form > controller hierarchy similiar to the servlet tree. > A new controller type is ActionFormController for forms requiring > processing in the action phase, e.g. to call > ActionResponse.sendRedirect(String), > ActionResponse.setPortletMode(PortletMode), or link > ActionResponse.setWindowState(WindowState). > A controller extending this is RedirectFormController. > > Another new class is ParameterControllerMapping to map > controllers by a > given request parameter, and ParameterMappingInterceptor to intercept > those parameters in ActionRequests and forward it to the according > RenderRequest. > > The code works for me but needs some more testing and documentation. > > Generally it might be necessary to change some method > signatures in base > classes from using ActionRequest/Response or > RenderRequest/Response to > use the more general PortletRequest/Response. Then implementing > controllers have more freedom to choose wether the processing > will take > place mainly in the render phase (as proposed in the original > code) or > in the action phase (as implementd by ActionFormController). After > implementing a few portlets I can imagine the need for portlets doing > more work in the action phase and forward the result to the > render phase > as parameter or even in the portlet session. Yes, I agree this would be a good change and I think it should be made. > In addition the next version of the portlet specification might relax > the communication constraints between action and render > phases (e.g. by > allowing to set RenderReuqest attributes). The proposed changes will > make it easier for implementing controllers to implement > those extensions. > > I'd like to think that might be the case but some people on the JSR committee seemed pretty opposed to this when it came up on the pluto-dev list. Nick |
|
From: Rainer S. <Rai...@ab...> - 2004-12-14 13:48:15
|
Nick Lothian wrote: > Does org.springframework.web.portlet.mvc.SimpleFormController replace > org.springframework.web.portlet.SimplePortletFormController? Yes. Sorry, I forgot to delete SimplePortletFormController and mention the name change. When I introduced the other classes I got pretty confused by all these PortletSomething names, so I decided to keep the names as used in the org.springframework.web.servlet tree. This way the correspondence between classes is obvious and the names are simpler. >>In addition the next version of the portlet specification might relax >>the communication constraints between action and render >>phases (e.g. by >>allowing to set RenderReuqest attributes). The proposed changes will >>make it easier for implementing controllers to implement >>those extensions. >> >> > > > I'd like to think that might be the case but some people on the JSR > committee seemed pretty opposed to this when it came up on the pluto-dev > list. I know :-(. But I still haven't heard any good reason why not to allow RenderRequest attributes, so maybe they'll make up their minds. Rainer |
|
From: Nick L. <nic...@es...> - 2004-12-14 23:59:41
|
> > Nick Lothian wrote: > > > Does > org.springframework.web.portlet.mvc.SimpleFormController replace > > org.springframework.web.portlet.SimplePortletFormController? > > Yes. Sorry, I forgot to delete SimplePortletFormController > and mention > the name change. When I introduced the other classes I got pretty > confused by all these PortletSomething names, so I decided to > keep the > names as used in the org.springframework.web.servlet tree. > This way the > correspondence between classes is obvious and the names are simpler. > The other thing we should look at fixing is the Exception handling. At the moment most things are just defined to throw Exception. We can probably tidy that up some. Nick |
|
From: William G. T. Jr. <wg...@ru...> - 2004-12-13 00:10:46
|
Nick Lothian wrote: > Someone (I think it was Rainer?) sent in a patch for > SimplePortletFormController to fix the problem he discusses below. I don't > think this has been applied, but it looks like a good change to me. I don't recall this patch going by...do you still have it? > (BTW, my name is spelt Lothian - not Lothiam. Could > http://opensource.atlassian.com/confluence/spring/display/JSR168/Home be > corrected?) fixed. sorry about that. later. Bill > > > Nick > > >>-----Original Message----- >>From: William G. Thompson, Jr. [mailto:wg...@ru...] >>Sent: Friday, 10 December 2004 11:31 PM >>To: spr...@li... >>Subject: Re: [Springframework-developer] Portlet support (again) >>Importance: Low >> >> >>Folks, >> >>I have updated the PortletMVC[1] project page to reflect the current >>status. At this point we need to indentify what is left to do to get >>out of the Sandbox...here is what is on my mind: >> >>Are we happy with the ViewServlet solution/work-around? >> >>Are we Feature Complete? >> >>Is the Code Quality up to snuff for Spring? >> >>later. >>Bill >> >>[1]http://opensource.atlassian.com/confluence/spring/display/J >>SR168/Home >> >> >>Rainer Schmitz wrote: >> >>>Nick Lothian wrote: >>> >>> >>>>Portlet support (in the sandbox) has been fairly stable >> >>for the past >> >>>>couple >>>>of months. I've been finding it works well and I think a >> >>few other people >> >>>>have used it successfully, too. >>> >>> >>>Is it stable or is just no-one working at it? >>> >>>Anyway, I'm using it and made quite a few changes mainly regarding >>>forms. Also I added a PortletControllerMapping to map by request >>>parameters. >>> >>>One general problem: >>>In the current CVS version form handling takes place totally in the >>>render phase, request parameters being forwarded by the >> >>action phase. >> >>>This approach does not work in all cases. E.g. if you want >> >>to redirect >> >>>to another URL the response.sendRedirect(URL) call has to >> >>be made on the >> >>>ActionResponse. >>> >>>The code is working for me, but not production ready and >> >>certainly needs >> >>>some clenup. >>> >>>Cheers, >>>Rainer >>> |
