p:inputText does not remember values(autofill does not work) - jsf-2

How to make p:inputText remember values? I have autocomplete="on" in there but it doesnot work.
Please find the code below:
<p:inputText id="username_email" value="#{BsnsSgnupLgnBen.userName}" required="true" size="25" autocomplete="on" >
<f:validateLength minimum="0" maximum="50" />
</p:inputText>
Any clue?

Browser-builtin autocomplete/autofill is only triggered during synchronous page load. So, if you're loading your forms by ajax, then autocomplete/autofill is not triggered. Apparently that's what happening here. The solution is obvious: you need to load your forms on which you need autocomplete/autofill synchronously. E.g. by <h:link>, <h|p:button>, etc or a navigation with faces-redirect=true.
As the particular input field seems to be part of a login form, I just want to add for sake of completeness, another thing to take into account is that usernames/passwords of login forms (a form is considered a login form when it has at least one <input type="password"> field) are not remembered for autocomplete/autofill when the login itself is submitted by ajax. You should perform the actual login synchronously. You can use <p:commandButton ajax="false"> for this.
Please do note that the concrete problem has completely nothing to do with JSF. It's in the context of this question merely a HTML code generator. You'd have had exactly the same problem when using a different server side language generating the very same HTML output and even when using plain vanilla HTML.

I think you should use the autoComplete component from Primefaces http://www.primefaces.org/showcase/ui/autocompleteHome.jsf

Related

inital value with setBooleanButton in primefaces

I'm using Primefaces and MyFaces. I would like to use the selectBooleanButton component, to control visibility of other components within a long and rather complex form.
simplified sample code:
<p:selectBooleanButton
onLabel="Comment" offLabel="Comment"
onIcon="ui-icon-check" offIcon="ui-icon-close"
value="#{not empty myBean.comment}"
onchange="toggleDisplay(this.checked,'myForm:commentPanel');" />
<h:panelGroup id="commentPanel"
style="display:#{empty myBean.comment ? 'none' : 'block'}">
<p:inputTextarea value="{myBean.comment}"/>
</h:panelGroup>
The javascript in the onchange attribute simply toggles the display style from none to block and vice-versa to hide or unhide the panel group. I want/need the components to remain in the view, I do not want to use rendered attributes to remove them completely.
Where I get into trouble is because of the EL construct used in the value attribute of the setBooleanButton component. I do realize that this EL statement is not compatible with the set operation, and this results in an exception.
What I want to be able to do is when the form is loaded, have the initial status of the selectBooleanButton components set to 'on' when the comment property has some existing text it, and 'off' when it is empty. I am looking for a way to work around this that would not require me to create a property in the model for each and every instance where I want to hide the panel, as that would result in dozens and dozens of properties because my real world form is very large with many of these comment sections.
I also posted this question on Primefaces forum, and did not receive any answers there either, so at this time there may not be a great solution to this problem, or at least not one that has been shared. What I ended up doing to work around this is to create two versions of the component, and use the rendered attribute to control which one is used, like this:
<p:selectBooleanButton
onLabel="Comment" offLabel="Comment"
onIcon="ui-icon-check" offIcon="ui-icon-close"
value="true" rendered="#{not empty myBean.comment}"
onchange="toggleDisplay(this.checked,'myForm:commentPanel');" />
<p:selectBooleanButton
onLabel="Comment" offLabel="Comment"
onIcon="ui-icon-check" offIcon="ui-icon-close"
value="false" rendered="#{empty myBean.comment}"
onchange="toggleDisplay(this.checked,'myForm:commentPanel');" />

Unique ID for JSF composite component inside dataTable

