wood burning stoves*
The moose likes JSF and the fly likes Why isn't my CRUD working? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Why isn Watch "Why isn New topic
Author

Why isn't my CRUD working?

Maire Marnane
Greenhorn

Joined: Nov 27, 2012
Posts: 6

Please help me if you can with this problem. I'm doing a course in JAVA and my assignment is to create a JSF page listing all suppliers. It has to have CRUD functionality, but I'm not allowed use persistence. I have to write the SQL statements.

The page has an add supplier button at the top, this goes to another page and the insert works perfectly.

Then a table is displayed with 2 buttons on each row, one to delete and one to 'save changes'. The delete works. the save changes does not.
I can't see what is wrong. Please help. I'm using Netbeans with a MySQL database.

I've put all the code here, in case I'm doing something incredibly stupid..

this is my jsp file



and this is my managed bean..



Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16020
    
  20



Should be:


The value is an EL expression that references the supplierList backing bean property. It should not be executable code. That is also true of the "action=" expressions. Which should not contain parameters. Because they shouldn't need parameters. The backing bean should have all the data it needs internally.

The getSupplierList method should not return the actual list if you expect to get maximum benefit from JSF. It should return an object of type ListDataModel. That object should wrap the actual supplierList, either when constructed or via a call to setWrappedData(supplierList). If you used the ListDataModel, your delete action method can tell which item to delete by invoking the ListDataModel's currentRow() method.

You should never do any logic that is expensive or has side-effects in a JSF "get" method. That method may get called up to 6 times for a single page request. You can do your database retrieval on the first call and cache it, but you shouldn't hit the database on each and every method invocation. Incidentally, in J2EE, it's not considered good practice to do brute-force Connection creation. Use a DataSource, instead.

And finally, get rid of all those valueChangeListeners! JSF is smart enough to update the values without them.



Customer surveys are for companies who didn't pay proper attention to begin with.
Maire Marnane
Greenhorn

Joined: Nov 27, 2012
Posts: 6

Hi Tim,

Thanks for that. But it still isn't 100% clear to me - sorry. I haven't come across the ListDataModel yet, so I'm not sure how to use it.

What do you mean by
It should not be executable code.


Thanks
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16020
    
  20

You need to find a good JSF book. While JSF is designed to work with POJOs as much as possible, the 2 types of JSF Models (DataTable and SelectItem) are essential things to know about.


What do you mean by

It should not be executable code.


JSF is a very precise implementation of the Model/View/Controller paradigm where the Controllers are usually built into JSF, the Model is your backing bean(s) and the View is defined as a template that the FacesServlet will populate and transform in order to create the final rendered (HTML) output.

A template is not executable code, the way that the Model is, and attempting to treat it as such is a violation of the Separation of Concerns compact that defines JSF. In practical terms, it tightens the coupling between Model and View, turns maintenance into an expensive "treasure hunt" as you bounce back and forth trying to find which component did what and how they got out of sync, and last, but not least, EL itself is a real to debug.

While you can code method calls in EL in JSF2, the ways that those calls are employed are not what every newbie who thinks that JSF can be designed just like any other platform expect, so aside from polluting the Separation of Concerns, there's the more critical problem that things won't work "correctly".

The primary use for EL in JSF is to define references to backing bean properties and methods. Not calls, references. A reference allows a read/write relationship, which is important since a value reference expression on a JSF control both populates the display from the backing bean property values, AND the backing bean is in turn updated by JSF to reflect what values those controls had when their form is submitted back to the server. This 2-way relationship is indicated by the "#" sentinel that is used to begin a substitution expression in JSF. The older JSP "${xxxxx}" expressions were read-only.

In the case of EL method references, the backing bean's method has to conform to a pre-defined method signature or JSF cannot match up the reference to the method. If you don't understand what a method signature is, you need to consult some basic Java documentation, because method signatures are a very important concept in Java.

The EL method references should not normally contain parameters, even an empty parameter list "()". Parameters passed to referenced methods in JSF are created by JSF automatically. Data values aren't passed at all, because the method is expected to access them directly inside the backing bean.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Why isn't my CRUD working?