Default.css is not loaded for openfaces - jsf

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.

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");

Why is Ajax4JSF Script automatically defined on top of HTML page?

I am using JSF 1.1 in a web application. When I run the app in IE 5 it has some UI problems. so, I used the meta tag to open the page in Edge compatibility.
Now I have used the Ajax4JSF tag library with URI - https://ajax4jsf.dev.java.net/ajax
The meta tag works only when its written above any other line in the head tag. The problem is that the Ajax4JSF library automatically declares a script in first line of the head tag.
It pushes my meta tag to second line causing the lose of Edge compatibility.
meta tag is - http-equiv="X-UA-Compatible" content="IE=edge"
script declared is - /*appName*/a4j.res/org.ajax4jsf.framework.ajax.AjaxScript.jsf
How to resolve this issue.
Thanks in advance.

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?

What is the equivalent tag for ScriptCollector?

We want to migrate our project from IBM WebSphere 6.1 to Tomcat 6, but in our JSP-JSF UI pages we have extensively used below IBM JSF tags.
ScriptCollector
PanelRowCaregory
PagerWeb
OutPutSelections
InputRowSelect
InputHelperDatePicker
InputHelperAssist
ConvertMask
And to replace above tags, we are trying to find the equivalent tags from Sun JSF or any other open source libraries, but we didn't find any equivalent tags.
I wanted to know whether any body has already worked on this kind of migration project, if yes can you please share the equivalent tags?
or if you solved it differently even that info also will be useful.
Thanks in Advance.
There's no standard JSF equivalent for the <hx:scriptCollector> (although the JSF 2.0 <h:head> comes close). The <hx:scriptCollector> is only required by those IBM-specific <hx:xxx> components. It's designed to collect all JavaScript files required by those <hx:xxx> components and then render the desired <script> tag(s) without potential duplicates when multiple components require the same JS files. It's not required by any standard JSF component.
In other words, just get rid of it without replacement.
As to other tags, just check the available standard components in tag documentation or Java EE tutorial. If none is available, just pick a component library like PrimeFaces or RichFaces. If you still can't figure out, ask an individual question for the particular tag.

Unable to find or serve resource, dataList.xhtml, from library, org.apache.myfaces.custom

I am trying to implement pagination in JSF and Hibernate.
I have these statements on my html page.
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:f="http://java.sun.com/jsf/core"
xmlns:t="http://myfaces.apache.org/tomahawk">
<t:dataList value="#{med.pages}" var="page">
I have included tomahawk20-1.1.14-bin - the jar files in /build/web/WEB-INF/lib and tomahawk-examples-1.1.14-bin - all the war files in /build/web/WEB-INF/src/META-INF
But, I get this error : Unable to find or serve resource, dataList.xhtml, from library, org.apache.myfaces.custom.
What should I do ?
I think it is caused by Mojarra (it gets confused reading the .taglib.xml, even if is valid syntax to use that file for composite and normal components, it was clarified in the new 2.2 spec) Use MyFaces JSF implementation instead to get it fixed.
I believe this is a tomahawk issue.
The JSF 2.2 spec mentions this:
As specified in facelet taglibrary schema, the runtime must also
support the composite-library-name element. The runtime must
interpret the contents of this element as the name of a resource
library as described in Section 2.6.1.4 “Libraries of Localized and
Versioned Resources”. If a facelet tag library descriptor file is
encountered that contains this element, the runtime must examine the
element in that same tag library descriptor and make it
available for use in an XML namespace declaration in facelet pages.
And there's also this in the spec:
If you want to employ a cc with a namespace other than
http://java.sun.com/jsf/composite/libraryName you need to have a
taglib file that declares composite-library-name. Currently you must
not declare any tag elements in such a taglib file. All the tags in
such a library must come from the same resource library.
In the case of tomahawk, composite-library-name does not point to a resource (a directory name under META-INF/resources), hence the errors.
The simple solution here may be to remove the composite-library-name element from the tomahawk.taglib.xml file (if it's not needed for any other purpose of course). I haven't tested it however.

Resources