Profiles

Profiles are similar to sessions but store permanent data about a given user as opposed to data that expires as soon as the visitor closes their browser. Profiles have many good uses, and perhaps some underhanded uses. Many Web sites use profile data to allow a visitor to customize the site to some extent for future visits, or to pre-populate forms with data they submitted on a previous visit. On the other hand some sites use it to profile (hence the name) the visitor's browsing habits and sometimes even go so far as to cross link this information with affiliate sites. Their uses are many and only you can choose what you will do with them. Profiles automatically mean cookies (unless you are using some kind of authentication system) which means if the visitor does not have cookies enabled then long term storage will not be possible. The system also breaks down if they have their browser configured to discard all permanent cookies when closed. From my own experience most users do indeed have cookies enabled. InterJinn provides two packaged systems for profile data storage. One is to store the data on the filesystem as files, the other is to store the data in an SQL table (the exact SQL type depends on the database service which by default is MySQL). You can configure whichever option suits your needs best. Alternatively if you don't like either then you can write your own profile service to accomplish whatever system you would like.

What's special about InterJinn's profile system?

There's nothing altogether special about the InterJinn profile management system other than it makes good use of the InterJinn framework itself, and is leveraged by the Property System to enable transparent profile data handling. This behaviour; however, will exist for any properly constructed replacement profile service. For users that prefer to directly manage the profile data themselves (perhaps wanting to save out the data on a whim) the profile service is easily retrieved in the same manner as any other service.

$profileManager = &$this->getService( 'profileManager' );
$profile = &$profileManager->do->getProfile();

$profile->do->setData( 'threadMessages', true );
$profile->do->save();

That's pretty simple, and the system automatically uses either the filesystem or the database depending on what was configured. If you had declared a profile property using the property system, then the above would be as simple as the following:

$this->threadMessages = true;

Where can I learn more about the profile service?

You can learn more about the profile service by reading the Profile Service Documentation. The same documentation will provide you with a list of methods and functionality that must exist in your own profile service should you choose to create a custom one. You might also find the general Service Documentation useful.