Jump to content
Matt
 Share


Lifting the lid on the registry

In a previous blog entry on IP.Board 3.0's new framework, I mentioned that at the core of the new framework is something called 'ipsRegistry'. This blog post will go into more detail and will be of interest to modification authors.

Overview
IP.Board, like most complex applications, has a need for 'core' data, like settings, session and input data ($_GET, $_POST, etc). There is also a need for a database connection and access to global objects like cached data. It would be incredibly wasteful to make each file and class set up a database connection, load any cached data, authorize the browser session and build up any settings. This could happen many time in any IP.Board view.

Clearly there is a need for a way to initialize this data once and then pass it throughout the application. This is exactly what the ipsRegistry is for. Previous versions of IP.Board relied on the 'ipsclass' object as a registry; but this quickly became tarnished without clear boundries as more and more data was attached to it. It was more of a global variable than anything else. The new registry is composed of clearly defined objects. Also in previous versions initialization of the settings, caches, input data, sessions, etc was handled over a scattering of classes and files. The new registry is a single point for this initialization. This initialization occurs when init() is called. This makes it much easier to use IPS registry data in your own scripts and modifications. Previously you would have needed to copy out half of the default index.php. Now your scripts can be as simple as:

  require_once( 'classes/base/ipsRegistry.php' );    /* Call init which loads up input, caches, settings, creates the DB handle, authorizes and loads the member  $registry = ipsRegistry::instance()->init();    print $registry->request()->getField('foo');  $registry->DB()->do_update( 'table', array( 'foo' => 'bar' ); );  print ( $registry->member()->getProperty('member_id') ) ? 'Hello ' . $registry->member()->getProperty('members_display_name') : 'You are a guest';

require_once( 'conf_data.php' );










Gathering Input from URLs and Forms
One key part of IP.Board's initialization was the sanitization of $_GET and $_POST into a clean array. This was vital to the overall security of the board. IP.Board 3.0 as a 'request' registry object for this and all functions relating to this initialization (parse_key, parse_value, etc). This is available via either $this->request->getField('foo') or $this->request['foo']. This effectively replaces $this->ipsclass->input['foo'];

Cached Data
There are many improvements to the caching backend which we'll go into more detail in a later blog entry. The cache registry object simply returns the cache when requested via $this->registry->cache()->getCache('forums'); The cache is loaded and unpacked during initialization so you do not need to manually call it.

The Database
So much of the database code has been refactored that it's almost a separate blog on its own. Here, I'll concentrate on the registry object. The main function is getDB() which is interfaced via $this->DB (or ipsRegistry: :D B() when outside of class scope). This is a simple function to return the DB object which is set up during initialization via setDB(). This happens transparently when the file is included and init() called (which is done so by ipsController.php). You may set up more connections by specifying a key, for example:

  return $this->registry->DB( 'newConnection' )->build_and_exec_query( array( 'select' => '*', 'from' => 'table' ) );

$this->DB->setDB( 'mysql', 'newConnection', 'user@localhost.com', 'password', 'localhost' );



Settings
The setting cache is loaded and unpacked during initialization. This registry object merely returns the setting when requested via $this->settings->getSetting('foo') or $this->settings['foo'].

Member Information
Previously member information was scattered through 'ipsclass'. IP.Board's member registry centralizes this information. This object sets up the incoming IP address, browser and operating system and attaches it to the member class. It also authorizes the current browser session (via cookies or an inline URL) and loads up the session member and builds up the permission arrays. All this is done during initialization meaning there is less to do on the front end.

I hope this post has given you some insight into the IPS registry and the improvements it brings not only to IP.Board itself, but also to modification authors who will find their workload greatly reduced by automatic set up of all the required information. If you find that you do not need all of this information set up, then you can write a child class of ipsRegistry and alter the 'protected' functions to prevent them from initializing.

 Share

Comments

Recommended Comments

I woudl call $registry->DB()->doUpdate( 'table', array( 'foo' => 'bar' ); ); instead of $registry->DB()->do_update( 'table', array( 'foo' => 'bar' ); );. If you take a look on $registry->request()->getField('foo'); it seems to be more logical to me.

Link to comment
Share on other sites



Ye they do plan on converting those to Camel Case but it would take time i guess to transform everything.

I woudl call $registry->DB()->doUpdate( 'table', array( 'foo' => 'bar' ); ); instead of $registry->DB()->do_update( 'table', array( 'foo' => 'bar' ); );. If you take a look on $registry->request()->getField('foo'); it seems to be more logical to me.

Link to comment
Share on other sites

Does this mean people won't have to make modifications to be able to use certain member information (avatars, for example) in parts of the board that currently do not support it (the member list, global_board_header, etc.)?

Link to comment
Share on other sites

If templates have access to ipsRegistry on the fly, then I guess that would be possible :)

EDIT: Actually, remembered brandon said PHP was enabled by default in templates, so yeah you would be able to do that without touching the files :)

Link to comment
Share on other sites

  • Management

Lord G,

IP.Board 3 makes things so much easier. For example, you could simply do this:

My avatar: {parse expression="IPSMember::buildAvatar( $this->member )"}

Or, if you wanted to load another member's...

Your avatar: {parse expression="IPSMember::buildAvatar( $member_id )"}

It's very easy :D

Link to comment
Share on other sites

[quote name='Matt' date='Jul 28 2008, 03:27 PM']Lord G,

IP.Board 3 makes things so much easier. For example, you could simply do this:

My avatar: {parse expression="IPSMember::buildAvatar( $this->member )"}

Or, if you wanted to load another member's...

Your avatar: {parse expression="IPSMember::buildAvatar( $member_id )"}

It's very easy :D
Nice :D

Link to comment
Share on other sites



Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...