Easy Toggling of AttributesPosted: February 8, 2012
The Requirement: A quick, user-friendly toggling of people’s “attributes”.
Demo file: ToggleAttributesDemo.zip – downloadable from the “Box” over on the right.
I’m now using a very efficient method for toggling fields. A typical example is with “attributes” in the application I’m currently working on.
First, a bit of background. The users wanted to be able to assign “attributes”, or labels, to a person’s record. This attribute could be anything – “Homeless”, “Likes drum and bass”, etc. – and will be used for reporting, producing mailing lists, etc. The attributes have to be user-definable, and a person can have as many attributes as necessary (although typically not more than about 10).
I did think of storing each person’s attribute allocations in a text field, with a value list enabling the user to select as many of the available tags as they needed via a check-box display. But, thinking ahead, this would have limited the usefulness of attribute allocations when it came to reporting. Much better (if a bit more work) to have a separate table of “attribute allocations”, i.e. a join table between the People table and the Attributes table. This would not only increase my reporting options later, but also enable the storage of details of the tag allocation (reason for allocating it, date, etc.).
So, 2 new tables:
- Attributes (“ATR”), with primary key, attribute name, plus any other details needed.
- Holder Attribute Allocations (“HAJ”) – primary key, plus 2 foreign keys (to People and Attribute tables), and any other details that we may need. (Note the use of “Holder”, rather than “Person”, as this will be used for other entities which can hold Attributes.)
In the People table, a couple of new fields:
- AttributesHeld, i.e. a calc field, listing all the Attributes held for this person. The calculation is defined as List ( PPL_HAJ_ATR::id).
- ATR_ID – i.e. a global field, which will be used to hold the ID of the selected attribute, and will be used to check whether the person already has the attribute or not.
Re. relationships, as well as the obvious relationships linking the PPL, HAJ and ATR tables, I added a relationship from PPL to HAJ. I called it “PPL_HAJ~newRecCheck”, defined as:
So, it uses the global “ATR_ID” field and the PPL ID field to check for the existence of the record.
And now the method for allocating attributes , which is the main point of this post.
On the People Details layout, we have a list of available attributes, in a portal. If this person has this attribute, conditional formatting highlights the portal row:
FilterList ( PPL::attributesHeld; “Equals” ; PPL_ATR::id ; 0 ) ≠ “”
So, using the excellent “FilterList” custom function (see Brian Dunning’s site), we can check whether the ID of the current portal row’s attribute exists in the person’s currently held tags. If so, we highlight it.
A button on the portal row runs the “Toggle Tag” script:
This is what it does:
- Set the global field to the value of the attribute under consideration.
- Use the “creator” relationship to check for the existence of this attribute allocation (i.e. whether this person already has this attribute ).
- If so, delete the attribute allocation.
- If not, create it.
The record creation is the nicest part of all of this. By using “Set Field”, we not only create the record, but also populate the field that we’ve set (obviously), but also the other field(s) used in the relationship – in this case, that’s the PPL_ID field, the foreign key back to the People table.
The icing on the cake is that we don’t even need to refresh the window to toggle the attribute in the Person Details screen – it refreshes itself, presumably by virtue of the Commit. The whole thing happens as calmly as if I had used the check-box/text field option, but with all the potential extra functionality that the related table option provides.