class Entry

Each entry in a loaded database has its own ::Entry object. More...

Full nameAddressBook::Entry
Definition#include <addressbook.h>
List of all Methods
Annotated List
Files
Globals
Hierarchy
Index

Public Types

Public Methods

Public Members

Protected Members


Detailed Description

Each entry in a loaded database has its own ::Entry object.

\par The structure of the address database As you might have read, kab uses the QConfigDB class to manage its data files. This class is intended to handle hierarchical structures. Thus, kab is able to create human readable but still deep and complex data files. This paragraph describes the overall structure of the files, the next two deal with special parts of it.
First of all, kab II data files (that usually end with \c .kab, while in kab 1 the fixed file name was \c addressbook.database) have two main sections (see the documentation of the QConfigDB and Section classes), one is called \c config, it contains different file specific configuration settings like the last displayed entry, and one section called \c entries that in turn contains a subsection for each entry in the database file. The keys of this subsections are the literal strings that are used in the KabKey class in the member KabKey::key. Each entry subsection has some key-value-pairs described below and another subsection "addresses" with one or more addresses in it. See the following example for a kab II data file (without any key-value-pairs):

  [config]
  [END]
  [entries]
     [1] (the first entry with literal key "1")
       [addresses]
         [1] (the first address, addresses are enumerated)
         [END]
         [2] (the second address)
         [END]
         ... (more addresses may follow)
       [END]
     [END]
     [2] (the second entry)
       [addresses]
         [1]
         [END]
       [END]
     [END]
     ... (more entries may follow)
  [END] 

\par The fields an entry contains An entry contains all settings that are expected to be unique for all addresses directly as key-value-pairs. Everything that is part of a specific address of this person is part of an object of the member list \c addresses referenced in the next paragraph.
The keys defined directly in the entry sections are:

"title" The title of that person.
"rank" A possible military rank of that person.
"fn" The formatted name. If it is not empty, it replaces the standard combination of the other name fields in the address display.
"nameprefix" A possible name prefix.
"firstname" The first name.
"middlename" The middle name.
"lastname" The last name.
"birthday" The birthday (a QDate).
"comment" A free form comment.
"talk" The talk addresses (a string list).
"emails" The email addresses (a string list).
"keywords" A list of free-form keywords.
"telephone" A list of telephone numbers in a special format.
"URLs" A list of internet addresses.
"user_1" The first user-declared data field.
"user_2" The second user-declared data field.
"user_3" The third user-declared data field.
"user_4" The fourth user-declared data field.
See the next section for a description of the addresses subsections.

\par The fields of the addresses subsections The section for each entry contains a subsection \c addresses with in turn a subsection for each address. The addresses are enumerated in the order they are inserted, their keys are the numbers of inserting converted to a string.
The keys defined in an address subsection are:

"headline" A headline shown for the address.
"position" The position of the person.
"org" The organisation.
"orgunit" The organisational unit.
"orgsubunit" The organisational subunit.
"role" The role of the person.
"deliverylabel" A label for delivering to this address.
"address" The street, house no., flat etc line.
"zip" A zip or postal code.
"town" The town the person lives in in this address.
"country" The country for federal states.
"state" The state for federal states.

\par The local configuration section For each kab II database file there are some settings that apply only to the file itselfes, not to all kab databases the user works with. These settings are called the local configuration. The settings are stored in the \c config section of the local file. The following keys are declared in this section:

"user_1" The \e name of the first user-declared field.
"user_2" The \e name of the second user-declared field.
"user_3" The \e name of the third user-declared field.
"user_4" The \e name of the fourth user-declared field.
More fields will surely follow.

Address (class)

Address

Since an entry may have different addresses, we need a type for them. Multiple addresses are used to distinguish between addresses at home and work, for example.

std::list<AddressBook::Entry::Address> addresses

addresses

static const char* Fields[]

Fields[]

static const int NoOfFields

NoOfFields

AddressBook::ErrorCode  getAddress (int index, Address& address)

getAddress

[const]

Use this method to retrieve the address at the given \a index. The method is provided for convenience. The address data is returned in \a address.

int  noOfAddresses ()

noOfAddresses

[const]

ErrorCode  get (const char* key, QVariant&)

get

Query the literal, translated name of the field given by its key.

Returns: false if key is not defined */ static bool nameOfField(const char* key, QString& value); /** Get a field by its field name. Field names are defined in

See also: QVariant, Since, there, are, different, file, types, a, field, may, be, represented, with, a, QVariant, is, returned.

QString title

title

QString rank

rank

QString fn

fn

QString nameprefix

nameprefix

QString firstname

firstname

QString middlename

middlename

QString lastname

lastname

QDate birthday

birthday

QString comment

comment

QStringList talk

talk

QStringList emails

emails

QStringList keywords

keywords

QStringList telephone

telephone

QStringList URLs

URLs

QString user1

user1

QString user2

user2

QString user3

user3

QString user4

user4

QStringList custom

custom

QStringList categories

categories

static KeyNameMap * fields

fields

[protected]


Generated by: dfaure on faure on Tue Apr 16 08:51:05 2002, using kdoc 2.0a53.