How to add an Employee Directory? [was How to merge features into Modx]

Quote from: PaulGregory at Jul 19, 2006, 11:47 AM

However, I do not think using user_settings is the best way for an Employee Directory.

1) It is counterintuitive.
The user’s phone number is already stored in the "phone" field of user_attributes / web_user_attributes. As is "fullname", "email, "mobilephone" etc. It appears to me that _settings are more "optional" settings, like "which days of the week can they access", etc. Every (human) user has a first name and a last name. Unless Madonna is on the payroll. Even so, it’s more likely than having a mobile phone. So adding 2 fields (firstname & lastname) to _attributes makes sense.

2) There is little benefit to the Manager in this instance.
Given that one would have to hack "mutate_user.dynamic.action.php" to add the fields/quasi-fields to either tab, there’s no benefit there. (If there was an User Setting Editor allowing you to add settings as if they were template variables, this reason would be void).

3) There is little benefit to Any Other Script in this instance.
It is obviously easier to add/update "fullname", "first_name", "last_name" and "phone" data at the same time. (If there was an API feature for checking for the existence of a user_setting entry and either adding one or amending the existing one, this reason would be void).

4) It is harder to sort properly by last_name, first_name if both are in the same table.
Compare

SELECT * FROM modx_user_attributes ORDER BY last_name, first_name

with

SELECT * FROM modx_user_settings US1, modx_user_settings US2 WHERE US1.user = US2.user AND US1.setting_name = 'first_name' AND US2.setting_name = 'last_name' ORDER BY US1.setting_value, US2.setting_value

Now try adding the phone number, or worse another _settings value.

5) Before anyone says it, any "future db versions do it more like _settings than _attributes" argument doesn’t wash.
Any major change of data model would need to convert the _attributes anyway.

So whilst I welcome being reminded of the _settings table, my opinion is that it is better to add fields to _attributes.

Field for sorting
One thing worth considering in place of "firstname" / "lastname" is "SortBy".
That way "Bruce Forsyth" would be "Forsyth Bruce", "Scott McQueen" would be "MacQueen Scott" etc. That may well be better if you have lots of names where the traditional human sorting is different from what would be achieved by Lastname, Firstname sort (eg cultural differences). It is also a field used in Outlook, which may well be the source of the employee data.

Great points Paul. I will add the alternative idea, that creating a separate table for the extra data and including a foreign key from the web_users or manager_users table would be even better. You can easily LEFT JOIN the results from this table into queries and sort them as desired, and it’s not that much work to add additional fields and an INSERT statement to handle this extra table, via a plugin in the manager, or via a separate module. The benefit of this approach is leaving the core tables alone and protecting your investment in MODx by making upgrades to the core possible without affecting the functionality of your employee directory.

Also, as for a field for sorting by, first_name last_name from your custom table can be aggregated into the existing fullname field, or dynamically aggregated via a SQL function in the proper sort format so the data does not have to be duplicated in the table.

I’ve used these approaches on four or five different projects now, and I’ve never had a problem upgrading MODx and causing conflicts with my custom user profiles...

Personnally, even if I understand the benefits of separating business logic from the CMS data structure, I chose to use TVs to do just that... mainly because it’s a small company (65 people), no outside source of data, and also because it allowed for QuickEdit in the frontend which a definite plus.

I had a client who requested and employee directory and it works just fine with TVs and Ditto...
Sample here : http://www.michelez-notaires.com/repertoire/alphabetique.html#A ( a french website).

Most of this conversation has been over my head. I really am trying to learn without expecting a free ride, but could someone start me out w/ a list of what I need to do to create the directory?

Quote from: davidm at Jul 19, 2006, 01:55 PM

Personnally, even if I understand the benefits of separating business logic from the CMS data structure, I chose to use TVs to do just that... mainly because it’s a small company (65 people), no outside source of data, and also because it allowed for QuickEdit in the frontend which a definite plus.

I had a client who requested and employee directory and it works just fine with TVs and Ditto...
Sample here : http://www.michelez-notaires.com/repertoire/alphabetique.html#A ( a french website).

That’s exactly what I’m looking for. How did you do it?

Basically, I created TVs for every field I needed. Then I templated the listing with a chunk (Ditto’s &tpl parameter) and the detailed page with a specific template.

The "bad" thing that I did (really it was "bricolage" as we say in french), is I used multiple NewsListing’s calls, one for each alphabet letter. And on top of every field I set up a TV with an alphabet selector, so the editor has to select the alphabet sorting key -> the tv named alpha and used as hiddentv in the call beyond (not really cool, but I didn’t know any other way to do it, I am not MySQL proficient...).

Did it like this :



The alphabet selector is just a list of anchor links styled with CSS
At the time, Ditto and AtoZ listing was not out and in fact, I have to update this website with it, it will be much cleaner.

My &tpl chunk is this :



And my detailed page template looks like this :



It was the second website I did with MODx, so as you can see it’s far from being the best way to go (quite ugly in fact), even if it renders OK.