From: Rainer S. <Rai...@ab...> - 2005-12-16 11:50:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Lewis wrote: > One concern I have about the new ModelAndView class is that it does not > currently allow the View object to be created directly -- it can only be > set by name and must then be loaded by a ViewResolver. Adding in the > methods for setting the View directly would result in one set of API > methods that reference the servlet-side classes, but given that we use > the servlet-side infrastructure to do all the rendering I think this > might be reasonable. What are your thoughts on this? Without having spend much time to think about it: we need the servlet stuff anyway, so I don't see a problem referencing it where it's needed. > As for the Liferay issue, this sounds like a bug in Liferay. The > default behavior of handleActionRequestInternal and > handleRenderRequestInternal in AbstractController (i.e. throwing > Exceptions) is modeled after the default behavior of processAction, > doView, doEdit, and doHelp in the GenericPortlet from the JSR-168 API. > In fact, this behavior was requested by a number of users in order to be > consistent with the API. I think it would be better to get Liferay to > fix their bug than to try to work around it in the Spring framework. As > I think about, this is actually a pretty serious bug in Liferay. What > if you have a bunch of legitimate database manipulation code in your > handleActionRequestInternal? Will it try to run that every time you > change the window state? That doesn't sound good. Let me know what you > think. Meanwhile I think it's a bug in Liferay, too. The Portlet spec says in section PLT.11.1.1: Commonly, portals provide controls to change the portlet mode and the window state of portlets. The URLs these controls use are generated by the portal. Client requests triggered by those URLs must be treated as render URLs and the existing render parameters must be preserved. I've found an unresolved issue in the Liferay JIRA providing a simple patch (LEP-478 if anyone is interested). I also asked a question at the forums, I hope the bug will be fixed in the next Liferay release. Anyway, no need to change the Portlet MVC behaviour. > I should have a new build of the portlet framework out soon that is > based on the sandbox code. I'll appreciate your help in testing this. Sure. As you might have noticed I'm still struggling with porting my application to Liferay ;-) But after things have stabelized I'm eager to integrate the newest version of Portlet MVC. Cheers, Rainer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: GnuPT 2.6.1.1 by EQUIPMENTE.DE Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDoqoGav/AIDHDd+YRAkhRAKCG/1tElC7mFi/oPZnsO1GFX/HbDgCgwS7B Wf3OGfcsXoyfhmYrqgmYEyk= =ZdKC -----END PGP SIGNATURE----- |