From LifeType Wiki

[edit] Introduction

Information on how to set up an run user data providers is available elsewhere, this page will concentrate on how to create them.

The idea behind this feature is that as long as user data provider classes implement the interface given below and return the expected values, LifeType will transparently use whatever data is provided to it

[edit] The BaseUserDataProvider class

This is the class defines the interface that all user data providers must implement. Each one of the methods should return a value of the type given on the left and expect parameters of the type given on the right.

• boolean authenticateUser( string $user, string $pass ): Given a username and a password, return true if the user can be authenticated.
• UserInfo getUserInfo( string $user, string $pass ): Given a username and a password, return a UserInfo object if the user can be authenticated or false otherwise.
• UserInfo getUserInfoFromUsername( string $username ): Given a username, return a UserInfo object with the information about the user or false if it does not exist.
• UserInfo getUserInfoFromId( string $userid ): Given a user identifier, return a UserInfo object with the information about the user or false if it does not exist.
• UserInfo[] getAllUsers( int $status = USER_STATUS_ALL, string $searchTerms = "", int $page = -1, int $itemsPerPage = DEFAULT_ITEMS_PER_PAGE ): Return an optionally paged array of UserInfo objects with all the users in the database. It is possible to specify a set of search terms and a user status to further filter the results. If no users were found, an empty array should be returned.
• boolean updateUser( UserInfo $userInfo ): given a UserInfo object, update this information in the database. Return true if successful or false otherwise.
• boolean addUser( UserInfo &$user ): given a UserInfo object, add this new to the database. Methods calling this method are expecting this class to set the "id" field of the parameter with the new id of the user in the database, hence the parameter being passed by reference instead of value. Return true if successful or false otherwise.
• UserInfo[] getBlogUsers( string $blogId, boolean $includeOwner = true, int $status = USER_STATUS_ALL ): Return an array of UserInfo objects containing the users who belong to the given blog. If not users are found, an empty array should be returned.
• boolean deleteUser( int $userId ): Remove the given user from the database. Return true if successful or false otherwise.
• int getNumUsers( int $status = USER_STATUS_ALL, $searchTerms = "" ): Return the number of users, optionally given a set of search terms and user status.
• boolean emailExists( string $email): Return true if the given email address exists in the database or false otherwise.

[edit] Implementation details

There are some aspects of the provider implementation that will be left up to the developer to decide. There are a few fields that are part of the core provider (LifeTypeUserDataProvider) such as the id of the resource file used as the user picture, or the administrator flag that cannot usually be stored in the 'host' system (mostly because they are LifeType-specific field)

In the case of the PhpBB2 and the forthcoming Joomla provider, this information is stored in a separate database table that is linked to the original user via its id (a foreign key) The logic implemented in the provider will then automatically load data from both places and put it together to return a working UserInfo object from methods such as getUserInfo().

In case of more flexible sources of data such as LDAP, this information could be stored in a new attribute in the directory thus removing the need for additional sources of data.