With the JSF/Seam/RichFaces stack, is there a way to mark up comments (on XHTML pages) so that they will not be included in the HTML output? I.e., something like JSP's <%-- comments --%>, as opposed to normal <!-- comments -->.
I heard that facelets.SKIP_COMMENTS context-param migth do this for normal HTML comments, but is there any other option? (After all, there might be some comments that you want included in the page output and some that you don't.)
Found an answer in a thread on the JSF for nonbelievers forum of IBM developerWorks:
<ui:remove><!--
<tags you want to remove/>
--></ui:remove>
See the official Facelets documentation of ui:remove for more information.
Use the facelets.SKIP_COMMENTS context-param. You won't need comments in the generated pages. They are not meant to be human-readable anyway.
Related
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.
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 want to understand the basic mechanism of <ui:remove>. As per my knowledge, <ui:remove> is basically used in conjunction when basic HTML stuff is part of your Facelets page. When you want, when rendering of the Facelets page happen, it should ignore this part of HTML code, we can use the <ui:remove> tag.
Still I am confused about practical implications of <ui:remove>. How often we need to use this Facelets tag? Additionally, the Facelets page is not compiled everytime when the page is hit.
It's useful to remove content which is required during design time, but not during run time, such as comments, some stubbed content (e.g. "lorem ipsum") which aids in filling up the page content to fit the layout in visual designers such as Dreamweaver, etc.
If you're not a page designer, but already retrieve designs as PSD/AI/etc, it's indeed useless to you.
See also:
Is there a way to run a JSF page without building the whole project?
Outcommented Facelets code still invokes EL expressions like #{bean.action()} and causes javax.el.PropertyNotFoundException on #{bean.action}
JSF display HTML comment
How can I write good documentation for xhtml jsf pages?
I might use <!-- comment -->, but that clutters the code very much, and makes it sometimes more unreadable than without comments.
Is there any way to do HTML comments or inline documentation better?
This may not be the answer you are looking for, but might be an alternative to massive html commenting.
I found that it is much easier (and logical) to document the backing bean methods, than the xhtml itself. The only thing I use the html comment for is to identify large parts/areas on my page so its easier to find.
having readable and well named variables/logic is much better than any comment.
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.