I'm facing some problems using CDATA blocks inside h:outputscripts with MyFaces 2.0... but I don't know exactly if I should avoid using CDATA with JSF2 or if it is because I do things wrong.
Maybe it is because I use many scripts in many Composite components...
The fact is that when I have some composite components that contain scripts with surrounded by CDATA blocks, other scripts in the page doen't work.
Removing CDATAs solves the issue.
Nevertheless I've had an issue where using CDATA blocks made some of my Composite components bug saying a property of the component can't be found on class NamingContainer when trying to render the component using f:ajax render attribute. Here is the workaround.
Removing the CDATA surrounding my scripts solved the problem.
So my question is : am I the only one having troubles with CDATA blocks and JSF2 (MyFaces) ?
This is a known issue. See MYFACES-3339 for details. It was already fixed, so you can try the latest code HERE, and it will be included on 2.1.4 and 2.0.10.
I can't answer if you're the only one having problems with it. I can at least answer that having JS code plain in a XML file is a poor practice. JS code is not well formed XML. Fiddling with escaping XML-special characters in JS code or putting JS code in CDATA blocks is plain ugly. That it gives troubles in JSF ajax response is in turn a different story. Technically, that would have been a bug in the JSF implementation used. But from the other side on, you're actually practicing a poor practice.
Just put JS code in its own .js file which you reference by <h:outputScript>.
<cc:implementation>
<h:outputScript library="foo" name="js/your-cc-script.js" target="head" />
...
</cc:implementation>
Related
[Stackoverflow disallows the word help in the title. Hence the h3lp]
We are in the proces of moving our code from Orbeon 3.9 to Orbeon 4.x. One of the many things that changed is the behavior for display of xforms:alert and xforms:help. Example code:
<xforms:input ref="#code">
<xforms:alert ref="$resources/required-field"/>
<xforms:help ref="$helptext"/>
</xforms:input>
In Orbeon 3.9 the alert is displayed as a red img with a white exclamation mark that has the text as tooltip, only if the binding fails. The help is displayed as a blue-ish image with a question that activated a tiny pseudo window containing the (potentially large) help text.
In Orbeon 4.7 the alert text is displayed as-is, no image and no condition based on binding. This interferes with a carefully designed interface as it takes up a lot more space. The help text is not displayed at all because .xforms-help has display: none;. Overriding that doesn't work because the text would then just be displayed inline.
I could not find documentation for these changes. Does anyone know the rationale and how to make "alert" and "help" useful yet again?
There are two changes with Orbeon Forms 4.x which might be relevant to this:
The HTML layout of elements has changed a bit. This means existing CSS might have to be adapted. You can check this by comparing the HTML produced by 3.9 vs. 4.x for a given page. With 4.x, all form elements, for example, are wrapped within a <span> or <div> element.
Form Runner uses Twitter Bootstrap as a CSS library. But the Bootstrap CSS files are also included for non-Form Runner pages.
This said, "red icon" alerts should still work, see for example the good old Espresso Order or Bookcast demos.
If you see alerts inline and unconditionally, it means that somehow the proper CSS doesn't apply, either because of the HTML layout change mentioned above, or because some CSS files are missing.
Look at this post : http://blog.orbeon.com/2014/01/improving-how-we-show-help-messages.html
and this : http://discuss.orbeon.com/how-to-use-the-quot-new-quot-xforms-help-in-4-5-td4658348.html
julien
I am building out a dynamic table using JSTL and was hoping to make use of the c:out tag to help build out some expressions, but am not able to find that tag available among the other JSTL core tags.
I have the following namespace being used:
xmlns:c="http://java.sun.com/jsp/jstl/core"
and made sure my web.xml file was set to use the 2.5 spec found here
https://stackoverflow.com/tags/jstl/info
but still only find catch, choose, forEach, if, otherwise, set, and when.
Additionally, I tried importing the JSTL 1.2.1.jar libraries as well with no success.
So, should the c:out tag be available for me to use in JSF2 ? If so, what steps am I missing?
Regards,
Mike
The <c:out> indeed not available in JSF2 Facelets. You don't need it in JSF2 Facelets anyway. Just use the JSF equivalent <h:outputText>,
<h:outputText value="#{bean.text}" />
or even better, just put EL in template text,
#{bean.text}
It will already be implicitly XML-escaped if that's your sole concern (and was during old JSP2 ages actually the sole reason why <c:out> is been used; in JSP1 the tag was simply mandatory in order to display a bean property as EL in template text wasn't supported in JSP1). The <c:out> offers no additional advantages over those standard JSF2 Facelets ways, that's why it's been removed from the JSTL subset for Facelets.
See also:
Is it suggested to use h:outputText for everything?
I am not sure what are the benefits of using <f:view> and <f:subview>.
I noticed that one could write JSF pages without using them.
What are the benefits of using those tags?
<f:view>
The <f:view> is only useful if you want to explicitly specify/override any of the available attributes such as locale, encoding, contentType, etc or want to attach some phase listeners. E.g.
<f:view locale="#{user.locale}" encoding="UTF-8" contentType="text/html">
If you don't specify it, then the sane JSF defaults will just be used instead, which is respectively UIViewRoot#getLocale(), UTF-8 and the closest match of Accept request header. Noted should be that the closest match of Accept request header isn't always entirely right. Sometimes it results in application/xhtml+xml because of the presence of .xhtml extension in the URL in case of Facelets and the webbrowser not being configured to interpret it as text/html by default (like MSIE). You'd really like to avoid this wrong content type by explicitly setting it to text/html.
Note that it doesn't matter where you put it in the template. You can even put it in template client as immediate child of <ui:define>. However, canonical place is as immediate child of <html> and thus wrapping both <h:head> and <h:body>. This is also the way how it's done in legacy JSP where it's actually required. In Facelets it's optional and accounted as meta data.
See also:
Our XHTML wiki page
Is it possible to use JSF+Facelets with HTML 4/5?
JSF 2.0 not rendering any page
<f:subview>
The <f:subview> will create another naming container context. This is particularly useful when you want to reuse an include file which in turn contain fixed component IDs more than once in the same view root, otherwise you will get duplicate component ID errors. However, since JSF 2.0 such an include file can better be a composite component which is by itself already a naming container.
If you don't specify it, then it won't harm if you don't reuse a component with the same ID physically multiple times in the view.
See also:
Why <h:panelGroup> id is not found when I access through <f:subview> tag?
Binding attribute causes duplicate component ID found in the view
Difference between <f:subview> and <ui:composition> tags
I am trying to parse a bunch of JSP files and find places with hardcoded strings. E.g.
<h:outputText value="I am hardcoded" styleClass="someClass" />
<my:customTag value="I am hardcoded too" />
Currently I am using jsoup to do so. It seems great as an HTML parser, however if I make changes to the document and write it out to a file all of the case sensitive JSF tags and attributes are changed to lowercase. Are there any Java libraries that can parse a JSP file, let me modify some attribute values, and let me write out the JSP?
Or better yet is there a way to tell jsoup not to change the casing of my elements and attributes?
It may not be the case for other people, but it turns out replacing all of the toLowerCase() calls in jsoup worked well enough for me.
I posted this to the PrimeFaces user forum but I think they are too busy to look into it, so I thought I would try here.
I have server-side string that has markup in it, so when I want it rendered I do this:
<p:panel>
<f:verbatim>
#{daBean.markedUpString}
</f:verbatim>
</p:panel>
This works fine, but not if the same tag is used inside a p:dataTable -- either with or without the p:panel enclosure. What gets rendered is a div class="ui-dt-c" element with nothing in it. To test, if I take out the f:verbatim tag the marked-up text gets escaped and rendered.
I don't know if this should be considered a bug or not, but does anyone know of a work-around for this? This is with PrimeFaces 3.0.M3.
The <f:verbatim> tag is intented to hold plain text/HTML, not JSF components nor EL expressions. The tag is a leftover from JSF 1.0/1.1 ages when it was not possible to inline plain text/HTML between JSF components. The tag is deprecated in JSF2. You do not need it anymore.
Your concrete functional requirement is thus displaying some HTML string from a managed bean unescaped. For that you should use <h:outputText> with escape="false".
<h:outputText value="#{daBean.markedUpString}" escape="false" />
See also:
Getters inside f:verbatim called before form submission
JSF/Facelets: why is it not a good idea to mix JSF/Facelets with HTML tags?
What are the main disadvantages of Java Server Faces 2.0?