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.
Tim Holloway wrote:It sounds like you are interested in getting the item's datatable model row. To get the immediately enclosing datatable component, chase up the Menu Control's parent chain until you find it. To get the outer datatable component, repeat the process from there. You should be able to invoke getRowData or getRowIndex to acquire the appropriate model data.
OR, you could just cheat:
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.
Tim Holloway wrote: You need to ask when the row of interest is being generated.
Frankie Fuentes wrote:
Tim Holloway wrote: You need to ask when the row of interest is being generated.
You mean by implementing DataModel? Or perhaps creating a ListDataModel instance and then add listeners to it? I've tried it. Yes it will iterate through all the rows but you will never be given a chance to know if that particular row is where the SelectItem has changed its value. I want to get hold of the instance where the Menu Control has changed its value. So if the group3.user2.type has change its value through that MenuControl, I should be able to get a handle for that instance. But alas, I've tried everything I could but no luck.
Thanks
-- Frankie
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.
Tim Holloway wrote:
That is not true. Were it not so, even the simpler version where there's only one table wouldn't work. And I've got more tables with embedded controls and listeners in them than I can count.
Every time a datatable row is rendered, part of what's written out to the web page is a marker that indicates what row in the table it is. This is the information that feeds back so that, for example, a click on a commandLink labelled "delete" on that row can fire a general "doDelete" action method which will know what item to delete because it queries the currentRow() method of the table's dataModel.
Embedding one table in a row of another table means that there's a more complex tree, but each inner row has a unique ID that can be used to ensure that you know exactly which row of both the outer and inner tables you're dealing with. That ID is a composite of the row ID of the inner table and the row ID of the outer table, as well as several other useful items and JSF knows exactly how to decode them.
Don't make things harder than they need to be! JSF is designed to make common tasks simple, and while 2-level tables aren't trivial, they're not rocket science, either.
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.
Tim Holloway wrote:
And yes, its "currentRow()" not "getCurrentRow()". I always forget.
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.
And if you invoked getRowData on an inner model, that inner model has to be part of the getRowData of its containing model - you can't invoke it on any of the other inner models.
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 a pinch, you can parse this down and dereference the rows by brute force, but it should already have been done and available if you look in the right place.
Look! It's Leonardo da Vinci! And he brought a tiny ad!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|