[wp-hackers] Call for thoughts on a new Settings/Options/Metadata API

[Ryan McCue]

Eric Andrew Lewis wrote:
> An issue in previous iterations of these APIs has been the object structure
> of a setting/metadata/option being intermingled with the the UI components
> in some cases. I don't want to jump the gun on implementation, but here is
> a gist of  meanderings imagining a new
> API<https://gist.github.com/ericandrewlewis/7441441>

I think that's a good start on structure. I do think we need to avoid
being too verbose though; having used some other systems similar to
this, you can end up very abstract quickly.

Rather than having the 'for' key, and letting settings be attached to
everything, I think we could use subclassing. It's a little weird to
have something attached to both a post *and* as an option without
needing different handling. I'm thinking:

	abstract class WP_Setting {}
	class WP_Setting_Option extends WP_Setting {}
	class WP_Setting_Post_Meta extends WP_Setting {}

But that could end up being confusing.

> I would love to hear constructive feedback: what the issues you face as a
> developer in the current environment, what you might want from a new API,
> etc.

I think something we should look into handling is making nested options
a first-class feature. That is, storing an array/etc into a single
option, rather than spreading it out. It's been recommended for a long
time, but you have to write all of the handling yourself.

On the other hand, if you could do something like...

	$setting = new WP_Setting( array(
		'key' => 'master_option',
		'type' => 'array',
		'children' => array(
			'option1' => new WP_Setting( ... ),
			'option2 => new WP_Setting( ... ),
		),
	) );

...that'd be pretty cool. This could also be implemented via the
settings group API you proposed.

-- 
Ryan McCue
<http://ryanmccue.info/>