掲示板
The method of portlet forms
12年前 に Lirone75 M. によって更新されました。
The method of portlet forms
Regular Member 投稿: 118 参加年月日: 07/03/19 最新の投稿
Hi,
let say that I have a search form in a portlet.
As I'm looking for data and not modifying data, the method of the form should simply be a GET method.
And for the portlet url, I think that it could be a render url because I want to render the portlet in the state corresponding with search criteria field of the search form.
It seems that it's not conventionnal way to do the things, for example the liferay search portlet use a POST in the search criteria form of the portlet.
I didn't find anywhere that form method should always be a POST.
Is it simply a good habit, or a architectural portal convention that has been choosen in liferay ?
I use POST method in form in all case (even when the portlet just render data and don't process data) and in most of case I set
to avoid the browser popup to appear when the user perform a refresh "F5" on the page.
But I didn't try with a form with a GET method and a render URL, does it work in liferay ?
As I remember but I'm not absolutely sure, I think that in the "GET" form, the HTTP RFC encoding of parameters is iso8895, but most of browsers doesn't respect this rule and use the encoding that you want.
But except for this possible reason, is there any other reason, it may be forbidden to do GET method for form in liferay portlets ?
Could someone explain more precisely and make things more clear on this subject ?
let say that I have a search form in a portlet.
As I'm looking for data and not modifying data, the method of the form should simply be a GET method.
And for the portlet url, I think that it could be a render url because I want to render the portlet in the state corresponding with search criteria field of the search form.
It seems that it's not conventionnal way to do the things, for example the liferay search portlet use a POST in the search criteria form of the portlet.
I didn't find anywhere that form method should always be a POST.
Is it simply a good habit, or a architectural portal convention that has been choosen in liferay ?
I use POST method in form in all case (even when the portlet just render data and don't process data) and in most of case I set
<action-url-redirect>true</action-url-redirect>
to avoid the browser popup to appear when the user perform a refresh "F5" on the page.
But I didn't try with a form with a GET method and a render URL, does it work in liferay ?
As I remember but I'm not absolutely sure, I think that in the "GET" form, the HTTP RFC encoding of parameters is iso8895, but most of browsers doesn't respect this rule and use the encoding that you want.
But except for this possible reason, is there any other reason, it may be forbidden to do GET method for form in liferay portlets ?
Could someone explain more precisely and make things more clear on this subject ?
12年前 に David H Nebinger によって更新されました。
RE: The method of portlet forms
Liferay Legend 投稿: 14919 参加年月日: 06/09/02 最新の投稿
Primarily you are mixing the servlet world and the portlet world incorrectly...
Servlets care about post vs get, what the http request parameters are, etc. When you play in the servlet world you can have some control over the post vs get, etc.
In the portlet world, for the most part you do not have that luxury. Portlets don't (shouldn't, anyway) know anything about the request method (get vs post) or the request parameters.
The portlet spec works because of the well-defined portlet lifecycle. Portlets do things in the action phase, and the render phase is only used to render content. There is a reason for this; many portlets can be on a portal page, but only one of them (at a time) is doing some action in response to a click, but the others will need to re-render their snippets.
When you're looking at a JSP page, for example, it is easy to get the two worlds mixed together, but not always w/ the expected results. Other frameworks do not really show off the mixing, i.e. in JSF we don't really specify the http method at all.
Servlets care about post vs get, what the http request parameters are, etc. When you play in the servlet world you can have some control over the post vs get, etc.
In the portlet world, for the most part you do not have that luxury. Portlets don't (shouldn't, anyway) know anything about the request method (get vs post) or the request parameters.
The portlet spec works because of the well-defined portlet lifecycle. Portlets do things in the action phase, and the render phase is only used to render content. There is a reason for this; many portlets can be on a portal page, but only one of them (at a time) is doing some action in response to a click, but the others will need to re-render their snippets.
When you're looking at a JSP page, for example, it is easy to get the two worlds mixed together, but not always w/ the expected results. Other frameworks do not really show off the mixing, i.e. in JSF we don't really specify the http method at all.
12年前 に Lirone75 M. によって更新されました。
RE: The method of portlet forms
Regular Member 投稿: 118 参加年月日: 07/03/19 最新の投稿
No, POST, GET are first HTTP&REST concepts, before being servlets concepts : servlets only wraps HTTP&REST concepts.
The question is how portal, and portlet architecture deal with http concepts. The concern here is not servlet.
That's right user clicks in the pages are commonly handle by processAction method.
But you can also use renderUrl as an optimization as the JRS 168 says it :
So we can use renderURL to pass parameters to the portlet and these parameters represents the state of the portlet in which it must be render.
renderURL are commonly used in HTML tag <a href="<renderURL>">my link</a> but we also could imagine use renderURL with forms declaring the method attribute GET that is semantically equivalent to a <a href>...</a> element.
So the question is : can liferay work with GET forms ? And if not, I'd like to know what is the specific technical reason for that.
The question is how portal, and portlet architecture deal with http concepts. The concern here is not servlet.
That's right user clicks in the pages are commonly handle by processAction method.
But you can also use renderUrl as an optimization as the JRS 168 says it :
A render URL is an optimization for a special type of action URLs. The portal/portlet-
container must not invoke the processAction method of the targeted portlet.xxvi The
portal/portlet-container must ensure that all the parameters set when constructing the
render URL become render parameters of the subsequent render requests for the
portlet.xxvii
So we can use renderURL to pass parameters to the portlet and these parameters represents the state of the portlet in which it must be render.
renderURL are commonly used in HTML tag <a href="<renderURL>">my link</a> but we also could imagine use renderURL with forms declaring the method attribute GET that is semantically equivalent to a <a href>...</a> element.
So the question is : can liferay work with GET forms ? And if not, I'd like to know what is the specific technical reason for that.
12年前 に Raja Nagendra Kumar によって更新されました。
RE: The method of portlet forms
Expert 投稿: 484 参加年月日: 06/03/02 最新の投稿
>So the question is : can liferay work with GET forms ? And if not, I'd like to know what is the specific technical reason for that.
Answer is yes, as Liferay is the implementation of JSR-168.
JSR-168 makes GET and POST obsolete/hides as portlet run-time handles GET and Post for you and gives a different life-cycle which is processAction and renderRequest. One could could receive all the GET or POST parameters is ActionRequest. only.
The Main reason for this is Portlet Specification is productive framework to make the developers more smarter than basic HTTP servlet approach.
Like the way you have adopted to doGet and doPost methods in servlets, start solving the issues with framework provided lifecycle and this would lead you with more work done by Portlet Container, specially in scalability and performance tuning.
Regards,
Raja Nagendra Kumar,
C.T.O
www.tejasoft.com
Answer is yes, as Liferay is the implementation of JSR-168.
JSR-168 makes GET and POST obsolete/hides as portlet run-time handles GET and Post for you and gives a different life-cycle which is processAction and renderRequest. One could could receive all the GET or POST parameters is ActionRequest. only.
The Main reason for this is Portlet Specification is productive framework to make the developers more smarter than basic HTTP servlet approach.
Like the way you have adopted to doGet and doPost methods in servlets, start solving the issues with framework provided lifecycle and this would lead you with more work done by Portlet Container, specially in scalability and performance tuning.
Regards,
Raja Nagendra Kumar,
C.T.O
www.tejasoft.com
12年前 に Lirone75 M. によって更新されました。
RE: The method of portlet forms
Regular Member 投稿: 118 参加年月日: 07/03/19 最新の投稿Raja Nagendra Kumar:
JSR-168 makes GET and POST obsolete/hides as portlet run-time handles GET and Post for you and gives a different life-cycle which is processAction and renderRequest. One could could receive all the GET or POST parameters is ActionRequest. only.
JSR makes GET and POST obsolete, but it cannot handle the problem of F5 popup when refreshing the page in browser because it doesn't take into account the GET & POST concept of HTTP.
So in the developper point of view GET & POST, at the end developper would have anyway to worry about POST and GET.
Raja Nagendra Kumar:
Answer is yes, as Liferay is the implementation of JSR-168.
that doesn't seem to work, to pass parameter it seems one should use POST method in form, for example :
http://www.coderanch.com/t/502840/Portals-Portlets/java/liferay-portlet-form-parameters-missing
http://www.liferay.com/community/forums/-/message_boards/message/4381919#_19_message_4381919
In my opinion, that should work but it doesn't.
It seems that the best to do it to try, I'll give a try this morning and I'll tell you if it really works.
12年前 に Raja Nagendra Kumar によって更新されました。
RE: The method of portlet forms
Expert 投稿: 484 参加年月日: 06/03/02 最新の投稿
How are you generating POST url..
try using action='<portlet:actionURL>
Regards,
Nagendra
try using action='<portlet:actionURL>
Regards,
Nagendra
12年前 に Lirone75 M. によって更新されました。
RE: The method of portlet forms
Regular Member 投稿: 118 参加年月日: 07/03/19 最新の投稿Raja Nagendra Kumar:
How are you generating POST url..
??
Are you drunk, really awake ?
Justly, the question is about GET method in form.
What is the value of such a response from you ?
12年前 に Lirone75 M. によって更新されました。
RE: The method of portlet forms
Regular Member 投稿: 118 参加年月日: 07/03/19 最新の投稿
As I thought, this does NOT work.
Perhaps liferay thinks that's more simple and straightforward for the developper to always use the same method in form not several solution.
But technically and conceptually (except perhaps for the problem of encoding) I don't see other reason, the GET for form would not be possible.
Beside, for example, jboss portal seems to support it.
Perhaps liferay thinks that's more simple and straightforward for the developper to always use the same method in form not several solution.
But technically and conceptually (except perhaps for the problem of encoding) I don't see other reason, the GET for form would not be possible.
Beside, for example, jboss portal seems to support it.
9年前 に Olaf Kock によって更新されました。
RE: The method of portlet forms
Liferay Legend 投稿: 6403 参加年月日: 08/09/23 最新の投稿
This is an old posting, but as the same has just come up on Stackoverflow, let me add the answer here for future reference:
An ActionURL contains some parameters, embedded in the URL (separated with "?"). The HTML Spec allows the browser to strip these from the URL in a GET form, when it appends the form's input fields to the URL. Thus Liferay has nothing to do with it: It's the browser that strips certain required parts from the URL (unless you add them as hidden fields to the form), so that Liferay doesn't even trigger an action.
Check reasons, workarounds and specification links at this question on stackoverflow.
An ActionURL contains some parameters, embedded in the URL (separated with "?"). The HTML Spec allows the browser to strip these from the URL in a GET form, when it appends the form's input fields to the URL. Thus Liferay has nothing to do with it: It's the browser that strips certain required parts from the URL (unless you add them as hidden fields to the form), so that Liferay doesn't even trigger an action.
Check reasons, workarounds and specification links at this question on stackoverflow.