How Habari implments the WordPress code shown here: http://codex.wordpress.org/Settings_API

myplugin.plugin.php

<?php

namespace Habari;

class MyPlugin extends Plugin 
{

	/* Implementing this function modifies the admin options form */
	public function action_modify_form_admin_options(FormUI $form) {
		// Add a wrapper for a new "example" section before the form buttons
		$form->insert( $form->buttons, $example = FormControlWrapper::create('example') );
		// Add CSS classes to the wrapper
		$example->add_class( 'container settings');
		// Add a title and intro to our new "example" section
		$example->append( 
			FormControlStatic::create('example_title')
				->label('<h2>Example settings section in Options</h2>
				         <p>Intro text for our settings section</p>')
		);

		// Add a checkbox and store its checked state in the "eg_setting_name" option key
		$example->append(
			FormControlCheckbox::create('eg_setting_name', 'eg_setting_name')
				->label('Example setting Name')
				->set_helptext('Explanation text')
		);
	}
}

?>

Note that this method only adds a fully working read/write control to the options form with the surrounding markup, as in the WordPress example.

It's equally possible using this same method to remove, replace, alter, or rearrange these controls, existing core controls, or controls added by other plugins via this same method. You can also set storage parameters that allow easy automatic storage and retrieval directly from any FormStorage-capable object (like Users, Posts, Terms, Groups...) without any additional getters/setters. It is also possible to replace parts of this with command to use an MVC-style template file that would allow custom markup for a whole new control.

And all of these classes and methods autocomplete with PHPDocs in a competent IDE, allowing you to do in-editor help lookup (and avoid published docs entirely) for all of the complicated-looking classes and methods.

I'm not saying it's better. I'm saying... "Callbacks and mystery parameters for this?"