Sergey Smirnov

Did you try the image attribute that h:commandButton has?

What the action method returns?

The difference is much bigger than you expects.

outputLink is an equivalent of the < a href >. From the JSF point of view, it is alway a non-faces request. According to the JSF Specification, it is called "non-faces request generates faces response". The JSF lifecycle create the new view (based on the page you use in URL) and jumps directly to the sixth phase - Render Response. The value from the f:param is not assigned because JSF bypass all the phases such assignment might be performed.

commandLink is one of way for JSF postback. I.e. it triggers the form post that is associated with "faces request" on the server and JSF walks thru the JSF lifecycle. In same cases ( like session cannot be restored, validation failed, conversion failed, update more failed) particular phases might be bypassed. The application might jump to the next page only if the whole JSF lifecycle is passed and the navigation to the next page in performed at the end of the fifth phase.

According to your code snippet, you are completely misunderstand what the h:commandLink is about. The action attribute is NOT an URL to the next page. The action attribute should return a literal value that is used in the navigation case declared in the faces-config.xml file.

What you did you fill half of the screen with xml ?

Originally posted by Srik Messmer:
Arshad, You can do it in JSF without using goofy javascript. All you need to do is use attribute type="submit" for your commandButton.

-Srik

The final behavior will be vary depends of the number of fields and browser type.

You can look into the Spec to see what will be in JSF 2.0:
http://jcp.org/aboutJava/communityprocess/edr/jsr314/index2.html

Look at the Ajax JSF matrix for more information about what products allow Ajax: http://www.jsfmatrix.net/

vidhya, you are 10001 guy who bumps the head to this JSF stone. This behavior is absolutely expected from the JSF point of view.

Read explanation at:
http://wiki.jboss.org/wiki/RichFacesTwoInputText
[ September 11, 2008: Message edited by: Sergey Smirnov ]

Blue box is a header. So, it should appear only in you define facet name="header", but not "whenever" like you said.

rich-panel-header class redefine the class for header. You can use it if you want to re-define it for the whole page. If you want to change only one particular instance of panel, use headerClass attribute.

General advice: read the documentation or, at least, see the demo:
http://livedemo.exadel.com/richfaces-demo/richfaces/panel.jsf . "Look Customization" tab addresses your question.

Each request to JSF page should pass the Faces Servlet.
What the URL you print in the browser to access the page?

Managed bean is about how a java bean is created and initialized. As you know, jsf uses the lazy initialization model. It means that the bean in the particular scope is created and initialized not at the moment when the scope is started, but on-demand, i.e. when the bean is first time required.

Backing bean is about the role a particular managed bean plays. This is a role to be a server-side representation of the components located on the page. Usually, the backing beans have a request scope, but it is not a restriction.

If you use or try to work with Java Studio Creator, you can find the backing bean work more explicitly. The same for Shale, because it is designed by the same architect, that led the first JSF specification where those terms were introduced. Generally, it is not required by specification to bind all the components with the properties of the backing bean, so, on practice, the differentiation between the backing bean and managed bean is not evident. Sometimes people call all the beans like backing beans even they are just used for value binding. There is no a thumb rule here, just because the JSF specification has no explicit definition for those terms.

Source: http://forum.java.sun.com/thread.jspa?threadID=765889&messageID=4366727
[ June 05, 2008: Message edited by: Sergey Smirnov ]

Are you sure you want to program Ajax manually when the ready-to-use solution based on this approach already exist ?

It is just one line of code with Ajax4jsf.

Example:
http://livedemo.exadel.com/a4j-dropDownBoxes/

Source code:
https://ajax4jsf.dev.java.net/nonav/ajax/ajax-jsf/download.html#examples

Managed bean (any scope) has a lazy initialization. It means it is created at the moment when it is required for the first time. In your case, the bean is mentioned on the page first time. So, it is Render_Response(6) phase.

When user clicks on <h:outputLink value="/Nod/pages/managerPlusStaff.jsf">, it means "non-faces request generates faces response". The short (1ph -> 6ph) lifecycle is used. On the first phase, jsf checks for the view, does not find it and immediately jumps to the 6 phase. So, 6th phase is only one phase where the activity (request for beans) might happen. (However, you can use your custom ViewHandler or PhaseListener and do something what you need if any)

About Initialization: I recommend the following approach for your case: Check the current value in the getter and invoke the creator if data is not initialized yet. I.e.:

...... public class BeanManagersStaff { private List staff; ..... public BeanManagersStaff(){ } public List getStaff() { if (staff == null) populateStaff(); return staff; } ..... } public void setStaff(List staff) { this.staff = staff; } public UserBean getManager() { return manager; }

Important:

DO NOT take the managed bean directly from the session or request scope. Like that:
FacesContext context = FacesContext.getCurrentInstance(); ExternalContext extContext = context.getExternalContext(); Map sessMap = extContext.getSessionMap(); manager=(UserBean)sessMap.get("user");

Again, the managed beans use a lazy initialization. If nobody touches the bean yet, it is not added to the map. So, you can get null or object. It depends of "user" has been referenced previously or has not.

Use valueBinding or variableResolver instead. They take the bean from the map if exists. Otherwize, the bean will be created first.

yes, you are right. The state should travel to the server with each ajax request and each ajax response should contain the new state that should be send next time.
Just look at the source code of Ajax4jsf for details.
http://ajax4jsf.dev.java.net/
[ January 01, 2007: Message edited by: Sergey Smirnov ]