myfaces-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Myfaces Wiki] Trivial Update of "ExecutingMethodsFromLinkButtonParameters" by SimonKitching
Date Wed, 04 Jan 2006 09:17:49 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for change notification.

The following page has been changed by SimonKitching:
http://wiki.apache.org/myfaces/ExecutingMethodsFromLinkButtonParameters

The comment on the change is:
Trivial grammar/syntax fixes only

------------------------------------------------------------------------------
  </c:url>
  <a href="${url}">Edit</a>}}}
  
- With MyFaces, there are several ways to handle this. Below are three ways. (Note, I don't
like the first way, but am showing it as it might be the first one your inclined to try).
+ With !MyFaces, there are several ways to handle this. Below are three ways. Note that there
are good reasons not to use the first way, but it is shown here as it as it might be the first
one you are inclined to try.
  
  '''1) Passing params with f:param'''
  
@@ -36, +36 @@

  Map map = context.getExternalContext().getRequestParameterMap();
  String employeeID = (String) map.get("id");}}}
  
- The above will work, but I'm not too fond of this approach. For one, you'll be dealing with
a String and you'll have to conversions yourself. Plus,you have extra lines of code just to
get a handle to the map holding the parameters. Sure you can push that off to a utility class,
but there is a cleaner way to handle this.
+ The above will work, but I'm not too fond of this approach. For one, you'll be dealing with
a String and you'll have to do conversions yourself. Plus, you have extra lines of code just
to get a handle to the map holding the parameters. Sure you can push that off to a utility
class, but there is a cleaner way to handle this.
  
  '''2) Using <t:updateActionListener  ... />'''
  
  Before I get to using the tag, some background information...
  
- Typically your backing bean (continuing with the example above, EmployeeAction.java) will
have either 
+ Typically your backing bean (continuing with the example above, !EmployeeAction.java) will
have either 
  1) A member property that is a bean that will hold info you want to capture (often just
a typical POJO value object)
  or
  2) Direct memember properties in the backing bean with getters/setters
  
- For example EmployeeAction might have:
+ For example !EmployeeAction might have:
  
  {{{private Employee employee; //standard POJO Value Object with properties name, id, etc
  setEmployee( Employeee emp ) //
@@ -58, +58 @@

  String name; //getName/setName
  Integer id;  //getId/setId}}}
  
- both techniques are valid although I like the first approach. Since I usually have ValueObjects
that are used in different places, it makes sense to me to just make the POJO a managed property
of your backing bean. The only caveat is that you'll usually need to create a managed bean
reference to your property in your faces-config. 
+ both techniques are valid although I like the first approach. Since I usually have !ValueObjects
that are used in different places, it makes sense to me to just make the POJO a managed property
of your backing bean. The only caveat is that you'll usually need to create a managed bean
reference to your property in your faces-config. 
  
  ie:
  
@@ -72, +72 @@

      </managed-property> 
  </managed-bean>}}}
  
- The above will make sure that EmployeeAction always has an instance of Employee set.
+ The above will make sure that !EmployeeAction always has an instance of Employee set.
  
  Now to use the t:updateActionListener tag you could just do:
   {{{<t:dataTable var="emp" .... >
@@ -82, +82 @@

      <t:updateActionListener property="#{employeeAction.employee.id}" value="#{emp.id}"
/>
  </t:commandLink>}}}
  
- When the above link is clicked it will set the id of the Employee object in our EmployeeAction
bean.
+ When the above link is clicked it will set the id of the Employee object in our !EmployeeAction
bean.
  
- If you were using id directly as a property in your EmployeeAction, the link would look
like...
+ If you were using id directly as a property in your !EmployeeAction, the link would look
like...
  
  {{{<t:commandLink action="#{employeeAction.prepareForEdit}">
      <h:outputText value="#{msgs.edit}" />
      <t:updateActionListener property="#{employeeAction.id}" value="#{emp.id}" />
  </t:commandLink>}}}
  
- I really like this approach. It's clean and ex-Struts users can think of it as sort of like
having your ActionForm properties set based on any request parameters submited. There is no
need to have to get a handle to the Map backing the Request parameters like there is in the
first approach.
+ I really like this approach. It's clean and ex-Struts users can think of it as sort of like
having your !ActionForm properties set based on any request parameters submited. There is
no need to have to get a handle to the Map backing the Request parameters like there is in
the first approach.
  
- '''3) Getting handle to DataModel Row.'''
+ '''3) Getting handle to !DataModel Row.'''
  
- Another approach is if you are using a DataTable backed by a DataModel you can get a handle
to the object that is backing the row. So if the user clicks on the "edit" link on the third
row, you can get a handle to the Employee object that backs that row in your EmployeeAction.
The edit link would be simple...
+ Another approach if you are using a !DataTable backed by a !DataModel is to use the !DataModel
to get a handle to the object that is backing the row. So if the user clicks on the "edit"
link on the third row, you can get a handle to the Employee object that backs that row in
your !EmployeeAction. The edit link would be simple...
  {{{<t:dataTable var="emp" value="#{employeesListBean.employeesModel}" ... >
   
  <t:commandLink action="#{employeeAction.prepareForEdit}" value="#{msgs.edit}"/>}}}
@@ -104, +104 @@

  
  {{{employee = (Employee)getEmployeesListBean().getEmployeesModel().getRowData();}}}
  
- Note, our DataModel in this case happens to be created in a class called "EmployeeListBean"
which is managed property of our EmployeeAction...
+ Note, our !DataModel in this case happens to be created in a class called "!EmployeeListBean"
which is managed property of our !EmployeeAction...
  
  {{{<managed-bean>
      <managed-bean-name>employeeAction</managed-bean-name>
@@ -120, +120 @@

      </managed-property>
  </managed-bean>}}}
  
- You could of course create your DataModel directly in the EmployeeAction class, in which
case you wouldn't need the extra class (EmployeeListBean) holding the DataModel (I like to
have it separate though in case other classes want to use it).
+ You could of course create your !DataModel directly in the !EmployeeAction class, in which
case you wouldn't need the extra class (!EmployeeListBean) holding the !DataModel (I like
to have it separate though in case other classes want to use it).
  
- The other thing to note is that if your DataModel for the form doesn't have Session scope,
you should add preserveDataModel="true" to your dataTable definition:
+ The other thing to note is that if your !DataModel for the form doesn't have Session scope,
you should add preserveDataModel="true" to your dataTable definition:
  
  {{{<t:dataTable var="emp" 
                  value="#{employeesListBean.employeesModel}"
                  preserveDataModel="true" ... }}}
  
- This will make sure the same DataModel is present when you click on your edit link. 
+ This will make sure the same !DataModel is present when you click on your edit link. 
  
- Another option is to use t:saveState to preserve your DataModel. In this example we would
add t:saveState some place after f:view:
+ Another option is to use t:saveState to preserve your !DataModel. In this example we would
add t:saveState some place after f:view:
  
  {{{<f:view>
      <t:saveState id="employeesListBean" value="#{employeesListBean}"/>}}}

Mime
View raw message