Jsf component for html tag - jsf

Does it exist a way to create a <a name="bookmark"> in jsf?
I would like to create a list with general bookmarks so that i can point them with links, i would like to create these links with values I take dynamically.
h:outputLink doesn't have a name attribute.

Using outputLink like this:
<h:outputLink id="bookmark" />
generates the html:
<a id="bookmark" href="" name="bookmark"/>
So you could use the ID as your pointer?

Use Javascript or Output Filtering or a Custom Component
I think I would just use Javascript and patch up the anchors onload.
However, you could do output filtering. You could wrap the sub components inside your own and parse and modify the output. That does seem like a lot more work than just tweaking the document with JS.
If you are willing to create a custom component using facelets, a true but heavyweight solution, just go over here: How to add a new attribute to an existing JSF component.

Related

Should I use ui:fragment with the render attribute to conditionally render HTML tags in Facelets with JSF 2.2?

I am in the process of upgrading an old project from JSF 1.1 to JSF 2.2. Specifically, I am upgrading the JSF implementation from MyFaces 1.1 to MyFaces 2.2.12, replacing JSPs with Facelets and upgrading/replacing outdated tag libraries. I am mainly using Migrating from JSF 1.2 to JSF 2.0 as a guide.
The project used some tag library called htmLib with the namespace http://jsftutorials.net/htmLib in it's JSP pages. I can't find any documentation about this tag library anymore, neither on the jsftutorials webpage nor elsewhere, but apparently it was used to include plain HTML tags like <div> or <table> in JSP pages.
Since plain HTML tags can now be used in XML Facelets with JSF2, I am right now removing all occurences of tags from the htmLib taglib like <htm:div>...</htm:div> and replace them with plain HTML tags like <div>...</div>.
However, some of the tags used from htmLib contain the render attribute for conditional rendering, like this:
<htmLib:h4 render="someCondition">
...
</htmLib:h4>
Because plain HTML tags don't have a render attribute for this purpose, I was searching for an alternative way to conditionally render plain HTML tags and stumbled upon this answer on SO: How to conditionally render plain HTML elements like <div>s?
So, my idea is to replace a construct like the one above with something like
<ui:fragment render="someCondition">
<h4>
...
</h4>
</ui:fragment>
My questions:
Is wrapping HTML tags inside a <ui:fragment> tag with the render
attribute the recommended way to conditionally render HTML tags, or
is this method only valid and recommended for the case in the linked question?
Are there other ways to conditionally render plain HTML tags in Facelets that should be preferred?
Does the <ui:fragment> wrapping method work, no matter what kind of plain HTML is contained within it?
Can conditionally rendered <ui:fragment> blocks be nested?
There's no limitation in that. Not even for wrapping ui:fragment.
Basically:
In order just to control the inner content, with no extra HTML generation use
ui:fragment.
To generate an extra HTML span element, use h:panelGroup.
To generate an extra HTML div element, use h:panelGroup layout="block".
The HTML you have inside isn't a problem. JSF, being a server side framework, performs all the HTML building/rendering job in the server, so the JSF/facelet tags get translated to HTML before the response being sent. All the plain HTML you use inside will remain HTML.
However, beware of using tag handlers inside UI Components when migrating from 1.x. Tag handlers (ui:include, c:if, c:forEach) evaluate before the UI Components (which tipically contain rendered clauses). This has been a source of conflict in JSF 2.

Rendering hidden span text inside h:commandLink

We have an accessibility requirement to render certain command links with additional "off screen" text for screen readers. So we want to end up rendering something like (attributes omitted for clarity)
<a>Edit Details<span class="hiddenOffScreen"> for John Smith</span></a>
The problem is the standard jsf1.2 <h:commandLink> tag does not respect the escape attribute. I tried something like <h:commandLink escape="false" value="#{linkText}"/> where linkText evaluates to the contents of the a tag shown above but this renders the span tag literally (i.e escapes the < and >)
How best to go about meeting this requirement? I can of course easily add the span later with JQuery however, for my own education I'd like to have a try with a custom renderer - but not sure how I would hook in with the existing default renderer which adds the "onClick" event handler and associated javascript. My google-foo seems to have failed me when searching for custom commandLink renderer.
Bear in mind, this is JSF 1.2 and we cannot use any third party tag libraries as we're running on a braindead very old version of WebSphere Portal Server.
You can nest content, including other tags and/or implicit text, within the <h:commandLink> tag, instead of specifying text within its value attribute, to achieve your functionality:
<h:commandLink ...>
<h:outputText .../>
<span class="hidden"></span>
#{bean.someText}
</h:commandLink>
This will render exactly what you want.
Use < or > to write < >

Seam conditional render without parsing

