Hi Can't you store the elements in a list and use the index of the list as key. This works fine till do not remove an element from the list using ajax which I don't think is required in your case.
regards Taha On Wed, May 25, 2011 at 9:18 PM, Vangel V. Ajanovski <[email protected]> wrote: > On 05/22/2011 03:39 AM, Thiago H. de Paula Figueiredo wrote: > >> >> I tried to understand your scenario but I didn't understand it at all. A >> heavily normalized complex would be the simplest scenario to implement. >> Almost all Selects will have options which are of a single type (otherwise >> I'd think the classes are not well designed). >> > I appologize for my english and not making it clear. You are right, in fact > all selects are of single type. The problem is that many times these types > are not self explanatory, like in this simplest case: > - Department { long id, String title } > - Person { long id, string name } > - Staff { long id, Person person, Department department } > > So, you have a form based on Staff. This is very simple: > - one select with a list of Person-s > - one select with a list of Department-s > > Now, this class: > - StaffSalary { long id, Staff staff, int month, int year, float salary } > > If I have a form for StaffSalaty I would do it like this: > <t:selectObject list="listStaff" value="staff" label=" literal: > staff.person.name '\s' staff.role.title "> > > As you see, none of the attributes in Staff is usable enough for the > average user to be used as a label. Again this is just a very very simple > case, sometimes these chains of navigation through foreign keys go for 5-6 > entities. > > I hope I was clear enough now. > > Of course you can say that a select list might not be the best component > for this use case. Oracle apps have popup LOVs (popup list of values which > is custom html with javascript in a popup window ), but to be most > user-friendly in some situations it is much better to use a select list > instead of some custom drawn component. > >
