i have implemented Datatable by using Prime faces, in that i am showing drop down list for Countries and states separately from two different table. Now the requirement has changed , i have show dependent List of vales, for ex if i select US i have to show, states which are present US, . But the Thing here is we should not add any foreing key relation ship for these two tables.
DB desing contains states table with 4 colums like state id(pri key), stateName , country name, country id thats it, there isnoforeign key relation with Contry table.. i don't know why they are fallowing this approch in db desing..
i suggest them to add foreing in states table like( 3 colums with state_id(pri key), state name, country_id(foreign key) ), but they are not willing to add,
What would you say tim is this better approach , ?? can we achive functionality by what DB designers suggesting ??
if that is the case how to implement?? i am using spring ,Hibernate,JSF2.0, primefaces 3.5 in my project
It sounds like you have 2 different issues - a purely database issue and a JSF issue.
I really cannot understand why it isn't allowable to establish a foreign key relationship between countries and states. It might be a performance concern, could be they're using bargain-basement DBAs, could be idiot management policy, or could be something entirely else. It really doesn't matter that much to you, other than in cases where a foreign key would have enforced a proper parent/child relationship and you get clobbered by orphan state records.
On the subject of cascading JSF UIs, however, I've found a technique that is very effective, however. It goes like this:
A) The "get" method for the dropdown list (or suggestion list) looks for the SelectItem list in the backing bean. If it doesn't find one, it invokes a method to create one, searching the database for eligible candidates building a SelectItem for matches, and assembling them all into a SelectItem list, which is returned to the list get() method, which caches the list and returns it (caching the list eliminates overhead on subsequent calls).
B) A valueChangeListener is attached to the parent UI control. When this listener is invoked (value has changed), it resets the SelectItem list for the child UI to null. Which will cause the next attempt to get that list to trigger the sequence of events in item A). The listener ALSO resets the selected value for the child control, since unless it also appears in the new child SelectItem list, it would now be invalid.
I use this not only for things like dropdown lists, but also for stuff like DataModel objects. It's simple, efficient, doesn't require PostConstruct or other elaborate techniques, and makes it extremely easy to refresh the display, since all that is required is to null the model object and a new, fresh one will automatically be creaed.
Customer surveys are for companies who didn't pay proper attention to begin with.