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");
Related
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?
I'm making JSF composite component, something simple with the following code:
<cc:implementation componentType="timePickerComponent">
<div id="#{cc.clientId}" style="#{cc.attrs.style}">
<h:outputScript name="js/timepicker/timepicker_helper.js"/>
<p:autoComplete id="timepicker"
scrollHeight="200"
onfocus="openAutocompletePanel(this);"
widgetVar="#{cc.attrs.widgetVar}"
completeMethod="#{cc.completeMethod}"
value="#{cc.timeLocal}"
size="5"/>
</div>
</cc:implementation>
And timepicker_helper.js which contains only single function:
function openAutocompletePanel(field){
console.log("ups");
console.log(field);
}
When I try to debug openAutocompletePanel function in Chrome developer tools, i.e. defining breakpoints at the beginning or at the middle of the function it doesn't work. But function itself is invoked, it prints to console.
When I added row debugger; in the middle of the openAutocompletePanel, it has stopped at this point but instead of file timepicker_helper.js Chrome has opened file VM3339.
There is snapshot of my screen:
This isn't first time I debug JSF's javascript in Chrome but first time I've met this issue. What could cause such behavior?
Thank you.
UPDATE:
Ok, it was my fault.
BalusC said many time that when you include javascript in composite component you should specify target="head" otherwise it will be loaded multiple time.
When I changed loading sentence to <h:outputScript name="js/timepicker/timepicker_helper.js" target="head"/> the problem has gone.
I cannot consider this as answer because I not sure 100% if I right.
Sorry, cant put it into comment, so put it as an answer...
The such behavior could be if timepicker_helper.js is loaded and executed by JavaScript eval(); function.
In this case developer console will show the common file where your origin file has been included, like you see: VM3339.
And debugger; is the only way to break inside in this case.
We're trying to use the <f:view contracts="xxx" /> feature from JSF 2.2, with many simultaneous contracts, as "contract1,contract2".
In our contract1, we have a file style1.css, and in our contract2, a style2.css. We include both in our views through <h:outputStylesheet /> tags.
If I only use contracts="contract1" in the view, JSF logs than style2.css is missing, which is logical.
If I use contracts="contract1,contract2", JSF imports both style1.css and style2.css, but with a faulty url (it uses &con=contract1 instead of &con=contract2 to get the resource).
Is it a bug? Is it normal? I can't find any documentation about the use of many simultaneous contracts.
That's normal behaviour, as I've found in the Apress Pro JSF and HTML 5 text book. An excerpt:
It's possible to map multiple contracts to a single mapping. In that case, it will go through each contract sequentially to look for the required templates. Once a template has been found, it will stop processing other templates.
As to why it's allowed, if all it's going to do is pick the first suitable option, I'm with you on the fact that it may be pointless after all.
Reference:
Apress Pro JSF and HTML 5
I am getting title as error and it is asking
Did you use head instead of h:head?
I started to use OpenFaces, add JAR to library, and add namespace
xmlns:o="http://openfaces.org/"
I can see components working right but without styling.
I am using a tree, I can expand it but can not close it.
Should I add some css to somewhere?
First, I suppose that you've used <h:head> tag in your xhtml page (and not the plain <head> tag), as the error message suggests...
Other than that there's nothing that you should do to make it work without this error (if you're using JSF 2.x based version of OpenFaces).
If you're using OpenFaces 3.0 release (with JSF 2.x) then there was a bug where this error was shown in some configurations despite having the <h:head> tag in the page. Try the current nightly build where this problem is fixed.
I've been doing some searching around and couldn't find this topic anywhere. My company wants to use an HTML doctype but wordpress outputs XHTML by default. I've seen plugins and I would use these but this site will probably outlive the development of said plugins. Plus it's something else to account for when updating or building new sites.
If I use an XHTML doctype how will HTML5 browsers render it? Will they be backwards-compatible with old doctypes?
Edit 1: It is actually recomended that in order to make the transition to HTML5 easier that you try to follow the XHTML structure when writing any HTML.
There will be additional options and types with XHTML in HTML5 but a lot of it is based on the structure in which you are writing your HTML. The X simply means that it is moving to more of an XML base.
To go along with Kayla's input, you will want to make sure that all tags are being closed:
<br/> Instead of: <br>
You will also want to make sure to put quotations around any parameters:
Instead of: <a href=value></a>
Browsers have been slowly adopting the XHTML structure. This might mean that HTML that is formatted without end tags/etc might look a little different in IE 6 than in newer brower versions. Hope that helps!
It is not recommended to use the XHTML 1.0 or 1.1 doctypes for your HTML5 pages, one because its unnecessary and two your markup won't validate when you use the newer tags. Here is a quick guide on using XML syntax in HTML5 a.k.a. XHTML5.
Update: As noted bellow checkout the W3C Specification.
I am not sure what you are asking. What do plugins have to do with DTD?
Yes, any browsers that supports HTML5 is backwards compatible with (X)HTML, you can mix and match all you want. And basically as long as you are writing tags like:
<div>Hi</div> or <p>There</p>
instead of
<DIV>Hi</DIV> or <P>There</P>
the rest is just semantics.
HTML5 began life specifically because browsers manufacturers wanted to make sure that changes they introduced were backward compatible with existing web pages, in contrast to the now defunct XHTML 2, which was shaping up to be non-backward compatible.
So yes, your XHTML doctype will work just fine in HTML5 browsers.
As far as I know all modern browsers that are adding HTML 5 support will continue to support HTML 4 and XHTML for the foreseeable future so you should be fine.
If you're using Wordpress though stick with XHTML. It'll be supported for a long time to come in all browsers and most Wordpress plugins are designed to output XHTML.