Dear Wiki user, You have subscribed to a wiki page or wiki category on "Shale Wiki" for change notification.
The following page has been changed by Hermod Opstvedt: http://wiki.apache.org/shale/ShaleAndClayTutorial ------------------------------------------------------------------------------ </managed-bean-class>[[BR]] <managed-bean-scope>request</managed-bean-scope>[[BR]] </managed-bean>[[BR]] + <managed-bean id="page2">[[BR]] + <managed-bean-name>page2</managed-bean-name>[[BR]] + <managed-bean-class>[[BR]] + com.acme.test.TestVC[[BR]] + </managed-bean-class>[[BR]] + <managed-bean-scope>request</managed-bean-scope>[[BR]] + <managed-property>[[BR]] + <property-name>person</property-name>[[BR]] + <property-class>[[BR]] + com.acme.test.Person[[BR]] + </property-class>[[BR]] + <value>#{person}</value>[[BR]] + </managed-property>[[BR]] + </managed-bean>[[BR]] + - What we do here is to define what is known as a backing bean or managed bean. This is a that Shale will make available to us. Shale uses an implicit mapping strategy to decide which beans it should instantiate for a given view. Since our page is called page1, it will then look for a managed bean with the same name and instantiate it. If you have a path to your page that spans several folders as in /foo/bar/pages/page1 then you need to define it as foo$bar$pages$page1 for Shale to find it and associate it with the page. + What we do here is to define what is known as a backing beans or managed beans. These are beans that Shale will make available to us. Shale uses an implicit mapping strategy to decide which beans it should instantiate for a given view. If our page is called page1, it will then look for a managed bean with the same name and instantiate it. If you have a path to your page that spans several folders as in /foo/bar/pages/page1 then you need to define it as foo$bar$pages$page1 for Shale to find it and associate it with the page. - Clay will when it sees the symbol managed-bean-name, replace it with the implicitly mapped bean that Shale is providing. In our case page1 + Clay will when it sees the symbol managed-bean-name, replace it with the implicitly mapped bean that Shale is providing. In our case page1. - Lets take a closer look at this bean (com.acme.test.TestVC). The first thing we notice is that it inherits from fra [http://shale.apache.org/shale-view/index.html/ AbstractViewController]. This class gives us some hooks (callbacks) into some Shale added lifecycle methods so that we can perform certain tasks that are relevant to that particular lifecycle. The next thing to notice is that is refers to a class Person. If you look in the faces-config.xml file again you will find the following declaration: + Lets take a closer look at the bean (com.acme.test.TestVC) that we are using for our backing bean. The first thing we notice is that it inherits from fra [http://shale.apache.org/shale-view/index.html/ AbstractViewController]. This class gives us some hooks (callbacks) into some Shale added lifecycle methods so that we can perform certain tasks that are relevant to that particular lifecycle. The next thing to notice is that is refers to a class Person. If you look in the faces-config.xml file again you will find the following declaration: <managed-bean id="person">[[BR]] <managed-bean-name>person</managed-bean-name>[[BR]] @@ -359, +374 @@ <managed-bean-scope>session</managed-bean-scope>[[BR]] </managed-bean>[[BR]] + If you look at the above definition you will see that Person has been declared as a managed bean. Because Person is defined as a managed bean, Shale will inject it into our page2 definition because we instructed it to through the use of the managed-property section. Since Person has a scope of session it will be persisted between request so that any value that we set on one request will be available on the next. Finally we see that we define a method sayHello on the TestVC bean, and that we refer to that method in the page2Body.html in the âactionâ attribute (: [EMAIL PROTECTED]). + + One of the thing that separate JavaServer Faces from an ordinary webapplication is that most interaction with the server is through http POST. This means that all fields and actions must be surrounded with a form tag. + + Another important thing to notice is that if declare your backing beans to extend AbstractViewController you have to declare them with request scope for the lifecycle methods to be called. If you declare it with scope session they will not be called! + + When we do a post against the server JSF/Shale will populate all fields in the managed bean that we have associated with fields on the page (There is a lot of other things going on too but that is beyond the scope of this tutorial). That means that when the method sayHello is invoked a bean Person will have been instantiated and filled with the values coming from our page. In the method sayHello we do not actually do anything other that return a string. +
