22 Nov Contacts and the Extended Directory Scheme
Background: Every page on the website is known within the Joomla framework as an article. Articles are structured in a hierarchical manner using categories and subcategories (to any depth). For example, News is a category, with Events/News, Outside the Village, and Notices as subcategories. Group Pages is a category, and all the groups with a web presence are subcategories. Categories are useful for a number of reasons:
- One can quickly see and manage all the articles in a category
- One can set up a blog-format page that shows all the articles in a category
- One can restrict a category to, say, logged-in visitors, or website administrators, or members of a group or organization.
An attribute that can be assigned to any article is one or more “tags”, which are arbitrary labels applied to the article, somewhat akin to categories. An article can have any number of tags, but only one category. I decided that using tags to designate “context” in the contacts sense, would be more flexible, if somewhat harder to program, than categories. Also, Joomla tags can be assigned not only to articles but also to web links, categories and other Joomla objects. See this page for information about tags.
Contexts and Tags: To establish a context within a webpage on our site, one assigns a tag to the page, where the assigned tag is a “child” of the Context tag. That is, the Context tag is defined as the Parent of the specific context tag. For example, “FHA” is a tag with the parent “Context”, so any page tagged with “FHA” establishes the context “FHA”. Tags may be managed (added, deleted, changed) in the Admin back-end with the “Components” drop-down “Tags” link. Tags may be assigned to an article while editing the article.
When a website page is opened, if it uses FHA Directory information, it will use objects programmed in PHP to retrieve directory information about people and/or residences. If a context has been set by the article (called the page’s context), the context will be automatically determined by the objects, and all contacts associated with the residence OR the person will be filtered in the following way:
- If the list of contacts has any contexts that match the page’s context, these and only these contacts will be made available for display on the page.
- If the list of contacts does not have any contacts that match the page’s context, then all the contacts in the list identified as blank (default context) will be made available to the page.
An example: Suppose someoone who lives at Lot number 1111, and has a personal ID number (pointer in the database) of 2222 has these contacts:
No. | Entity | EID | Context | Type |
1 | Residence | 1111 | FHA | Phone |
2 | Personal | 2222 |
| Cell Phone |
3 | Personal | 2222 | FHA, WoF | |
4 | Personal | 2222 |
| |
| 5 | Personal | 2222 | WoF | Website |
The person represented by these contacts chooses to have separate emails for personal, FHA, and WoF business. He wants his residential phone and his FHA email to appear on pages which are related to his FHA persona. He only wants WoF members to use his WoF website. And he wants his residential phone, his cell phone, and his blank (unspecified) email to appear everywhere else.
If a page is opened with NO context, then contacts #2, and #4 will be fetched for the page. (No page context is provided.) | If a page is opened with context XYZ then #2, and #4 (the default contacts) would be fetched. (No MATCHING page context is provided.) | If a page is opened with context FHA, then contacts #1 and #3 would be made available to the page. (Page has matcing context “FHA”.) | If a page is opened with context WoF, contacts #3 and #5 would be fetched for the page, since these have context WoF. Contact #3 is used for FHA as well as WoF pages. |
The Contacts Table Contents
The Contacts table’s (tblContacts) relevant fields:
Field Name | Sample Value | Explanation/Description |
entity_type | 1 | 1=Lot, 2=Person – enumerated in tblEntities |
eID | 1001 | Index to Lot in tblLotsX or to person in tblNamesX – use table name indexed by entity-type in tblEntities table |
context | Where this contact should be displayed, e.g., blank for everywhere, FHA on FHA-tagged pages, XYZ for XYZ-tagged Club pages More than one context is OK, separated by commas. | |
type | Cell Phone | One of 8 or so common types, like Landline, Email, Website URL, Other – enumerated in tblContactType |
other_type | Type, if above selection is “Other” | |
value | 9195551212 | Data value of the field – validation done per type. |
order_pref | Order in which field will be presented in each context | |
| protected | 1 | Will not be displayed if page visitor is not logged in (default 1 = don’t show if not logged in) |
note | Arbitrary notes about the contact (To show or not to show. That is the question) |
- A “Contact” may be associated with a Lot (household or residence) and as such is, or could be, a contact for anyone who lives at that location. A Landline is an example, or a shared Email or FAX. A Contact could also be associated with an individual, e.g., a cell phone or a non-shared email address. So in the table above, the entity-type indicates whether the contact is for an address or a person, and the eID field gives the index, or reference to the address or person’s record on the appropriate database table.
- The type of contact can be any of a selection of types as described on the right.
- The “name” is what’s displayed in the selection options for a contact, e.g., Cell, Fax, Business phones, Website, twitter handle, etc. might be others.
- data_type tells what kind of a contact it is, for purposes of validation and formatting.
- If someone chooses “Other” as a contact type, the “Other” type will be stored in the contact record’s “other_type” field.