Store a value manually setted in Database

[marcel vieira]

Hi everyone!

I have a jsf form in which the user type an int and a string value, which are stored in database after clicking on a Save button.

    <h:form id="TbtestCreateForm">
        <p:inputText value="#{tbtestController.selected.name}" />
        <p:commandButton actionListener="#{tbtestController.saveNew}" value="#{myBundle.Save}" />
    </h:form>

I'm using EJBs with façade pattern, which does the CRUD actions defined in AbstractController class, which uses the AbstractFacade that 'binds' the entity class.

What I need is to <b>hard code/set manually</b> the string value in the form and store it in database along with the int value informed by the user, in the same operation (the same object).

I've tried to do as below, but no success:

@Named
@SessionScoped
public class MyBean implements Serializable {

    @Inject
    TbtestController tbtestController;

    private String myName;
    //GETTERS AND SETTERS

    @PostConstruct
    public void init() {
        myName = "some foo name";
        Tbtest myTbtest = new Tbtest();
        myTbtest.setName(myName);
        tbtestController.setSelected(myTbtest);
        tbtestController.saveNew(null); // to simulate what the savNew method do
    }

I've created a small netbeans project available to be cloned at: https://github.com/f6750699/webAppTest.git

Below, follows 2 methods defined in the AbstractController class:

The <b>saveNew</b> method:

    public void saveNew(ActionEvent event) {
        String msg = ResourceBundle.getBundle("/MyBundle").getString(itemClass.getSimpleName() + "Created");
        persist(PersistAction.CREATE, msg);
        if (!isValidationFailed()) {
            items = null; // Invalidate list of items to trigger re-query.
        }
    } 

The <b>persist</b> method:

