We have a corporate website which has an iFrame within a page pointing to my XPage.
The problem I have is that the same XPage is also used in another iFrame (different page) and I need to clear some Scope variables on beforePageLoad event.
Using SSJS; how can I get the parent window url for my iFrame content?
Example:
Corporate page #1 = http://mycompany.com/training-courses
Corporate page #2 = http://mywebsite.com/training-ilo
Both pages have an iFrame pointing to http://dominoserver/myapp.nsf/xHome.xps
Unless your domino server domain is the same as the parent sites, you will not be able to access information from those pages.
Your best bet is to supply a url parameter to the src of the iframe:
<iframe src="http://dominoserver/myapp.nsf/xHome.xsp?site=xyz"></iframe>
Then, in your ssjs of your xpage you can grab the url information using the XSPUrl class:
var url : XSPUrl;
url = context.getUrl();
var site = url.getParameterName("site");
Related
I have a portlet that is deployed on a page and I need to produce a link that will load a different portlet (which is in a different module) in full-screen mode. I can load the built in Login portlet this way without a problem, but when I try to load any of my custom portlets I get two red error boxes with the message "You do not have the roles required to access this portlet." And I have the permissions - I can access the portlet fine when added to a page - and I'm even testing with an omni-admin account.
The portlet ID that has the .jsp file is 'subscriptionmanagement_WAR_subscriptionmanagementportlet' and the portlet ID I'm trying to load is 'GRPSignupForm_WAR_NY511RMportlet'. The tag is:
<liferay-portlet:renderURL portletName="GRPSignupForm_WAR_NY511RMportlet" var="grpPortlet" windowState="<%= WindowState.MAXIMIZED.toString() %>">
</liferay-portlet:renderURL>
Which produces the URL: http://localhost:8080/group/test/unsubscribe?p_p_id=tripitinerary_WAR_NY511RMportlet&p_p_lifecycle=0&p_p_state=maximized&p_p_mode=view
However, as I've mentioned, I have been able to load other portlets in this way. The login portlet for example using the same tag works fine:
<liferay-portlet:renderURL portletName="<%= PortletKeys.LOGIN %>" var="loginURL" windowState="<%= WindowState.MAXIMIZED.toString() %>">
<portlet:param name="mvcRenderCommandName" value="/login/login" />
</liferay-portlet:renderURL>
The obvious difference is that it is passing a specific render command parameter, but otherwise it is the same. It produces the URL:
http://localhost:8080/group/test-1/unsubscribe?p_p_id=com_liferay_login_web_portlet_LoginPortlet&p_p_lifecycle=0&p_p_state=maximized&p_p_mode=view&_com_liferay_login_web_portlet_LoginPortlet_mvcRenderCommandName=%2Flogin%2Flogin
For completeness, here is the code for the portlet I'm trying to load. But as I mentioned above, I have tried to load various portlets in this project and all of them produce the permissions error.
#Component(
immediate = true,
property = {
"com.liferay.portlet.display-category=root//NYSDOT//GRP",
"com.liferay.portlet.instanceable=false",
"com.liferay.portlet.header-portlet-css=/css/main.css",
"com.liferay.portlet.footer-portlet-javascript=/js/main.js",
"com.liferay.portlet.css-class-wrapper=grh-signup-form-portlet",
"javax.portlet.display-name=GRP Signup Form",
"javax.portlet.init-param.template-path=/html/",
"javax.portlet.init-param.add-process-action-success-action=false",
"javax.portlet.init-param.config-template=/html/configuration.jsp",
"javax.portlet.init-param.view-template=/html/view.jsp",
"javax.portlet.init-param.edit-template=/html/edit.jsp",
"javax.portlet.name=" + GRPSignupPortletKeys.GRPSIGNUP,
"javax.portlet.resource-bundle=content.Language",
"javax.portlet.security-role-ref=administrator,guest,power-user,user"
},
service = Portlet.class
)
public class GRPSignupPortlet extends GenericPortlet {
...
...
}
So it's obviously possible, as the Login portlet works. I'm sure there is just some small bit of config I'm missing. I've tried to see what is different in the Liferay Login portlet that allows it to work, but haven't found the secret.
Liferay CE 7.3
You need to add the property 'add-default-resource'. In the component add:
"com.liferay.portlet.add-default-resource=true"
From portal.properties: "add-default-resource" set to true will allow those portlets to be dynamically added to any page by any user. This is useful (and necessary) for some portlets that need to be dynamically added to a page, but it can also pose a security risk because it also allows any user to do it.
It's prudent to also add
"com.liferay.portlet.add-default-resource-check-enabled=true",
From portal.properties: Set this property to true to add a security check around this behavior. If set to true, then portlets can only be dynamically added to a page if it contains a proper security token. This security token is automatically passed when using a portlet URL from one portlet to another portlet.
I am trying to build a Support page for my website which should have Acumatica New Case Screen for customers to create a new Case. I tried using iFrame but when logged in, Selectors and dropdown don't respond. Any Suggestions how do I get New Case screen for my Support page just like in Acumatica Partner's portal.
This is working for me:
1) Create an acumatica portal web site; Make sure sp203000 page is accessible and works fine.
2) Create a simple html page and assign iframe src to be sp203000 screen url:
<!DOCTYPE html>
<html>
<body>
<style>
iframe {height:800px; width:1200px;}
</style>
<iframe src="http://localhost/AcuPortal/pages/sp/sp203000.aspx?CaseCD=null&CaseClassID=BILLING">
<p>Your browser does not support iframes.</p>
</iframe>
</body>
</html>
And it works fine:
New Case form embedded into frame
First time you will see the login screen in the frame. If you want users to see the form without logging in you need to think about some SSO solution for your site and acumatica.
We have a main public site, abcd.com, which is using SharePoint Office 365 and another replica SharePoint site using this format - abcd-public.sharepoint.com.
For some reason,
<link rel="canonical" href="http://abcd-public.sharepoint.com:80/Pages/Home.aspx" />
shows up on every page our main public website (abcd.com). The path above changes depending on the page the user is on.
If I understand this correctly, this could be one of the reason why our site does not show up on google search result at all. If possible, we would like to reverse the behavior so the SharePoint version of the site has the canonical url = abcd.com.
or
Is there a way to completely remove the canonical url from the main website (abcd.com)? Or is there some sort of a setting that could help our site to show on google search result?
I had the same problem and the only solution that I found is create a webpart to put in the masterpage and in the prerender event of the webpart put this lines of code:
protected override void OnPreRender(EventArgs e)
{
base.OnPreRender(e);
HttpContext.Current.Items["CanonicalURLWithParameters"] = "http://example.com/customurl";
}
Sergio
This thread is not a question , it was a doubt raised when I was going through Liferay Forums about using PortletURL.
In some cases I see this PortletURL inside the javscript Method
function createRowURL() {
var portletURL = new Liferay.PortletURL();
portletURL.setParameter("rowNumber", "25" );
return portletURL.toString();
}
In some cases I see this PortletURL inside the doView Method as shown
To get currentURL :
PortletURL url = PortletURLUtil.getCurrent(renderRequest, mimeResponse or renderResponse)
creating PortletURL from renderResponse :
For RenderURL:
PortletURL renderURL = renderResponse.createRenderURL();
For actionURL:
PortletURL actionURL = renderResponse.createActionURL();
Could anybody please tell me in which case PortletURL would be useful ?
Portlet applications are different from normal web applications. Portlets are mini pages inside a parent page called a portal and multiple portals become a book (a Weblogic term). Normal URL will not work in this situation. Aside from the reason given above, a portlet has a life circle with different states. You have to give the Portlet container a way to determine which portlet is communicating with it and what state it is being in - such as the window state of the portlet - is it minimized, maximized, or normal. Of course, another important function of the PortletUrl is to carry request parameters. If you are looking at a PortletURL you will sure see a lot exotic names along with the request parameters you give it.
Although most of the information needed by a PortletURL are common in many situations, the structure of a PortletURL is implementation-dependent and it is generated by the Portlet container one way or the other. There has been some time since my last liferay experience. I never used liferay specific javascript in my application. I used my own javascript/ajax to communication with the portal container. So I am just guessing the javascript way you presented is also liferay specific and won't be portable among different portal frameworks.
Edit: added types of PortletURLs and their differences and usage following comment from #PrakashK.
There are two types of PortletURLs:
Action URLs, they trigger an action request followed by a render request.
Render URLs, they trigger a render request.
So the purpose of an ActionURL is to trigger some kind of action - such as pressing a button. The action request will be intercepted by portlet container and send to appropriate action request handlers which process the action request and set necessary render parameters to be used by the render phase. In the life cycle of a portlet, a render request ALWAYS follows an action request. On the other hand, a RenderURl, as it's name suggested, is mainly for rendering the portlet.
Because of the "rendering" nature of a RenderURL, in JSR168(Portlet 1.0), you could not serve dynamically generated resources directly through the portlet. The only workaround is to use an additional servlet to serve the resources. The biggest problem of this approach is the inability of a Servlet to be involved in the lifecycle of a portlet. Direct links to the resources in the same portlet web application are not guaranteed to pass through the portal server and will not have portlet context available. To overcome this, in JSR286(Portlet 2.0), a feature called resource serving and a new kind of URL called ResourceURL has been introduced to enable a portlet to dynamically serve a resource. ResourceURL is not a PortletURL although they extend the same BaseURL. The biggest difference between a ResourceURL and an ActionURL is that a ResourceURL will NOT trigger a render request. This makes possible an Ajax request to the resource.
For more information on Portlet 2.0, please refer to [JSR286].
Hope the above information would be useful to you.
By default MOSS directs browser enabled InfoPath forms to the /_layouts/formserver.aspx page, with the query string parameters that define the form to display or edit. We have defined our own page (for a number of reasons) and would like to direct the forms in the form library there. The page can be hosted in that same _layouts folder, in a document library, it doesn't really matter.
Seems like there should be a linkeage (hopefully in a form of a configuration setting) that tells SharePoint where to direct the forms.
Thanks!
If you are using the SharePoint lists or form libraries to display the list of forms, you could add a jquery rewrite (in either a Custom Editor Web Part or Master Page) to look for links to the FormServer.aspx link.
<script type="text/javascript" src="~/_layouts/jquery.js"></script>
<script type="text/javascript">
$(document).ready(function(){
//Rewrite Form Links to Open in Custom Page
$("a[href*='/_layouts/FormServer.aspx']").each(function()
{
var formFileName = this.href.figureOutWhatFormAndParamsYouNeed()
var formServerUrl = 'https://server.example.com/_layouts/CustomPage.aspx'
this.href = formServerUrl
});
})
</script>
Have a look at the ServerFiles in the 12 Hive under 'Template\XML'. This has file extensions and a mapping to a redirect URL.
You can see there is a mapping for XSN and XML files in relation to InfoPath.
I haven't tried this and obviousily the normal caveats apply when altering files in the 12 Hive.