This question already has answers here:
How does the 'binding' attribute work in JSF? When and how should it be used?
(2 answers)
JSF doesn't support cross-field validation, is there a workaround?
(2 answers)
JSTL in JSF2 Facelets... makes sense?
(3 answers)
Closed 13 days ago.
The website I'm working on has multiple types of users: basic, advanced, pro. The form is already customized depending on user type by surround some fields with a conditional container tag like <h:panelGroup rendered="#{userType != 'basic'}">. This works well for just hiding some fields from the basic user..
Now, my customer's (horrible) new idea is to place some fields in one or another section, depending on the user type. Below is a simplified example. "Field 2" occurs in the 1st section for 'basic' users and in the 2nd section for all others. I've already evaded the "Duplicate ID" problem by assigning id "field_2a" to the second occurrence, but the value and the binding are the same.
The binding is the problem. It looks like JSF evaluates all expressions and bindings before removing stuff that is not rendered. As a result, #{formBean.field_2_inputElement} is always bound to field_2a and never to field_2. So it does not work for basic users.
I have 2 ideas to solve this, but both are ugly and I'm looking for a better option.
Duplicate the whole JSF fragment containing the form, and include the fragment matching the user type: <ui:include src="/path/to/#{userBean.userType}/form.xhtml"/> (yes, this works, I've tested it).
Downside: I'll have to make all future changes an both files synchronously.
Have separate bindings and use the matching one by checking the user type in the formBean.
Downside: It makes the code ugly.
Any ideas for a 3rd and better option?
<h3>Some section heading</h3>
<h:outputLabel id="field_1_label"
for="field_1"
value="Field 1: "/>
<h:inputText id="field_1"
value="{#formBean.field_1}"/>
<h:panelGroup rendered="#{userBean.userType == 'basic'}">
<h:outputLabel id="field_2_label"
for="field_2"
value="Field 2: "/>
<h:inputText id="field_2"
value="{#formBean.field_2}"
binding="#{formBean.field_2_inputElement}"/>
</h:panelGroup>
<h:panelGroup rendered="#{userBean.userType != 'basic'}">
<h3>Some section heading</h3>
<h:outputLabel id="field_3_label"
for="field_3"
value="Field 3: "/>
<h:inputText id="field_3"
value="{#formBean.field_3}"/>
<h:outputLabel id="field_2a_label"
for="field_2"
value="Field 2: "/>
<h:inputText id="field_2a"
value="{#formBean.field_2}"
binding="#{formBean.field_2_inputElement}"/>
</h:panelGroup>
<h3>Some section heading</h3>
Related
I'm blocked for couple of days on a JSF issue.
I have a web app where I create the page content quite dynamically from database data. Every page has several sections containing a form with h:commandButton (or a set of buttons).
Some forms work correctly and the form action method is launched as expected. Some other forms however don't work - the action method is not being called at all.
And I don't know why :-(
I know this response: action method is not called in JSF which lists conditions which must be fulfilled and I believe that everything is ok here, but it simply doesn't work for some forms...
Some points:
The problem is 100% repeatable
The same piece of XHTML is used for both successful and unsuccessful requests
The same action method (in the same bean) is being called for all forms
the console output differs in both cases
...RESTORE_VIEW phase is the same (my code logs seem to be equal)
...APPLY_REQUEST and few other phases are empty for the wrong case (only the final RENDER_RESPONSE phase is being executed
...APPLY_REQUEST and the following phases are not empty for the correct phase
(using ui:debug) Scoped variables / Request parameters contain ONLY vallues passed via f:param for the successfull case
Scoped variables / Request parameters contain however also formid, formid:action_name and an input box content for the UNsuccessfull case
the console shows absolutely no exception in any case
the correct request returns HTTP code 302 followed by another GET request with the target parameters (as build in the action method)
the incorrect request returns directly 200 (and no action is called)
when the JSF debug is switched on (javax.faces.level = ALL, com.sun.faces.level = ALL) still no exception is being shown, I see only couple of "javax.faces.component.UIComponentBase getRenderer\nFINE: No renderer-type for component j_idt171" messages and one "com.sun.faces.facelets.util.DevTools writeAttributes
FINEST: Error writing out attribute" followed by a NullPointerException - during RENDER_RESPONSE phase
So most probably there is a problem with restoring the view, but I have no idea why. The same XHTML block generates form and command button for both (successfull and unsuccessfull) cases (in a c:forEach loop).
But the strange think is also difference in the parameters in the correct case an in the wrong case...
Can anyone plase give me some directions what/where I should be looking for?
Thanks a lot in advance!
EDIT: some code...
This is the XHTML (unnecessary code cis cut)
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://xmlns.jcp.org/jsf/html"
xmlns:c="http://xmlns.jcp.org/jsp/jstl/core"
xmlns:f="http://xmlns.jcp.org/jsf/core"
xmlns:p="http://primefaces.org/ui"
xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
template="/templates/base.xhtml">
<ui:define name="title">IS runtime</ui:define>
<ui:define name="menu">
<h:link value="Home" outcome="/index" /> | <h:link value="IS home"
outcome="/runtime">
<f:param name="env" value="#{param.env}" />
</h:link>
</ui:define>
<ui:define name="content">
<c:forEach var="pv" items="#{runtimeBean.pageViews}">
<div id="view_#{runtimeBean.ISViews[pv.view].code}"
class="view_#{runtimeBean.ISViews[pv.view].code}">
<h2>#{runtimeBean.ISViews[pv.view].code}</h2>
<h:form id="form_#{runtimeBean.ISViews[pv.view].code}">
<h:messages />
<c:if
test="#{runtimeBean.getEnvView(pv.view).type == 'RECORD_DETAIL'}">
<c:forEach var="item" items="#{runtimeBean.getViewItems(pv.view)}">
<h:outputText value="#{item.sqlColumn}" />:
<ui:fragment rendered="#{item.type == 'INPUT_FIELD'}">
<h:inputText id="#{item.sqlColumn}"
value="#{runtimeBean.sqlData0[item.sqlColumn]}" />
</ui:fragment>
<ui:fragment rendered="#{item.type == 'READ_ONLY'}">
<h:outputText value="#{runtimeBean.sqlData0[item.sqlColumn]}" />
</ui:fragment>
<br />
</c:forEach>
</c:if>
<c:forEach var="action"
items="#{runtimeBean.getViewActions(pv.view, 'BOTTOM_LEFT')}">
<h:commandButton id="action_BL_#{action.code}"
value="#{action.code}" action="#{runtimeBean.doPageAction}">
<f:param name="env" value="#{param.env}" />
<f:param name="view" value="#{pv.view}" />
<f:param name="action" value="#{action.id}" />
<c:forEach var="actionParam"
items="#{runtimeBean.getActionParams(pv.view)}">
<f:param name="#{actionParam}" value="#{param[actionParam]}" />
</c:forEach>
</h:commandButton>
</c:forEach>
</h:form>
</div>
</c:forEach>
<ui:debug hotkey="z"
rendered="#{facesContext.application.projectStage == 'Development'}" />
</ui:define>
</ui:composition>
This is Scoped Variables / Request Parameters for the correctly processed action:
Name Value
env 5
id 22
page 3
After the correct action the next page contains the parameters as passed:
http://localhost:8080/metais/runtime.jsf?env=5&page=3&id=22
and the same for the incorrect action:
Name Value
action 3
env 5
form_prj_detail form_prj_detail
form_prj_detail:action_BL_delete form_prj_detail:action_BL_delete
form_prj_detail:name p5
id 22
view 3
In the wrong case the next page doesn't show the arguments. Just simple:
http://localhost:8080/metais/runtime.jsf
In both cases the parameters are passed already in the HTTP (POST) request. It seems to me more as a problem of javascript part of the JSF library...
EDIT2:
I made some progress in investigating the problem and I've found the following:
The page is being generated dynamically including the forms. They are generated based on parameters passed to the page.
However when applying the form data, they are being applied to page built with missing parameter. If the particular form is NOT present on the same page rendered w/o this parameter, the JSF then doesn't know the form instance and thus its values are not applied and the rest of the page processing chain is invalid.
Using different words: if I add the problematic form to a "default page" (with missing page parameter), the form is processed also from different pages (the same XHTML but different parametrs causing showing different forms on the page).
So for some reason when the page is restored or when the form data are being applied not all page parameters are used to restore the view.
...I made one small step but still don't have a solution and I'm frustrated :-(((
BR,
Rada
So, finally I've understood the problem.
The problem is in the Restore View phase when the server reconstructs the submitted page before any form values could be set and before the form action could be performed.
The point is that the page is not being restored from internal JSF view state but it's restored as a "new" page - and using arguments used to build the original page.
My app. creates the forms dynamically and concrete page content depends on the page parameters (set in the HTTP GET message) and then data read from DB. Pressing a command button builds a request with parameters necessary for making the action - which however don't match with parameters necessary to reconstruct the original/previous page (I don't care of it).
This means that the Restore view is reconstructing DIFFERENT page than the one the command button is pressed from. This means that the reconstructed forms don't match with the original page forms. And this finally means that they can't be matched and thus the follow up life cycle steps are not successfull and no action method could be called.
So... this is either my misunderstanding of the JSF principles OR it's a JSF design issue.
I'd simply expect that the Restore View must be performed implicitly and automatically...
Comments welcome!
BR,
Rada
Is it somehow possible to have a form for a single row in a panelGrid? If I just put the specific columns in a form-Tag they are (of course) rendered in one single column of my parent panelGrid.
Is there a possibility to solve this problem? It does not matter if a solution use the jsf-tag or the primefaces-tag
I am using Mojarra 2.1.26 and Primefaces 4.0
use partial process/update.
if your requirement is to send only data in specific row (and not sending other http parameters, even if they are not processed) add partialSubmit feature:
<h:form>
<p:panelGrid id="grid">
<p:row id="row1">
<p:column>
<p:inputText value="#{someBean.someProperty}"/>
</p:column>
<p:column>
<p:inputText value="#{someBean.anotherProperty}"/>
</p:column>
</p:row>
<!-- other rows -->
</p:panelGrid>
<p:commandButton action="#{someBean.someAction}" process="#this row1"
update="grid" partialSubmit="true" value="submit"/>
</h:form>
this behave the same (almost) as having a form just for row1.
note that you have to update grid because p:panelgrid renders its child components on its own.
however your desired behavior (exactly) is not possible using plain html either.
I'm using the Play Framework. I want to use the HTML5 input type 'search'. So, I want to output:
<input type="search" />
I've tried:
#inputText(field = myForm("myField"), 'type -> "search")
but it still kept the type="input"
the method inputText represents an HTML input text (see the source code here).
You have to define your own template to define the input of type search. Take a look at the Play documentation.
#helper.input(myForm("myField")) { (id, name, value, args) =>
<input type="search" name="#name" id="#id" #toHtmlArgs(args)>
}
Most probably your search field will not use many typical things from common form element (like constraints or error messages) so you can just use plain HTML to insert it, and add field's value in the proper attribute (if required at all):
<input type="search" name="myField" value="#myForm("myField").value" />
If it's just a search form (with this only field) you even don't need to wrap it with the Form class
(of course Nico's suggest is advisable in more sophisticated scenarios)
Some helpers you're looking for are avalaible in a play 2 module. The html5 input helpers are not in the core part of the framework because play authors want to keep it light.
Here is the module page on github : https://github.com/loicdescotte/Play2-HTML5Tags
This question already has answers here:
What values can appear in the "selected" attribute of the "option" tag?
(8 answers)
Closed 8 years ago.
I've been reading some articles about HTML, XHTML, etc. In most of them (i.e. My preferred syntax style) say that boolean attributes should be written without any value, like this:
<input type="text" required>
They even say that it is wrong to use this attributes like this:
<input type="text" required="required">
Some of this articles link W3 which says:
If the attribute is present, its value must either be the empty string or a value that is an ASCII case-insensitive match for the attribute's canonical name, with no leading or trailing whitespace.
but in the examples shows like this:
Here is an example of a checkbox that is checked and disabled. The
checked and disabled attributes are the boolean attributes.
<label><input type=checkbox checked name=cheese disabled>Cheese</label>
This could be equivalently written as this:
<label><input type=checkbox checked=checked name=cheese disabled=disabled> Cheese</label>
You can also mix styles; the following is still equivalent:
<label><input type='checkbox' checked name=cheese disabled="">Cheese</label>
So, how should the boolean attributes be written? Based in your experience, which of the options are cross-browser and which are not?
Attribues without values are valid in HTML, but invalid in XHTML, because it's not allowed in XML. Perhaps that's where your confusion is coming from. So, which one is valid depends on the doctype of your document.
I always use checked="checked" and disabled="disabled". I don't really have a reason for adding it, but it has always worked in all browsers that I test in. This includes IE6+.
im pretty new to jQuery, and i dont know how to do that, and if it can be done without editing manually the plugin.
Assume to have a simply form like that:
<form action="page.php" method="post">
Name: <input type="text" name="Your name" id="contact-name" value="" />
Email: <input type="text" name="Your email" id="contact-email" value="" />
</form>
When you submit it, both in 'standard' way or with ajaxSubmit(), the values of the request take the label of the field name, so in the page.php i'll have:
$_POST['Your name'];
$_POST['Your email'];
Instead i'll like to label the submitted values with the id of the field:
$_POST['contact-name'];
$_POST['contact-email'];
Is there a way to do that with jquery and the ajaxsubmit() plugin?
And, maybe, there is a way to do it even with the normal usage of a form?
p.s: yes, i know, i could set the name and id attributes of the field both as 'contact-name', but how does two attributes that contain the same value be usefull?
According to the HTML spec, the browser should submit the name attribute, which does not need to be unique across elements.
Some server-side languages, such as Rails and PHP, take multiple elements with certain identical names and serialize them into data structures. For instance:
<input type="text" name="address[]" />
<input type="text" name="address[]" />
If the user types in 1 Infinite Loop in the first box and Suite 45 in the second box, PHP and Rails will show ["1 Infinite Loop", "Suite 45"] as the contents of the address parameter.
This is all related to the name attribute. On the other hand, the id attribute is designed to uniquely represent an element on the page. It can be referenced using CSS using #myId and in raw JavaScript using document.getElementById. Because it is unique, looking it up in JavaScript is very fast. In practice, you would use jQuery or another library, which would hide these details from you.
It is reasonably common for people to use the same attribute value for id and name, but the only one you need to care about for form submission is name. The jQuery Form Plugin emulates browser behavior extremely closely, so the same would apply to ajaxSubmit.
It's the way forms work in HTML.
Besides, Id's won't work for checkboxes and radio buttons, because you'll probably have several controls with the same name (but a different value), while an HTML element's id attribute has to be unique in your document.
If you really wanted, you could create a preprocessor javascript function that sets every form element's name to the id value, but that wouldn't be very smart IMHO.
var name = $("#contact-name").val();
var email = $("#contact-email").val();
$.post("page.php", { contact-name: name, contact-email: email } );
This will let you post the form with custom attributes.