    private void persist(PersistAction persistAction, String successMessage) {
        if (selected != null) {
            this.setEmbeddableKeys();
            try {
                if (persistAction != PersistAction.DELETE) {
                    this.ejbFacade.edit(selected);
                } else {
                    this.ejbFacade.remove(selected);
                }
                JsfUtil.addSuccessMessage(successMessage);
            } catch (EJBException ex) {
                Throwable cause = JsfUtil.getRootCause(ex.getCause());
                if (cause != null) {
                    if (cause instanceof ConstraintViolationException) {
                        ConstraintViolationException excp = (ConstraintViolationException) cause;
                        for (ConstraintViolation s : excp.getConstraintViolations()) {
                            JsfUtil.addErrorMessage(s.getMessage());
                        }
                    } else {
                        String msg = cause.getLocalizedMessage();
                        if (msg.length() > 0) {
                            JsfUtil.addErrorMessage(msg);
                        } else {
                            JsfUtil.addErrorMessage(ex, ResourceBundle.getBundle("/Bundle").getString("PersistenceErrorOccured"));
                        }
                    }
                }
            } catch (Exception ex) {
                Logger.getLogger(this.getClass().getName()).log(Level.SEVERE, null, ex);
                JsfUtil.addErrorMessage(ex, ResourceBundle.getBundle("/MyBundle").getString("PersistenceErrorOccured"));
            }
        }
    }

I really appreciate some help with it, because I got stuck on it for a while already.

Thanks in advance.

[Akaine Harga]

Not sure what you ment by "hard code/set manually the string value in the form and store it in database along with the int value informed by the user, in the same operation (the same object)."

Anyways here are some observations:

1. Not sure of you need both actionListener in commandButton. You can easy use action attribute which is the primary managed bean method called after clicking the button. ActionListener is normally used when you need to execute something before the main action method is called.

2. If you use EJB pattern as you mentioned it's much easier to inject the EJB interface using @EJB annotation thus making available the Facade's local interface in the managed bean.

3. Just for the notice. @SessionScoped managed beans maintain their scope during the entire user session. Not sure if that was your intention. If you need to maintain the managed bean while being on a particular page only the usage or @RequestScoped or @ViewScoped is recommended to avoid unpredictable behavior.

4. I see you have a middle layer method called persist(). In most small/medium sized applications there is no need for the middle layer in case you use JSF and EJB. A good and clean approach would be to have managed beans containing the atomic methods realizing their correspondent view actions and EJBs (Facades) containing persistence related methods. As I mentioned before the session beans can be injected into the managed beans directly by using @EJB annotation.

Example: http://www.developer.com/java/ent/integrating-jpa-jsf-and-ejb-in-java-ee7-applications.html
A nice tutorial: http://netbeans.dzone.com/articles/develop-java-ee-6-app-jsf2

Hope it helps. If not, please specify your question.

[marcel vieira]

Sorry if it wasn't clear enough for you, but now it will be.

What I want is very simple:
- there is a form. In this form, there is:
- one inputText, for int values (where the user type through the keyboard a number) and
- another one inputText, for string values (where the user won't type anything, becasue it will be already filled with the value "some foo name" as you saw in the code example which I already provided. That's why I said hard coded or manually setted, which means a value entered through the code itself, where I typed it, and not the user. Again, in this inputText, the mentioned string value should be already filled in that field.
- then, after the user types just the int value and see the hard coded string value, the user clicks on the Save button, which will trigger the SaveNew method, then the persist method.
My goal is to store both of those values (the int typed by the user AND the hard coded string) in database.

Now that it is clear enough, can you resolve this problem?

Another thing: I really appreciate your nit-picking observations, but, sorry, it wasn't me who developed it. In fact, I'm using the Netbeans Primefaces CRUD Generator (developed by Kay Wrobel), which uses the JSF Plugin Generator developed by the Netbeans Dream Team. The Generator always worked pretty fine, but now I need to do this modification.

Thanks.

[Akaine Harga]

Ok. I didn't understand you the first time because I did not see two inputs, just one.

The problem you have is related to how JSF works. The command button by default submits only the form it resides in. So to be able to update the "view model" submitting both values, both inputs have to be inside the form where the command button is. Once you have the managed bean's variables updated the rest is trivial. The correct xhtml code would be:
<h:form id="TbtestCreateForm"> <p:inputText value="#{tbtestController.selected.name}" /> <p:inputText value="#{tbtestController.myHardcodedValue}" /> <p:commandButton actionListener="#{tbtestController.saveNew}" value="#{myBundle.Save}" /> </h:form>

I see you use Primefaces namespace. In this case you can specify the input fields or the wrapper element that contains the input fields you want to submit by specifying the partialSubmit="true" and process="listOfIdsOfTheElementsToSubmit" (http://www.primefaces.org/showcase/ui/ajax/partialSubmit.xhtml). This ca help you minimize the data sent to the server in case you have more input fields in the same form.

On the other hand it sounds pretty strange to me you want to submit a "hardcoded" value in the first place. By looking at your example I can see it comes from the managed bean. Why don't you just use it as a local variable inside the managed bean itself instead of submitting it, since the hardcoded value won't change anyway.

Btw, what are you trying to do in general? Is this some kind of combo field simulation?

[Tim Holloway]

IDE code generators are dangerous things. They allow people who don't know what they're doing to create stuff that's limited to just what the generator knows how to do. In the real world, sooner or later someone is going to say, "but could you just add this one small thing...?" and it all goes to perdition. So much for being able to hire cheap untrained monkeys because the IDE generates their code for them.

While we're nitpicking: You - or the code generator - don't write Controllers in JSF. In JSF Controllers are supplied pre-written, pre-debugged as part of JSF itself. Or, for PrimeFaces elements, as part of PrimeFaces. Backing beans are not Controllers, they are Models.

There is a time and a place for an actionListener, but it's so rare that in nearly a decade of working with JSF, I cannot recall any apps I've got that use them. A regular (POJO) action method is far preferable to an actionListener.

The way JSF works is that the View Template (xhtml) is rendered by JSF to produce and present an HTML web page containing one or more HTML FORMs loaded with JSF context data as well as the rendered template controls and the values that those controls reference in the backing bean(s). When a FORM is submitted, it goes through the JSF lifecycle under the control of the JSF Master Controller (FacesServlet), which causes the form data to be validated (and rejected, if invalid), the backing bean property values to be updated (using the sub-Controllers defined by JSF or PrimeFaces for the individual input controls), and then the action method is called from the FacesServlet. You do not move data to/from the Model to the View via user-written (or IDE-generated) logic. As I said, JSF's Controllers do that automatically. That's what Controllers do. Nothing more, nothing less.

The action method is a simple POJO method. It can then invoke any database code it wishes. JSF is not in the database business, so any database logic or constructs are strictly the business of the backing bean, which is a POJO.

In my webapps, there are generally 2 levels of persistence. The high-level persistence that allows me to combine inter-related table objects into a working transaction and the low-level persistence that does table-at-a-time persistence (DAO). The high-level persistence ("service") methods are equivalent to EJB Session EJBs, but I'm commonly using JPA, so that's the closest equivalent.

The actual GUI Model object (backing bean) may or may not contain the business logic in its action methods. For complex apps, I separate out the business logic into a layer of its own between the GUI Model layer and the Persistence Service layer. In that case, the action methods invoke methods in the business layer and there's typically no persistence logic in the backing bean itself.

[marcel vieira]

Akaine Harga wrote:Ok. I didn't understand you the first time because I did not see two inputs, just one.

The problem you have is related to how JSF works. The command button by default submits only the form it resides in. So to be able to update the "view model" submitting both values, both inputs have to be inside the form where the command button is. Once you have the managed bean's variables updated the rest is trivial. The correct xhtml code would be:
<h:form id="TbtestCreateForm"> <p:inputText value="#{tbtestController.selected.name}" /> <p:inputText value="#{tbtestController.myHardcodedValue}" /> <p:commandButton actionListener="#{tbtestController.saveNew}" value="#{myBundle.Save}" /> </h:form>

I see you use Primefaces namespace. In this case you can specify the input fields or the wrapper element that contains the input fields you want to submit by specifying the partialSubmit="true" and process="listOfIdsOfTheElementsToSubmit" (http://www.primefaces.org/showcase/ui/ajax/partialSubmit.xhtml). This ca help you minimize the data sent to the server in case you have more input fields in the same form.

On the other hand it sounds pretty strange to me you want to submit a "hardcoded" value in the first place. By looking at your example I can see it comes from the managed bean. Why don't you just use it as a local variable inside the managed bean itself instead of submitting it, since the hardcoded value won't change anyway.

Btw, what are you trying to do in general? Is this some kind of combo field simulation?

I really appreciate all the knowledge you shared here, it will help a lot in many other situations.
Thank you so much!
See the solution below.

[marcel vieira]

Tim Holloway wrote:IDE code generators are dangerous things. They allow people who don't know what they're doing to create stuff that's limited to just what the generator knows how to do. In the real world, sooner or later someone is going to say, "but could you just add this one small thing...?" and it all goes to perdition. So much for being able to hire cheap untrained monkeys because the IDE generates their code for them.

While we're nitpicking: You - or the code generator - don't write Controllers in JSF. In JSF Controllers are supplied pre-written, pre-debugged as part of JSF itself. Or, for PrimeFaces elements, as part of PrimeFaces. Backing beans are not Controllers, they are Models.

There is a time and a place for an actionListener, but it's so rare that in nearly a decade of working with JSF, I cannot recall any apps I've got that use them. A regular (POJO) action method is far preferable to an actionListener.

The way JSF works is that the View Template (xhtml) is rendered by JSF to produce and present an HTML web page containing one or more HTML FORMs loaded with JSF context data as well as the rendered template controls and the values that those controls reference in the backing bean(s). When a FORM is submitted, it goes through the JSF lifecycle under the control of the JSF Master Controller (FacesServlet), which causes the form data to be validated (and rejected, if invalid), the backing bean property values to be updated (using the sub-Controllers defined by JSF or PrimeFaces for the individual input controls), and then the action method is called from the FacesServlet. You do not move data to/from the Model to the View via user-written (or IDE-generated) logic. As I said, JSF's Controllers do that automatically. That's what Controllers do. Nothing more, nothing less.

The action method is a simple POJO method. It can then invoke any database code it wishes. JSF is not in the database business, so any database logic or constructs are strictly the business of the backing bean, which is a POJO.

In my webapps, there are generally 2 levels of persistence. The high-level persistence that allows me to combine inter-related table objects into a working transaction and the low-level persistence that does table-at-a-time persistence (DAO). The high-level persistence ("service") methods are equivalent to EJB Session EJBs, but I'm commonly using JPA, so that's the closest equivalent.

The actual GUI Model object (backing bean) may or may not contain the business logic in its action methods. For complex apps, I separate out the business logic into a layer of its own between the GUI Model layer and the Persistence Service layer. In that case, the action methods invoke methods in the business layer and there's typically no persistence logic in the backing bean itself.

I really appreciate all the knowledge you shared here, it will help a lot in many other situations.
Thank you so much!
See the solution below.

[marcel vieira]

That is the already tested and well working solution provided by http://stackoverflow.com/users/2125446/paul-morris:

@Named
@ViewScoped
public class TbtestController extends AbstractController<Tbtest> {

    @EJB
    private TbtestFacade ejbFacade;

    public TbtestController() {
        super(Tbtest.class);
    }

    @PostConstruct
    @Override
    public void init() {
        super.setFacade(ejbFacade);
        myName = "";

    }

    private String myName;

    public void setMyName(String name) {
        myName = name;
    }

    public String getMyName(String name) {
        if (myName.isEmpty()) {
            myName = "Default Value";
        }
        return myName;
    }

    @Override
    public void saveNew(ActionEvent event) {
        this.getSelected().setName(this.getMyName(myName));
        super.saveNew(event);
    }
}

[Tim Holloway]

Yup, that'll do it. But the bean STILL isn't a Controller, no matter what he said.