[wp-hackers] Enhancements to Settings API

[Chip Bennett]

First, I would recommend following/contributing to Trac Ticket
#18285<http://core.trac.wordpress.org/ticket/18285>for Settings
API-related changes.

Second, IMHO, settings that use markup other than that ascribed by core are
Doing It Wrong. Reasonable minds will disagree, but I believe that
Themes/Plugins should be emulating core UI as much as possible. The beauty
of the Settings API is that it allows developers to focus on the
functionality, rather than on the settings-page markup. As Ticket #18285
gets implemented, that focus will be made even more clear.

Chip

On Fri, Oct 21, 2011 at 9:42 AM, Ade Walker <photofantaisie at gmail.com>wrote:

> *Enhancements to Settings API*
>
> I am thinking of proposing some relatively minor changes to the Settings
> API, but thought I would bounce around some ideas here first before
> submitting a patch.
>
> One of the aspects I find limiting about the Settings API is the fixed
> nature of the XHTML markup generated by the do_settings_sections()
> function.
> By way of a reminder, this function iterates over a global variable (array)
> which holds the settings sections registered for that particular settings
> page, and then outputs the following markup and content for each registered
> section:
>
>
> - h3 title of the section
>
> - Output of the callback specified in add_settings_section() (if specified)
>
> - table opening markup
> - a table row for each registered settings field applicable to this
> settings
> section, containing markup for each setting's form field
> - a table row.. ditto
> - etc
> - table closing markup
>
> This block is then repeated for the next registered settings section, and
> so
> on, until do_settings_sections() has finished its output.
>
> The problem with this situation is that this markup is not ideal if one
> needs a more complex markup to create, for example, a tabbed interface like
> that found in the existing Appearance>Themes page. Although it is possible
> to use jQuery to create the necessary markup, it's rather complicated and
> far from ideal.
>
> So, here are possible solutions (in no particular order):
>
> 1. Add a filter within the foreach loop in do_settings_sections(). The
> filter would need to pass the $section array.
>
> 2. Create a new function do_settings_section($page, $section) to allow
> output of each section separately.
>
> 3. Add a new $section parameter to the existing do_settings_sections()
> function, ie like this: do_settings_sections($page, $section = false).
> if $section is false, then the function spews everything out just like now.
> If $section has a value of the id of a registered section, then only that
> section will be output.
>
> Disadvantages of #1 is that dealing with the closing markup becomes
> complicated, unless the user uses the filter to completely replace the
> existing code within the foreach loop.
> Disadvantages of #2 is that it basically replicates an existing function,
> which doesn't feel right, and would require, say, 5 function calls in order
> to output 5 settings sections...
>
> For me, #3 seems the least worst option and would maintain backwards
> compatibility.
>
> Any thoughts, anyone?
>
> If I haven't been very clear in what I'm discussing, please let me know and
> I'll try to elaborate! :-)
>
> As mentioned before, I could have raised a ticket already, but wanted to
> get
> some other input before I do so.
>
> Thanks.
>
> Ade
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>