CODEWITHSUNDEEP
javajsfjsf-2primefaces
Catfish
Catfish

Reputation: 19294

JSF - How to get old and new value when using Primefaces RowEditEvent?

I have a datatable with 2 columns(name and description) and I want to update my database when a person updates a row and clicks the checkmark which triggers the execBacking.update method.

In this method, I get the new values by casting event.getObject(), but how can i also get the old values? The name is my primary key so i need the old value to know which row to update in the db.

xhtml page 

  <p:ajax event="rowEdit" listener="#{execBacking.update}" update=":execForm:execMessages" /> 

  <p:column headerText="Name">
    <p:cellEditor>
        <f:facet name="output">
            <h:outputText value="#{exec.name}" />
        </f:facet>
        <f:facet name="input">
            <h:inputText value="#{exec.name}" />
        </f:facet>
    </p:cellEditor>
  </p:column>

  <p:column headerText="Description">
    <p:cellEditor>
        <f:facet name="output">
            <h:outputText value="#{exec.description}" />
        </f:facet>
        <f:facet name="input">
            <h:inputText value="#{exec.description}" />
        </f:facet>
    </p:cellEditor>
  </p:column>

  <p:column headerText="Actions">
    <p:rowEditor />
    <p:commandLink styleClass="ui-icon ui-icon-trash" type="submit" actionListener="#{execBacking.delete}" update=":execForm:execMessages" >
            <f:attribute name="execName" value="#{exec.name}" />
        </p:commandLink>
  </p:column>
</p:dataTable>

Backing bean

public void update(RowEditEvent event) {

        Dao dao = new Dao(ds);
        Exec exec = (Exec) event.getObject();
        System.out.println("name = "+exec.getName());  //New name
        System.out.println("desc = "+exec.getDescription());  //New desc
        try {
            // If the new exec was updated successfully
            if(dao.updateExec(accessBacking.getUsername(), null, exec.getName(), exec.getDescription())) {
                FacesContext.getCurrentInstance().addMessage("growl", new FacesMessage(FacesMessage.SEVERITY_INFO, "Success", "Exec Updated Successfully!"));
            } else {
                FacesContext.getCurrentInstance().addMessage("messages", new FacesMessage(FacesMessage.SEVERITY_ERROR, "Error", "Error Updating Exec!"));
            }
        } catch (Exception e) {
            FacesContext.getCurrentInstance().addMessage("messages", new FacesMessage(FacesMessage.SEVERITY_ERROR, "Error", e.getMessage()));
        }
    }

Upvotes: 7

Views: 11837

Answers (2)

kolossus
kolossus

Reputation: 20691

You can register a ValueChangeListener on the component you're interested in using:

<p:column headerText="Description">
   <p:cellEditor>
      <f:facet name="output">
          <h:outputText value="#{exec.name}" />
      </f:facet>
      <f:facet name="input">
        <h:inputText value="#{exec.name}">
           <f:valueChangeListener binding="#{keyChangedListener}"/>
           <f:ajax/>
        </h:inputText>
      </f:facet>
   </p:cellEditor>
</p:column>

keyChangeListener will correspond to an implementation of ValueChangeListener and we're using <f:ajax/> here to ensure that the valueChanged event is fired on the textbox. Otherwise the listener will not be notified. Your listener should look something like:

@ManagedBean(name="keyChangedListener")
@ViewScoped
public class KeyChangeListener implements ValueChangeListener{

     public void processValueChange(ValueChangeEvent event) throws AbortProcessingException{
          Object oldValue = event.getOldValue(); //get the old value
          Object newValue = event.getNewValue(); //get the new value

      }

I'm using the @ViewScopedhere as advised by the JSF Spec, to avoid unwanted side effects.

Upvotes: 0

StormeHawke
StormeHawke

Reputation: 6207

I would recommend not having name be your primary key, but instead add an auto-incrementing id field and make that your primary key, and don't make that field editable by the user. This guarantees you always have access to the record that you want to update.

Generally speaking it's bad practice to attempt to modify the primary key in a database the way you're trying to do it.

Upvotes: 4

Related Questions