I am using JSTL c:url tag to define my URL's in the application, something like:
<c:url value"/home" />
But the problem is that it appends the application context to the url, so the link becomes http://appName.come/appName/page while it should be http://appName.come/page.
The link had to be with slash, because it's not relative. I want to prevent the application context from being added or something like that, any ideas?
That's just the sole purpose of c:url: adding the context root and if necessary jsessionid whenever client doesn't support cookies. It also has support for URL-encoding the query parameters by c:param. If you don't want to have that, then just don't use c:url but use a plain HTML <a> element instead.
home
Update: as per the comment you seem to want to have the jsessionid in the URL (do you realize that the sessions are by default not shared between contexts and that you have to configure the serletcontainer accordingly?). In that case, manually set the context attribute.
<c:url context="/" value="/home" />
Related
What is the difference between specifying the plid in the opening tag when creating a portlet url
<liferay-portlet:renderURL var="myurl" windowState="normal" plid="123456">
<liferay-portlet:param name="struts.portlet.action" value='/view/myAction' />
</liferay-portlet:renderURL>
and passing it as a param
<liferay-portlet:renderURL var="myurl" windowState="normal">
<liferay-portlet:param name="struts.portlet.action" value='/view/myAction' />
<liferay-portlet:param name="plid" value='123456' />
</liferay-portlet:renderURL>
I get different error messages when the plid doesn't exist so I was wandering what the difference was
Q: What is the difference between specifying the plid in the opening tag when creating a portlet url and passing it as a param
The main difference is:
for tag-attribute-plid it would check for the plid and change your URL accordingly for that layout (page).
and for request-param-plid it would simply append it to your URL (as a query-string) with proper namespace like other request params. Nothing special.
Now an example
If tag-attribute-plid is used as follows inside your my-portlet:
<liferay-portlet:renderURL var="myurl" windowState="normal" plid="123456">
<liferay-portlet:param name="struts.portlet.action" value='/view/myAction' />
</liferay-portlet:renderURL>
When you want to construct a URL on a page-x to go to another page-y. Suppose you are on page: Home and you want to go to the Help page or to Control Panel, then in the plid attribute you would pass pild of Help page or plid of the Control Panel.
So if I pass the plid of Control Panel then the final URL would look something like:
http://mylocalhost.com/group/control_panel/manage?p_p_auth=1g0RGj4L&p_p_id=my_WAR_myportlet&p_p_lifecycle=0&p_p_state=normal&p_p_mode=view&_my_WAR_myportlet_struts.portlet.action=%2Fview%2FmyAction
The above is not achievable by passing the plid as a request param.
Q: I get different error messages when the plid doesn't exist so I was wandering what the difference was
Now you know what the difference is, so it might be easy to answer this.
If the tag-attribute-plid is incorrect it would create a URL something like this:
http://mylocalhost.com/c/portal/layout?p_l_id=123456&p_p_auth .....
And if request-param-plid is incorrect it would create a URL for current page and append the plid, something like this:
http://mylocalhost.com/web/guest/home?p_p_id=my_WAR_myportlet&p_p_lifecycle=0&p_p_state=normal&p_p_mode=view&_my_WAR_myportlet_struts.portlet.action=%2Fview%2FmyAction&_my_WAR_myportlet_plid=123456
Hope this helps.
What is the difference between specifying the plid in the opening tag and appending as request parameter when creating a portlet URL?
plid as tag-attribute: There are two certainties, if any layout (page)
for given plid is found on portal, then it will create URL specific to
that page, otherwise plid will be appended as a queryString parameter.
plid as request-parameter: In either case (correct / incorrect plid),
plid will be appended as a queryString parameter with current layout
URL with proper namespace of the portlet, which can be extracted from
request object.
I get different error messages when the plid doesn't exist.
Yes, certainly you will get, if there is no any layout / page found in your portal with the
given plid.
so I was wandering what the difference was.
The only difference can be the search for layout in case-1 before
appending it to the URL on creation of renderURL by tag. While in case-2, plid is simply passed a
request object that will be accessible in your portlet action.
I am implementing the Spring Pet Clinic Sample project given here
Implementation here
In the home page all the urls are encoded by <spring:url /> tag. I just want to confirm that is it a good programming practice to encode the links, even the simple navigation urls by the spring:url tag or is it done for a specific reason?.
Yes, it's a good practice. That tag is a Spring JSP tag for creating URLs with enhancements for JSTL c:url.
<c:url> tag is used to create a url and it is helpful in the case when cookies is turned off by the client, and you would be required to rewrite URLs that will be returned from a jsp page.
The rewritten URL will encode the session ID if necessary to provide persistent sessions.
For example, your URL will be displayed as:
<c:url value="a.jsp">
/context/a.jsp // when cookies is enabled
/context/a.jsp;jsessionid=B01F432.... // when cookie is disabled
This way, the servlet container can track the user requests. Another important thing is that c:url will prefix the context root, so you don't need to write your root context prefix everywhere.
Like I said, <spring:url> contains some enhancements over JSTL like encoded URI template variables for example.
<spring:url value="/url/path/{variableName}">
<spring:param name="variableName" value="more than JSTL c:url" />
</spring:url>
Results in: /currentApplicationContext/url/path/more%20than%20JSTL%20c%3Aurl
See more details in here: http://docs.spring.io/spring/docs/3.1.4.RELEASE/javadoc-api/org/springframework/web/servlet/tags/UrlTag.html
In my application I am trying to get labels out of a message bundle.
However rather then use constant key values I am using variables
<c:forEach var="emailAddress" items="${emailAddresses}">
...
<c:set var="labelKey" value="Contact_Label_${emailAddress.type}"/>
...
<h:outputText value="#{faces_translations[labelKey]}"/>
...
</c:forEach>
Most of the time this works correctly, but every so often when a page is
loaded some of the label are not processed correctly and the following
message is displayed:
???Contact_Label_???
It looks like the email.type does not return a value, however I added some
debug code to print out the value of email.type by including
${emailAddress.type}
and saw that a value was returned.
Another thing I tried was to remove the value everytime before setting it
again inside the loop using . This resulted in the following
exception. I verified that I had the tag library included in the WAR file
(jstl-api-1.2.jar and jstl-impl-1.2.jar as well as javax.faces-2.1.7).
<c:remove> Tag Library supports namespace: http://java.sun.com/jsp/jstl/core,
but no tag was defined for name: remove
Both these issues are really baffling. The label works most of the time,
but not consistently. The tag is defined in the included library, but cannot be found.
Thanks in advance for any pointers.
JSF UI components and tag handlers like JSTL doesn't run in sync. JSTL runs when the JSF view is to be built. The result is a JSF component tree without any tag handlers like <c:xxx> and <f:xxx>. JSF UI components runs when the JSF view needs to generate HTML for the HTTP response. That very same JSF view can be reused multiple times in subsequent HTTP requests as long as you're interacting with the same view by returning null or void on POST actions (like as you should use a #ViewScoped bean). It is not true that JSTL tags runs on every single HTTP request. That's most likely where it went wrong in your case.
Rather use JSF UI components if you want consistent render-time behaviour while reusing the same view. Your construct can be replaced as follows:
<ui:repeat var="emailAddress" value="#{emailAddresses}">
...
<ui:param name="labelKey" value="Contact_Label_#{emailAddress.type}" />
...
<h:outputText value="#{faces_translations[labelKey]}" />
...
</ui:repeat>
See also:
JSTL in JSF2 Facelets... makes sense?
I am in the process of changing a project which used a simple java HTTPServer on port 8080 to that which uses the Spring MVC servlet framework.
There are lots of links in the application like so:
Manage rules<br/>
Which worked fine using requests such as:
http://localhost:8080/send
However, these now don't work unless I put the servlet name in front like so:
"Manage rules<br/>"
Just wondering is there any way around this, or is it a matter of just changing all the href links to add the servlet name in front of them?
Note that I dont have to add the servlet name in my #RequestMapping calls at the start of methods, its only links that are the problem. E.g. this works fine without adding the servlet name in front
#RequestMapping(value = "/send", method = RequestMethod.GET)
If you use JSPs in your view layer, use a tag library that has a link tag (or write one yourself). Basically, the link tag has to create the url by doing
HttpServletResponse.encodeURL(originalUrl)
The <c:url> tag in JSTL does that, but it only generates the URL, not the link tag, but it can get you there like this:
<c:url value="your/relative/url" var="somevar" />
Link Text
Is there a cleaner way to do this in a JSP/Struts1 setup ?
... some HTML here ...
EDIT: In admin mode I would like to have access to additional parameters from a form element,
e.g. from the form element:
input type="text" value="Test user" name="Owner"
EDIT 2: Actually, my problem is very similar to the question that was asked in : Conditionally Render In JSP By User
But I don't really get the "pseudo-code" from the likely answer
Is SessionConfig exposed as a bean in your JSP (as part of request / session / Struts Form)?
If it's not, you can expose it. And if it's a static class containing global settings (which, by the looks of it, is a possibility), you can create a small wrapper and put it in the servlet context which you'd then be able to access from Struts tags as scope="application".
Once that's done you can check your condition via Struts tags:
<logic:equal name="sessionConfig" property="adminMode" value="true">
... your HTML here
</logic:equal>
Or, if you're using EL / JSTL, same can be done via <core:if>.
Without more information, it's hard to answer this, but I'd think instead of separate views: one for admin mode, one for normal mode. Extracting the parts of your pages into tiles will help you do this without a lot of pain; see: http://tiles.apache.org/