On 05/22/2011 03:39 AM, Thiago H. de Paula Figueiredo wrote:
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: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).
- 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.
smime.p7s
Description: S/MIME Cryptographic Signature
