Assuming an employee only has 1 (primary) home and 1 (primary) cell number.
My suggestion would be to add two 1-on-1 associations Employee_Phone_Home and Employee_Phone_Cell.
This way you can display the phonenumbers in a datagrid via an their 1-on-1 association.
Only downside is that it requires additional logic to set/update the associations when creating/changing the phone number entities.
You can’t do this without changing your domain model or without using non persistent helper objects.
An option would be to add another association that is the other way around Employee_PrimaryPhone, with the phone number object beeing on the 1 side. This would give you the flexibility to also select another phone number as primary phone. It does not need to be the mobile one.
Another option would be to store the primary phone number as extra attribute in your employee object. But that would lead to redundancy and I guess that you try to avoid this.
I like the idea of Nils.
What you also could do is to create a Enumeration for the different phone types make possible by logic, it can be used only once per employee. In your grid, you can filter by xpath for the specific attribute.
To offer yet another solution, you can drop the data grid widget entirely and use a list view. In combination with the list view widgets you can easily add searching, sorting filters etc to a list view.
To fix the styling you have several options all outlined here
Hope this helps,
There are a couple different options to accomplish this. If I read your question correctly the domain model that you are working with looks like this:
If you just want to display employee’s cell phone numbers then you can have your datagrid data source be “Phone” and display first name and last name over association. Then add an xpath constraint so only cell phone numbers are displayed.
[_Type = 'Cell']
If you want only one record per employee and to still be able to view associated numbers, you can use a datagrid with a listening dataview to display associated data.
If you can’t change your domain model then another option would be to style a listview to look like a dataview, and use a dataview sourced by a microflow to retrieve the employees cell phone number. Then use the list view controls widget to add sorting and searching functionalities.
And the last thing I can think of if changing your domain model is an option is to change the association to many to many and set the navigability of the association to refer to each other. That way an employee can still have multiple phone numbers associated to it, and also the ability to display the phone numbers in a datagrid. If you want to only show cell phone numbers, then you can use the constraint from the first option.
Hope this helps!
If the association needs to be 1 - * the extra (helper) attribute on Employee isn’t that bad a solution: its also good for performance (shifting load to writing instead of reading).
Create an attribute ‘PhoneNumbers’ on your Employee, and create an afterCommit event on your Phone entity (or add it in your Phone Save/Commit microflow) that updates this attibute with the information you want (for instance ”Home: XX-XX, Cell: XX-XXX). adding it in this place makes sure no inconsistencies exist. It’ll add a little extra time to saving the entity, but save a lot of time when retrieving a large list of Employee objects.