Including Openlayer.js in JSF 2.1 Project - jsf

I am trying to include OpenLayers.js in JSF project.
<h:outputScript library="js" name="OpenLayers.js" target="head"/>
I didn't have any resources folder so I created one and added openlayers.js and other folder as this thread tells.
I also tried to put it into lib folder
But I always get:
script type="text/javascript" src="RES_NOT_FOUND
Do I need to do additional configuration to run this js library?

We have the same problem. OpenLayers.js calculate the script location URI and based on this location include the other components like styles etc.
So it we use option 1 the JS is well included but there are broken link to CSS and IMAGES.
As a temporary solution we are using now the second option and it works well.
1: <h:outputScript library="js/openlayers" name="OpenLayers.js" />
2: <script src="resources/js/openlayers/OpenLayers.js"></script>
The cause is that JSF overrides the link so OpenLayers.js.xhtml does not match the regexp anymore:
http://HOST/CONTEXT/javax.faces.resource/OpenLayers.js.xhtml?ln=js/openlayers
It's not a problem to use the option2 as long as you don't something like MapConponent in a jar.

Related

putting jsf.js at the end of the body

I have a Java EE 8 web application deployed. it uses JSF 2.3
I test it with google PageSpeed Insights. and a recommendation says:
Eliminate render-blocking resources
…font/fonts-min.css.xhtml?ln=custom(**.com)
…fullcalendar/fullcalendar.bundle-min.css.xhtml?ln=vendors(**.com)
…base/vendors.bundle-min.css.xhtml?ln=vendors(**.com)
…base/style.bundle-min.css.xhtml?ln=demo(**.com)
…fix/poppins.css.xhtml?ln=custom(**.com)
/javax.faces.resource/jsf.js.xhtml?ln=javax.faces(**.com)
since jsf.js is added by default by the JSF framework. is there a solution so that I make it load at the end of the body next to other javascripts. And if there is, would that be good idea?
Thanks.
If you use PrimeFaces, you could activate the "MOVE_SCRIPTS_TO_BOTTOM" feature via context-param.
This moves all script includes (script src="...") to the bottom and it also merges all inline scripts (...) to a single inline script.
This is really a great performance boost.
See: https://github.com/primefaces/primefaces/issues/2888
It is possible to place the script to the end of the body using the target="body" attribute:
<h:head>
<h:outputScript name="jsf.js" library="javax.faces" target="body"/>
</h:head>
But as Kukeltje notes, keep in mind that this might have side effects and the optimization gain may be limited to first request.
The reference implementation (mojarra) explicitly adds this script to the <head> element which might have good reasons:
com.sun.faces.renderkit.RenderKitUtils.installJsfJsIfNecessary(FacesContext):
context.getViewRoot().addComponentResource(context, createJsfJs(), "head");

AEM 6.2 (Drag Component Here) Parsys height 0px

I am using AEM 6.2 and trying to create a parsys component in crx, using the code below
However, the height of this parsys, in edit mode, comes as 0px.
Attached are the screenshots.
When I manually change the height to some values eg. 40px, it looks fine.
Note: I am not using any client library for the above page. (no css and js)
Futher, All sample sites like geomatrix etc have parsys showing correctly.
Could anyone guide me with what I am doing wrong?
I think that the problem is outside the component or any of the code shown here.
I think what's happening is that the css style for the div that gives the droptarget placeholder its dimensions is not loading.
That's loaded as part of the AEM authoring client libraries which you should be inheriting from the foundation page component.
Examine your page component's sling:resourceSuperType property. It should point to either wcm/foundation/components/page or wcm/foundation/components/page or inherit from a component that does.
If that is set then you have may have blocked one of the scripts within it, quite possibly head.html.
Include following code in the head section of the page component's rendering script.
<!--/* Include Adobe Dynamic Tag Management libraries for the header
<sly data-sly-include="/libs/cq/cloudserviceconfigs/components/servicelibs/servicelibs.jsp" data-sly-unwrap/>
*/-->
<!--/* Initializes the Experience Manager authoring UI */-->
<sly data-sly-include="/libs/wcm/core/components/init/init.jsp" data-sly-unwrap/>
For resolving your issue, you need to include init.jsp in the first before writing down the parsys code. I mean write like this.
<head>
<sly data-sly-include='/libs/wcm/core/components/init/init.jsp' />
</head>
<body>
<sly data-sly-resource="${'par' #resourceType='foundation/components/parsys'}" />
</body>
I think #l-klement pointed it out correctly that the problem is outside component. When I rename the landingpage.html file to body.html it starts working fine. I think this may be because of different files like head.html etc present at wcm/foundation/components/page which is required to provide proper styling and load certain required client libraries which assigns proper styling to parsys.
If the above is true, my next question would be, How can I have my own head.html, body.html, header.html, footer.html etc files without compromising with the parsys styling?