I'm trying to make a conditional render in my Seam application (2.2.0), to display two different controls depending on a condition.
I'm using the s:fragment tag with the render attribute, but my problem is that I want whatever the control is displayed, to have the same id:
<s:fragment render="${editable}">
<rich:calendar id="entityDate"..../>
</s:fragment>
<s:fragment render="${!editable}">
<h:outputText id="entityDate".../>
</s:fragment>
My problem is that even when the render attribute set to false, the "not to be rendered" element is parsed, and I get an exception because of the duplicated id.
I also tried with the tag <ui:remove>, which effectively removes the element before the parsing phase, so I can have something like:
<span id="myId"/>
<ui:remove>
<span id="myId"/>
</ui:remove>
Unfortunately the <ui:remove> tag doesn't allow conditional logic. Has anyone found a way to solve this?
That's only possible when you use a view build time tag such as JSTL <c:if>.
<c:if test="#{editable}">
<rich:calendar id="entityDate" />
</c:if>
<c:if test="#{!editable}">
<h:outputText id="entityDate" />
</c:if>
(note that this is not going to work within an iterablte JSF component, such as <ui:repeat>, <h:dataTable> and so on)
After all, I strongly recommend to take benefit of the disabled attribute instead, if necessary with a good shot of CSS to hide the input field borders and so on. It'll minimize the JSF view boilerplate code.
<rich:calendar id="entityDate" disabled="#{!editable}" />
Disabled inputs are separately styleable by the CSS attribute selector element[attribute], e.g.
input[disabled] {
border: 0;
}
The above removes the border of input elements with the disabled attribute present so that it look like a normal output text.
"Solve"? There is nothing to solve here: two elements in a GUI can not have the same ID. Hardly unnatural or unsound?
It's like asking: "I have a database table with two rows, I would like them both to have the same primary key value, but somehow I get these errors... has anyone managed to solve the problem and circumvent the constraints?".
Or even closer analogy: "I have two spans, one of them is invisible (has style="display: none") I would like them both to have the same id - and browsers seem not to like it, despite one of the spans being invisible".
Bottom line: rendered on not rendered, each component is still a part of the view tree, and therefore has a UNIQUE id.
I have a suspicion that you want to have some "polymorphic" code that should work with the currently visible element. Using ID for such code IS WRONG. If you show us your use case, we might find a right way to achieve the effect.
I use selenuim myself in a seam environement and i recommend using defined ids whenever possible. First you have the ability to create smaller ids which is usefull for pagesize. Second the selenium test run alot faster if you use ids for referencing instead of other selectors. I have not yet found a selenium test where you cannot handle diffrent ids. Additionally if a code fails in jsf tree creation you see which id is failing.
I see you are using sfragment with editable or not. I use the sdecorate and give the decorate an id and then "just" ed for the input and vi for the outputtext for example. This makes it easy in selenium to check the availability of edit or view components.
Would you be able to get the same results you need by putting the id tag on the fragment?
So:
<s:fragment id="entityDate">
<rich:calendar render="${editable}" />
<h:outputText render="${!editable}" />
</s:fragment>

Can I replace h:commandLink with h:link

I'm creating a mobi-site using jsf. I got right to the end and found that more primitive phone browsers can't handle the javascript that commandLink creates. Is it possible to circumvent this with h:link or do you have any other suggestion as to how to get around this?
The <h:commandLink> generates a HTML <a> element with JS code in onclick to submit a POST form.
If your functional requirement is to submit a form with some data, then better use <h:commandButton>, it doesn't generate JS code.
If your functional requirement is to navigate to other page, then you should definitely use <h:link>, or <h:outputLink>, or just plain HTML <a>.

Is it suggested to use h:outputText for everything?

I'm new to JSF (just started learning about it 4 days ago) and I'm a bit confused about the usage of h:outputText. I know that is a simple tag, but in most examples I've seen, it's used to output very simple (no need to escape), non-i18n text. For example (taken from here)
<h:outputText value="Transport" />
which could be replaced by
Transport
So, I'm wondering if I'm missing something or if most of the examples I've seen are overcomplicated to the point of insanity.
If you're using JSF 2.x with Facelets 2.x instead of JSP, then both are equally valid. Even more, Facelets implicitly wraps inline content in a component as represented by <h:outputText> (in other words, it will be escaped!).
Only whenever you'd like to disable escaping using escape="false", or would like to assign id, style, onclick, etc programmatically, or would like to use a converter (either explicit via converter or implicit via forClass), then you need <h:outputText>.
I myself don't use <h:outputText> whenever it is not necessary. Without it, the source code becomes better readable. You can just inline EL in template text like so #{bean.text} instead of doing <h:outputText value="#{bean.text}">. Before JSF 2.0, in JSP and Facelets 1.x, this was not possible and thus the <h:outputText> is mandatory. If your IDE gives warnings on this, it's most likely JSF 1.x configured/minded.
The example you quote is written in XHTML - which is XML. A standalone 'Transport' may not be allowed at the position you want to put it in, so that you need to "transform" it into valid xml.
IIrc this what is called facelets and the default in JSF2, while in JSF1, the presentation code could be done with JSP tags as default and facelets was an alternative that many developers were using).
h:outputText tag is required only if you are rendering the text based on some render condition.
eg: <h:outputText value="Transport" rendered="#{myBean.displayText}"/>.
If its a simple output statement then there is no need of using the tag; you could just use: Transport

Resources