I am using PrimeFaces 3.2 with JSF 2 in a glassfish 3.1.2.
I have a <p:dataTable> which displays search results containing information on different issues (the issues are assigned to users).
If somebody clicks on the icon of the assigned user a <p:dialog> pops up.
The user icon and the according dialog are implemented using a composite.
Inside the composite I am using some jQuery functions which need a unique ID for each dialog component - I am not able to find a way to solve this problem.
My investigations so far:
I need to set the widgetVar attribute, which works fine as long as I have only one user in the list but it seems that inside a dataTable the widgetVar is not unique for many composites.
Since the user can be displayed more than one time inside the search result, I am not able to setup an widgetVar like this:
<ui:param name="myWidgetVar" value="widget_#{user.id}" />
and use it this way
<p:dialog widgetVar="#{myWidgetVar}">
also using #{cc.id} does not resolve the problem 'cause it only returns the id of the widget without the naming-container part which is always the same.
I need the complete id as displayed in html (e.g.: form:jdt123:dialog:456) - how can I get this?
Does anyone know what to do?
Thanks Pete
My solution is using #{cc.clientId} which I did not know yet.
This gives me the complete html element id constisting of the series of identifiers glued with the UINamingContainer#getSeparatorChar (e.g.: form:jdt123:dialog:jdt456)
Thanks for the answer. You solved my unrelated problem, but I think I stumbled on another solution for your problem.
From the PrimeFaces user guide (http://primefaces.org/documentation.html):
8.2 EL Functions
PrimeFaces provides built-in EL extensions that are helpers to common use cases.
Common Functions
Component
<h:form id="form1">
<h:inputText id="name" />
</h:form>
//#{p:component(‘name’)} returns ‘form1:name’
WidgetVar
<p:dialog id="dlg">
//contents
</p:dialog>
<p:commandButton type="button" value="Show" onclick="#{p:widgetVar(‘dlg’)}.show()" />
It looks like you would be most interested in the WidgetVar implementation.

Richfaces: a4j:commandLink with both onclick and actionListener

I am using Richfaces 4.1.0.Final.
I have a problem similar to this post, however the remedy (return true;) does not work for me.
It may be the version of Richfaces I'm using, but upgrading is very difficult for me and I'd like to verify that's the problem first or preferably find a workaround.
I have an a4j:commandLink link in a rich:column in a rich:dataTable in a rich:tab within a rich:tabPanel. I'd like to click the link, have the column data saved to the backing bean (e.g. via f:setPropertyActionListener) and then have the user switched to another tab for editing (using: #{rich:component('TabPanel')}.switchToItem('EditTab');)
If I use oncomplete for the javascript piece, the handler fires, but the switchToItem piece doesn't work. If I instead use onclick for the javascript piece, the handler doesn't fire, but the switchToItem piece does work. I need both.
Does anyone know of a solution? Is this a known problem in this version of Richfaces? Does anyone know how I can work around this problem using other components?
I apologize in advance, but I cannot post my code.
Thanks,
John
Update:
I upgraded to Richfaces 4.2.2.Final, but there was no improvement. Apparently it is impossible to use a4j:commandLink with a f:setPropertyActiopnListener if you also use the oncomplete to switchToItem another tab.
Ok,
I added a second f:setPropertyActionListener to set the TabPanel's activeItem to EditTab. Then I added oncomplete="location.reload(true);" to refresh everything and redraw with the correct active tab.
It works, but I'd still like to hear a better approach.
I tried it with RichFaces 4.2.2.Final and it worked for me when I used onclick:
<rich:dataTable value="#{model.simple}" var="item">
<rich:column>
<a4j:commandButton value="click me" onclick="#{rich:component('tabPanel')}.switchToItem('tab3');" action="#{bean.action}">
<a4j:param assignTo="#{bean.parameter}" name="param" value="#{item}"/>
</a4j:commandButton>
</rich:column>
</rich:dataTable>
<rich:tabPanel id="tabPanel">
<rich:tab name="tab1">tab 1 content</rich:tab>
<rich:tab name="tab2">tab 2 content</rich:tab>
<rich:tab name="tab3">tab 3 content</rich:tab>
</rich:tabPanel>
Regards,
Palo

A better way to get the real ID of an component in a naming container

I got the following scenario:
I got several tabs (TabView is a naming container )
and in one of the I got a p:inputText which shows a dialog(which is located in other xhtml file) , now I want the dialog to update the p:inputText , the thing is that the id of the p:inputText is unknow (JSF adds some prefix to it)
<h:form id="hoursReportFrm">
<p:inputText id="comment4Dialog" value="#{hoursReportBean.aComment}"
onfocus="dlg1.show();"/>
I can't use this update="hoursReportFrm:comment4Dialog" in the dialog
ATM i looked at the example of this site JSF: working with component IDs (id vs clientId) (its from 2009)
and added binding to to inputtext , like thisbinding="#{lookup.components.comment4Dialog}" and in the p:commandButton of the dialog I changed to update="#{lookup.clientIds.comment4Dialog}"
and It works just fine, but I'm looking for a better way , without the need to bind every component that I would like to access later...
Thanks ahead,
To be quite honest, I think the binding is probably the easiest route, however when I've been in that situation I've found composite components often offer a better solution than bindings. Depending on the situation (and again, its totally case by case) you can use a composite component to get around this problem. This allows you to reuse parts of a page creatively so that your specific updates don't take a lot of work and you can reuse the code.
An example of this might be:
//comp:myDialog
...
<composite:interface>
<composite:attribute name="update" />
<!-- Other attributes -->
</composite:interface>
<composite:implementation>
...
<!-- Implementation -->
<p:commandButton update="#{cc.attrs.update}"/>
...
</composite:implementation>
And here might be the component in use:
//for the sake of argument 'comp' as your library
<h:form id="someForm">
<p:inputText value="#{bean.changeMe}" id="changeMe"/>
</h:form>
<h:form id="dialog">
<!-- dialog here -->
<comp:myDialog update="someForm:changeMe" />
</h:form>
By separating this view into a piece of reusable code you might be able to get around the burden of specifying the full path because it is now much easier to reuse. However, I think it is a toss up of a binding or the composite component depending on the specific case. For reuse, make a new object (component) and reuse it. If you're dealing with a highly dynamic environment: bind it.
I'm not an expert by any means, but generally speaking the above has gotten me out of a lot of tough situations.
EDIT: on a re-read you should also make sure that the tab-view isn't lazily loaded and take a look at the rendering to make sure the path is correct (inspect the ID). I've had problems (in older versions of Primefaces) where sometimes the id was nested inside a p:outputPanel or in rare cases the subview id. It might be a very simple fix by specifying the full path ':subview:form:component' though that shouldn't be the case.

spring security 3.0.3 custom login form

This handy link shows how to make a form that replaces the built-in spring security login form in 2.5.6. Can anyone illuminate the corresponding question for 3.0.3? Something has changed, the old form does not work.
When I click on submit it comes back to the login page with the error flag, and the username changes from what I type to 'null'.
This suggests that the names of the required form fields have changed from j_username and j_password to something else.
I'm also suspicious of
<input type="text" name="j_username" id="j_username"
<c:if test="${not empty param.login_error}">value='<%=
session.getAttribute(AuthenticationProcessingFilter.SPRING_SECURITY_LAST_USERNAME_KEY) %>'
</c:if> />
since AuthenticationProcessingFilter is deprecated.
And the answer is: POST is required now. I wish it had produced that error message the first time.

Resources