The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
If I set the value to CountryBB.UpdateCountry.newRecord.countryName I get a PropertyNotFoundException
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
If I set the value to CountryBB.UpdateCountry.newRecord.countryName I get a PropertyNotFoundException
If I set the value to countryBB.updateCountry.newRecord.countryName I get a PropertyNotFoundException
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
as I read it, both newRecord and foundRecord are the same ORM Model object
/UpdateCountry.xhtml @12,83 value="#{countryBB.newRecord.countryName}": Target Unreachable, 'null' returned null
First, why is the "update" method attempting to do an INSERT?
Secondly, what's with all the org.eclipse classes on your stack?
Oracle Certified Professional: Java SE 6 Programmer && Oracle Certified Expert: (JEE 6 Web Component Developer && JEE 6 EJB Developer)
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
It's change countryBB to SessionScoped until you have everything else working
One thing you should be careful of when using JPA. The merge() method returns an object which may or may not be the same object as the one you passed in. Depending on context and implementation, an entirely new object may be returned. So for maximum safety, pass back the results of merge and use them as a replacement for the original property.
each defined entity implements a hash and equals method
One thing you should be careful of when using JPA. The merge() method returns an object which may or may not be the same object as the one you passed in. Depending on context and implementation, an entirely new object may be returned. So for maximum safety, pass back the results of merge and use them as a replacement for the original property.
each defined entity implements a hash and equals method
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
SessionScope is the lowest-common denominator and if you cannot get things to work there, then ConversationScope isn't likely to work properly either
Oracle Certified Professional: Java SE 6 Programmer && Oracle Certified Expert: (JEE 6 Web Component Developer && JEE 6 EJB Developer)
Oracle Certified Professional: Java SE 6 Programmer && Oracle Certified Expert: (JEE 6 Web Component Developer && JEE 6 EJB Developer)
You're using an entity name, is it specified in your persistence unit?
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
JSF has absolutely ZERO database functionality
There are certain functional patterns that I use over and over and over again. One of them is the table-based CRUD process such as what we are discussing here
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
In the case of DataModel, it decorates your underlying display data list with cursor information and adds the rowData and rowIndex methods
In actuality, an anonymous DataModel is constructed for them. But since it's anonymous, there's no easy way to get ahold of it to extract its rowData
you don't have to refresh the wrapping if you alter the List or any of the rows in the list. Only if you discard the original list and replace it with a new list. Which is what you would do if you called findAll() to obtain an updated list of EJBs after a CRUD database operation. To refresh the wrapping, you can simply invoke setWrappedData, passing in the new list. I destroy (and re-create) the entire DataModel myself, but that's simply because the patterns I've evolved become simpler when I'm building from scratch instead of updating existing objects.
Jay Tai wrote:
In the case of DataModel, it decorates your underlying display data list with cursor information and adds the rowData and rowIndex methods
So that cursor information could be what's preventing data from renedering correctly if the rowData and RowIndex methods are not appropriate for a ListDataModel object?
So by creating a ListDataModel object ini my code I'm essentially removing the anonimity of the DataModel, which means I'm able to use the rowData to extract and manipulate rows?
I'm not sure if i do discard the original list or not after the create operation.
The AllCountry jsf page is called which calls findAll(), but does that mean it's calling the original list or discarding it and creating a new one? If it's creating a new one how do I refresh the wrapping? Do I invoke the setWrappedData method after the getRowData(0 method in the backing bean? Do I include a getWrappedData() method before the findAll()? How do you destory and re-create the model?
I'm looking at your CRUD application which will hopefully give me some answers. Would appreciate any answers or insights you may have on the questions I raised above. Thanks!
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
findAll would not "call" the list, but it returns a list. Which, depending on how EJB is handling things, could simply be the same list (assuming no adds/deletes/updates), but you shouldn't depend on that. Otherwise why go to the effort to find it all over again?
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Consider Paul's rocket mass heater. |