Liferay 6.1.20 : Minimize and bundle theme Javascript

Is there a way to apply Liferay's built-in javascript minimizing and bundling capability to the javascript I've included in my theme? I have javascript.fast.load=true in portal-ext.properties and Liferay's javascript is getting bundled & minified in everything.jsp as expected. Also, all portlet javascript that is included via a portlet's liferay-portal.xml file is getting minified as expected. However, I've got many javascript files that are included in my theme because they are utilized on every page and I would like them to get minimized and bundled into everything.jsp along with all the Liferay portal javascript. I've tried the approach suggested by this question, but I think this will only work with a hook because the MinifyFilter will look for files to minify & bundle within the context of the portal web app, i.e. <TOMCAT>/webapps/ROOT. Is there a way I can specify a path to files in a different web app (the theme in this case) as the javascript.bundle.dir parameter? In other words, something like javascript.bundle.dir[javascript.jquery.files]=/<theme-path>/js. I've tried many variations and combinations of javascript.bundle.ids, javascript.bundle.dependencies, etc. to no avail. I know I can get around the problem by putting the javascript in a hook or putting it in portlet and embedding it in the theme but I'd really like to just keep the javascript in the theme. Is there a reasonable way to accomplish this?
There doesn't seem to be a good way to include javascript files from the theme with the minified and bundled Liferay javascript. While you can define a javascript bundle in portal-ext.properties that includes your files, you can't order the dependencies the way you need to in order to get everything to work using only configuration. You can configure the "everything" bundle to depend on your custom bundle but that's not very useful. It would be far more useful if you could configure Liferay to use your custom bundle as the new "everything" bundle and tell Liferay that your bundle depends on Liferay's "everything" bundle. However, the actual bundle ids that are included are hard-coded in Liferay's top_js.jspf file. So the only way to get everything to work would be to override Liferay's definition of javascript.everything.files to include both Liferay's files and your custom javascript. This doesn't seem like a very good solution since it tampers with Liferay's list of included javascript which would certainly be a pain when you need to upgrade Liferay. As Olaf suggested, you can minify and bundle the js yourself and just include it in the portal_normal template. That is a very reasonable solution and what I would normally recommend. Unfortunately I was in a situation where my customer was requesting that all the files be bundled in one file and we are not allowed to modify the build process.
Hook Workaround
There is a workaround using a hook that I don't necessarily recommend but it does accomplish the goal of getting all javascript minimized and bundled along with Liferay's javascript. The basic process is to move the javascript from the theme into a hook, configure a new bundle in portal-ext.properties that includes all of your files, then create a jsp hook for top_js.jspf that includes your new bundle instead of the hard-coded javascript.everything.files or javascript.barebones.files bundles. The steps are:
Move your javascript files into a hook project and place them under html/js. This will cause
the files to be copied to the javascript directory under the portal
web app, i.e. <TOMCAT_HOME>/ROOT/html/js. This is where the Liferay
MinifyFilter looks for javascript files to minify & bundle.
Define a javascript bundle in portal-ext.properties that references
all of your javascript files that need to be included in the bundle
created by the MinifyFilter. Your portal-ext.properties file should
look something like this:
minifier.enabled=true
javascript.fast.load=true
javascript.my.js.files =\
jquery.1.11.1,\
my-js-lib.js,\
my-other-js-lib.js
javascript.bundle.ids=\
javascript.barebone.files,\
javascript.everything.files,\
javascript.my.js.files
javascript.bundle.dir[javascript.my.js.files]=/html/js
# our bundle depends on all the files in the "everything" bundle
javascript.bundle.dependencies[javascript.my.js.files]=javascript.everything.files
Create a JSP hook for top_js.jspf. This file is under
<TOMCAT_HOME>/ROOT/html/common/themes. It is the file that includes
either the barebones.jsp or everything.jsp based on whether the user
is authenticated (if the user is authenticated they get
everything.jsp otherwise barebones.jsp is included). Replace the
references to the javascript.everything.files and/or
javascript.barebones.files bundles with a reference to your new
bundle based on your requirements. For example, if you only want to
include your javascript when the user is authenticated you just have
to replace references to javascript.everything.files.
Specifically, you make the following changes:
This line:
<script src="<%= HtmlUtil.escape(PortalUtil.getStaticResourceURL(request, themeDisplay.getCDNDynamicResourcesHost() + themeDisplay.getPathJavaScript() + "/everything.jsp", "minifierBundleId=javascript.everything.files", javaScriptLastModified)) %>" type="text/javascript"></script>
is changed to this:
<script src="<%= HtmlUtil.escape(PortalUtil.getStaticResourceURL(request, themeDisplay.getCDNDynamicResourcesHost() + themeDisplay.getPathJavaScript() + "/everything.jsp", "minifierBundleId=javascript.my.js.files", javaScriptLastModified)) %>" type="text/javascript"></script>
and this line:
javaScriptFiles = JavaScriptBundleUtil.getFileNames(PropsKeys.JAVASCRIPT_EVERYTHING_FILES);
is changed to this:
javaScriptFiles = JavaScriptBundleUtil.getFileNames("javascript.my.js.files");
* Non-Global Hook Caveat *
If you are putting the javascript and top_js.jspf hooks in a project with other hooks and the project is configured to use non-global jsp hooks, i.e. <custom-jsp-global>false</custom-jsp-global> the solution becomes more complicated. This is because setting <custom-jsp-global>true</custom-jsp-global> makes Liferay rename your hook jsp files rather than renaming the portal's jsp files. For example, if custom-jsp-global is set to true, which is the default setting, then when I make a hook for a page called top_js.jspf, the portal will rename the original top_js.jspf file to top_js.portal.jsp and my hook file will be used instead of the original. However, when custom-jsp-global is set to false then the original file stays intact and the jsp hook file is renamed to something that includes the name of the hook like top_js.my-hook.jspf. This is a problem when you're creating a hook for included files such as top_js.jspf because the file that includes top_js.jspf will still reference the old file, not the hook which is named top_js.my-hook.jspf. This means you have to also create a hook for the file that includes your hook. Likewise, if that file is included by another file you have to make hook for that file and so on until you reach the top level page. So, in the example of trying to create a hook for top_js.jspf we have to also do the following:
Create a hook for top_head.jspf and replace the reference to top_js.jspf with a reference to our hook, top_js.my-hook.jspf.
So this line
<%# include file="/html/common/themes/top_js.jspf" %>
becomes this
<%# include file="/html/common/themes/top_js.my-hook.jspf" %>
The top_head.jspf file is actually included by the theme in
portal_normal.vm using a Velocity variable that is initialized in
init.vm on the following line:
You need to assign $top_head_include to the top_head.my-hook.jspf hook in the theme's init_custom.vm, like this:
#set ($top_head_include = "$dir_include/common/themes/top_head.my-hook.jsp")
Your Theme has access to all of the HTML the portal generates. While you might need one extra file to be loaded (css gets minified for the whole theme anyway), you can easily add all of the (already) minified js files to your theme and include them in your templates/portal-normal.ftl implementation.
It would be as easy as having this section in portal-normal.ftl:
<head>
<title>${the_title} - ${company_name}</title>
<meta content="initial-scale=1.0, width=device-width" name="viewport" />
${theme.include(top_head_include)}
<script src="${javascript_folder}/my-minified-javascript.js"/>
</head>
Note: All but the <script> line is already in the default ftl file. This way you'll end up with two js files being loaded (the barebones or everything, plus your own), but that's not too bad. You can also add the minification to your theme's build process, so that you don't have to maintain the minified code manually.
Another alternative, which I haven't tried, is examining the use of Liferay's javascript minifier (e.g. in webapps/ROOT/html/common/themes/tom_js.jsp) to see how to utilize it to dynamically minify your files.
For completeness reason (maybe it helps someone else) I'm leaving my first answer here, which you couldn't use as you say in the first comment:
There's a section in portal.properties, to be overloaded in portal-ext.properties with this heading:
##
## JavaScript
##
#
# Set a list of JavaScript files that will be loaded automatically in
# /html/common/themes/top_js.jsp.
#
# There are two lists of files specified in the properties
# "javascript.barebone.files" and "javascript.everything.files".
#
# As the name suggests, the barebone list is the minimum list of JavaScript
# files required for most cases. The everything list includes everything
# else not listed in the barebone list.
#
# The two lists of files exist for performance reasons because
# unauthenticated users usually do not utilize all the JavaScript that is
# available. See the property "javascript.barebone.enabled" for more
# information on the logic of when the barebone list is used and when the
# everything list is used and how to customize that logic.
#
# The list of files are also merged and packed for further performance
# improvements. See the property "javascript.fast.load" for more details.
#
e.g. configure javascript.everything.files (the default is below that comment, for brevity I'm not copying that here)

using grunt-usemin to store minified references at dynamic path

In one of the project that I am working on, we need to create a folder named after version of the project and the minified JavaScript and CSS files are stored there. As per usemin's documentation, to update the reference in the HTML page, we need to add the build comment.
<!-- build:js 1.2.5/Combinedjs.js -->
<script src="file1.js"></script>
<script src="file2.js"></script>
<!-- endbuild -->
I want the name of folder mentioned above (1.2.5) to be dynamic and I don't want to change the build comment every time before running the grunt tasks. Does usemin provide any options to achieve this?
Take a look an alternative project named grunt-applymin: https://github.com/ghosert/grunt-applymin

WebSeal JSF Context path stripping Junction Name

We are using WAS & IHS as servers and WebSEAL as reverse proxy.
Application is developed using JSF 2.0 and using .xhtml pages for view.
Issue: Using ${facesContext.externalContext.requestContextPath} to generate the context for JavaScript and CSS files.
When the application is accessed through WebSEAL, getting correct context for JavaScript file, but the CSS context is missing the webSEAL junction name.
In Source Code:
JS is included as:
<script src="${facesContext.externalContext.requestContextPath}/js/jquery/jquery-1.6.1.min.js" type="text/javascript"></script>
CSS is included as:
var cssElement = document.createElement("link");
cssElement.setAttribute("rel", "stylesheet");
cssElement.setAttribute("type", "text/css");
cssElement.setAttribute("href", "${facesContext.externalContext.requestContextPath}/css/stylecontent.css");
Links Rendered on Browser:
For JavaScript(it has context name):
<script src="/junction/appcontext/js/jquery/jquery-1.6.1.min.js" type="text/javascript"></script>
For CSS:
<link href="/appcontext/css/stylecontent.css" rel="stylesheet" type="text/css"/>
Hence,
CSS files are not loading on the page.
Anyone has any hints?
Just incase some one is stuck with the same problem:
It got resolved by making some configuration at the WebSEAL junction level.
by default, WebSEAL looks for static resources on the the server itself, hence it strips the junction off.
Settings need to be applied to "look for resources under the junction"

Resources