I am using lots of commandLinks in my app. For them to work, JSF generates some wild Javascript ( function dpf(f) {var adp... ). Sadly, the script-tag destroys my layout. (It really does - I am sure about that).
Is there a way to force JSF to generate the script-tag somewhere else?
Maybe you can try to externalize your Javascript.
Instead of putting the Javascript code within your page, it will only include a script tag that points to a Javascript file.
To do that, modify your web.xml file to have that:
<context-param>
<param-name>com.sun.faces.externalizeJavaScript</param-name>
<param-value>true</param-value>
</context-param>
Related
I am following this guide: http://balusc.blogspot.com/2009/12/uploading-files-with-jsf-20-and-servlet.html and everything has gone smoothly except that I noticed it would only work if my web.xml is mapped to .jsf. Any ideas?
I am on tomcat 7.0.12 jsf 2.1.17 from mojarra and that is why I'm not using Tomahawk.
You need to make sure that the URL pattern of the filter mapping of the file upload filter also matches the desired JSF requests. Assuming that your FacesServlet has a <url-pattern>*.html</url-pattern>, then this should do:
#WebFilter(urlPatterns={"*.html"})
Even better, if you're going to use it exclusively for file uploads via JSF, then you can also map it on the servlet name of the faces servlet. Assuming that you've a <servlet-name>facesServlet</servlet-name>, then this should do:
#WebFilter(servletNames={"facesServlet"})
Is it possible to remove all styling from Primefaces components? I mean, the component set is good but having to manually override every tiny bit of each component to make the component style fit the overall design of my application isn't good. I can't use hours on using Firebug to find which classes etc it uses and all that.
So is there no way to remove this and only use the components for their functionality and provide your own design instead of being forced to use the default....or one of the "themes"?
Set primefaces.THEME context parameter to none and you'll get a functional ui with no styles.
<context-param>
<param-name>primefaces.THEME</param-name>
<param-value>none</param-value>
</context-param>
You don't need to spend hours editing styles. Styling of PrimeFaces is done via shared styles like ui-widget-header, ui-widget-content which you can customize via the themeroller web form. I don't think JSF and theming can get any easier than PrimeFaces.
PrimeFaces inserts two CSS files by default, theme.css and primefaces.css. You can remove theme.css by putting the following to web.xml:
<context-param>
<param-name>primefaces.THEME</param-name>
<param-value>none</param-value>
</context-param>
Then you can overwrite primefaces.css by creating an empty file in:
WebContent/resources/primefaces/primefaces.css
Older PF versions (<6.0)
If you want to use the primefaces with your own css's wouldn't it be easier to create your own theme using the jQuery UI - ThemeRoller ?
Here's a link to how you create your own Theme for PrimeFaces
Newer PF versions (6.0 and up)
More recently PrimeFaces introduced the 'Designer API' Since PF components have more features, the themeroller is not that suitable anymore. The Designer API is SASS based and allows you to create really good themes
Create own theme as #Daniel said. I just want to add :
For partial styling you don't have to firebug everything, primefaces user guide covers style classes for each element. It contains also other very useful info and tips (also part about skinning). So use it as your first source when you find yourself struggling with anything about primefaces.
The docs say put it in META-INF/skins, but RichFaces doesn't find it there, or anywhere else I tried.
I use Tomcat with MyFaces 2 JSF and RichFaces 4 components
Update: I posted the Exception that Tomcat throws at http://paste.lisp.org/display/128193
Update 2: In response to BalusC's comments below, I established that specifying org.richfaces.SKIN in uppercase also doesn't help.
The community forums notes that the my.skin.properties file (note: pluralizing skin to skins--as in my.skins.properties--is incorrect) must be in WEB-INF/classes/META-INF/skins.
In NetBeans, for example, this can be accomplished as follows:
Switch to the Files tab.
Create a new directory at the same level as src and web called resources.
Create a sub-directory in resources called WEB-INF.
Copy my.skin.properties into resources/WEB-INF.
Update web.xml to contain:
<context-param>
<param-name>org.richfaces.skin</param-name>
<param-value>my</param-value>
</context-param>
Note: Some places, including the formal documentation, refer to the skin param-name as org.richfaces.SKIN, which is incorrect. The param-name must be all lowercase.
Next:
Update build.xml to contain:
<target name="-post-dist">
<war destfile="${dist.war}" update="true">
<zipfileset dir="${basedir}/resources/WEB-INF" prefix="WEB-INF/classes" />
</war>
</target>
Press Shift+F11 to rebuild the application.
Verify that the archive (e.g., Project.war) contains the following file:
\Project.war\WEB-INF.classes\my.skin.properties
When deployed, the application should find the properties file.
I'm having a problem with charset encoding in my web application (JSF 1.2, Spring and Tomcat 7), and I've ran out of ideas of what to test to see where it is going wrong.
Whenever I submit something like 'çã' I get 'çã': that means my data POSTed as UTF-8 is being converted to ISO-8859-1 somewhere in the JSF life cycle.
I know that the wrong conversion is UTF-8 to ISO-8859-1 cause it's the same output for:
System.out.println(new String("çã".getBytes("UTF-8"), "ISO-8859-1"));
I believe that the wrong conversion is somewhere in the JSF life cycle (can it be before?) cause I set up a validator in my MB:
public void debugValidator(FacesContext context, UIComponent component,
Object object) throws ValidationException {
System.out.println("debug validator:");
System.out.println(object);
System.out.println("\n");
throw new ValidationException("DEBUG: " + object.toString());
}
and its message returns as: "DEBUG: çã"
I have in all my .xhtml pages the first line as <?xml version="1.0" encoding="UTF-8"?>.
I'm using Facelets, which according to BalusC's article uses UTF-8 by default
So it wouldn't need but I set up anyway, Spring's CharacterEncodingFilter in my web.xml to set the request character encoding to UTF-8.
I put URIEncoding="UTF-8" in Tomcat's server.xml file, just to guarantee
It is not my browser's fault, it prints the same thing in the console, and my environment is all UTF-8.
Do you have any idea of what more can I test? What could be my wrong assumption?
Thanks in advance!
BalusC's answer helped me to better understand the problem, but what solved it for me was putting the Character Encoding Filter as the FIRST filter in the chain (putting it above all the others in the web.xml file).
This is the filter I used:
<!-- filter enforcing charset UTF-8 - must be first filter in the chain! -->
<filter>
<filter-name>characterEncodingFilter</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>utf-8</param-value>
</init-param>
<init-param>
<param-name>forceEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>characterEncodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Apparently, the data was read before the parameter was set by the filter.
I got the hint from this page: http://tech.top21.de/techblog/20100421-solving-problems-with-request-parameter-encoding.html
Thanks everybody!
The symptoms indicate that the browser has sent the data using ISO-8859-1 encoding instead of UTF-8. This in turn means that the HTTP response Content-Type header is not been set with the proper charset attribute. In for example Firebug, you can find it out as follows:
You're right that Facelets uses UTF-8 by default. But very early versions of Facelets weren't programmed to use UTF-8 by default. See also among others issue 46 and issue 53. Facelets is currently at 1.1.15.B1.
As to your attempts to fix it, the presence of the XML prolog is not strictly necessary and its encoding isn't used in any way to set the response encoding, it's only used by the XML parser to decode the inputstream to characters. Spring's filter is also not necessary, but that it didn't solve the problem after you added it is enough evidence that it's the client who has sent the data as ISO-8859-1.
Check, if your form has enctype="multipart/form-data".
See this question form more information
Should I use JSF2 resources instead of plain html like <link href... or url(image.png)? What are the benefits? For me this is a bit annoying when web-designer creates layout with XHTML, CSS and all that stuff and I need to spend time to replace plain HTML paths and tags to JSF resource tags like#{resource[...]}.
Is there any other way? Like to put all CSS/image files in web root and use normal links?
Your choice.
The major benefit is that you can declare them on a per-component basis. If you need to include them on every single page anyway, then the benefit is little. But if you need to include component-specific CSS/JS code in for example a composite component which is reused more than once in a single view, then for example an <h:outputScript> in a composite component would end up in it being included only once instead of that many times as the composite component is been used as would happen with <script>. The same applies to the #ResourceDependency annotation on real UIComponent classes.
Please note that you are not required to use JSF2 resources only. Just plain vanilla <img>, <link>, <script>, etc is also perfectly fine. It can even point to the JSF resources folder.