Aleksei,

On 7/19/05, Aleksei Valikov <[EMAIL PROTECTED]> wrote:
> Hi.
> 
> >>What would be the easiest way to implement this with standard EL,
> >>without JS?
> >
> > Let's assume...
> 
> [skip]
> 
> Thank you, your answer is the most complete of all I've seen in the
> thread. I only miss one fragment:

Glad to help. :-)

> 
> > When the commandLink is clicked for a particular row in the table, the
> > current row is established in the table data model prior to action
> > event delivery.
> 
> Is it possible to set the current row and invoke an action with one command?

If you take a quick look at the Javadoc for DataModel at

http://java.sun.com/j2ee/javaserverfaces/1.1_01/docs/api/javax/faces/model/DataModel.html

you'll see there are setRowIndex(int) and Object getRowData() methods.

During event delivery, the <h:dataTable> component will automatically
establish the right row index on the DataModel before your
"loadDocument" action method binding is called, so you don't need to
worry about it. :-)

Then, inside loadDocument, you can call model.getRowData() to pull out
the current row's data object.

The problem with using an EL expression to observe the current row
data (rather than model.getRowData()) is that you now have a reverse
dependency because the loadDocument code and JSP document would have
to rendezvous on the name of table var.

For example:

<h:dataTable var="row" ... >

would need to be consistent with

public void loadDocument(ActionEvent event)
{
  FacesContext context = FacesContext.getCurrentInstance();
  Application application = context.getAppliction();
  ValueBinding vb = application.createValueBinding("row");
  Object rowData = vb.getValue(context);
}

whereas the managed-property approach establishes a model-to-model
dependency from the "logicBean" managed bean, to the "modelBean"
managed bean.  The dependency is captured in faces-config.xml
metadata, rather than Java code.

This allows the table var attribute in the JSP view layer to be
modified independently, without impacting the correctness of the
managed bean code.

Kind Regards,
John Fallows.

Reply via email to