v3 Roadmap - any request?

[michaeluno]

Is anybody interested in developing v3? I'm planning to start developing Admin Page Framework v3 which will have many breaking changes.

Goal

The goal of v3 is to have no more breaking changes in the future.

As I had written some custom field types, I've started realizing that, to incorporate with third party scripts including jQuery libraries, array key naming might be better to be all lower-cased to keep consistency with them. For example, the sample dial field type uses the knob library and the settings are defined with the data-{...} attribute. Since their setting attributes are all lower case, if the framework uses a different naming style for the settings, the user has to learn two different rules at the same time just to use a single field type.

This kind of situation happened before with writing a wrapper function for the WordPress core wp_enqueue_script() and wp_enqueue_style() functions. A similar situation probably will occur in the future as so many open-source libraries use lower case letters for their settings and parameters.

So I'm thinking that to have lower case letters where the user interacts with and keep the Hungarian notation where only the system uses.

To convert the array keys used by this framework into all lower case, it breaks the scripts using the previous versions of the framework. Is it worth breaking them? There are other issues that cannot be solved without breaking changes. So let's have them at once so that hopefully we no longer have breaking changes in the future.

Variable and Array Key Naming

Use lower-cased characters with underscores like my_variable for array keys where the framework users may use to define settings including pages, tabs, sections and fields. And employ the PHP Alternative Hungarian Notation syntax internally such as aMyArray where the users don't need to see.

Method Naming

Some methods should be renamed such as showPageHeadingTabs because it can imply rendering an output. However, what it does is just to set the visibility property. The actual rendering process is done by a different method.

So the name should be setPageHeadingTabVisibility() or something.

Also for internal methods, the prefix of underscore will be added such as _doInternalTask().

For callback methods, the prefix of replyTo will be added such as replyToAddStyle().

Field Array Structure

Currently the vLabel key's value determines whether a field holds multiple input elements or not. And the value can be either an array, a string, or a numeric value. This is confusing when defining a field type.

I think that to define the sub-elements, numeric keys can be used.

array(
    'section_id' => 'my_text_section',
    'field_id' => 'my_text_field',
    'title' => 'My Text Fields',
    'type' => 'text',
    'default' => 'hello',
    'label' => 'first field element.',
    array(          
        'label' => 'second field element.', 
        'default' => 'hi',
    ),
    array( 
        'label' => 'third field element.',
        'default' => 'bye',     
    ),      
)

Improve Repeatable Field Mechanism

Currently it's hard to write a custom field type that supports repeatable fields. One reason is that there is no means to rebind the JavaScript function attached to the input tag at the moment. Maybe it is doable by writing a repeatable-field script which allows a callback function to be assigned when a repeat event occurs.

Also the vDelimiter element may need to be dropped to help the repeatable script simple.

Sortable Field

If the repeatable field script is well structured to support almost all fields, then sortable fields can be introduced.

Select Field Type's Value

Currently the select field type's value is saved as a string for the single select type, holding the key specified in the vLabel element as its value. This may need to be changed to always have an array as it seems to be confusing for some users: #9

Drop Section Keys from the Saved Option Structure

When retrieving saved option values, sometimes it's cumbersome to specify the section ids in the array. Since the field id needs to be always unique, sections may not be necessary in the saved option array.

From

$value = $array['page_slug']['section_id']['field_id'];

To

$value = $array['page_slug']['field_id'];

Or even drop the page slug key.

$value = $array['field_id'];

So it helps implement this request as well: #12

Filter Names

There are some filter names which should be reviewed: #34

Also there are duplicated filters and added filters #64

Add the Minified Version of the Library

To help development be easier, it's better to keep classes in separate files. However, it might be overwhelming for programming beginners to have so many files to use the library. So like the minified version of the jQuery library, let's have two versions of the library; one is for the development of the library itself and the other is for the users to just include.

For the developers who fork the library:

• class/admin-page-framework.php
• class/debug/AdminPageFramework_Debug.php
• class/page/AdminPageFramework_Page.php
• class/page/AdminPageFramework_Setting.php
• ....

For the users who just use the library:

• class/admin-page-framework.min.php

In order to make this possible, a script to combine and minify those separate files to create the minified version is needed. If somebody can take this task, it would be greatly appreciated.

Form Fields in Taxonomy Page

#53

Meta Boxes in Pages Added by the Framework

#52

The 'attributes' key in Field Definition Array

This is already included in the 3.0.0b branch. What is does is to define tag attributes by array.

For example,

$aAttributes = array( 'name' => 'my_name', 'type' => 'text'  );

will generate <input name="my_name" type="text" />

Include Documentation

Include the documentation in the demo plugin. #55 (comment)

Your Ideas

Let me know what you think and tell me if something else should be changed or introduced.

Development Branch

It's now ready to be tested.
https://github.com/michaeluno/admin-page-framework/tree/3.0.0b

• The classes are moved to separate files.
• Most of the methods, properties, variables, and array keys, were renamed.
• Many of the classes were renamed.
• The section key was dropped from the saved option structure.
• Changed the field definition array structure to the one suggested above.
• Improved the repeatable fields mechanism including adding the ability to set custom callback JavaScript functions for repeat field events.
• Added more examples in the demo plugin.
• Supported the sortable fields.
• Dropped the page slug dimension from the saved option structure.
• Made it possible to pass settings to repeatable fields including setting maximum and minimum numbers of fields.
• Fixed a bug that caused infinite function calls in some PHP versions. Problem v3 #54
• Meta boxes for pages added by framework are now supported.
• Taxonomy Fields are now supported.
• Documentation is now included in the demo plugin.
• Added the info of deprecated filters.

[Edit]

• 12/23/2013 - Added the request of dashicons support. Added the idea of the minified version,
• 12/24/2013 - Added the Goal part with the reasons of the change. Updated the descriptions of variable and method naming.
• 12/25/2013 - Removed the dashicons part since v2 now supports it.
• 01/05/2013 - Added an idea to drop the page slug key from the option array structure. Added a list of changes that have been already done in the 3.0.0b branch.
• 01/08/2013 - Updated the status of the 3.0.0b branch.
• 01/09/2013 - Updated the status of the 3.0.0b branch.
• 01/10/2013 - Updated the status of the 3.0.0b branch.
• 01/18/2014 - Updated the status of the 3.0.0b branch. Added an idea of form fields in taxonomy page, meta boxes in pages added by the framework, and Attributes array in the field definition array.
• 01/23/2014 - Updated the status of the 3.0.0b branch. Added an idea of including documentation.
• 02/02/2014 - Updated the status of the 3.0.0b branch.

[soderlind]

In setRootMenuPage, add support for the new "dashicons"

[michaeluno]

Nice idea, thanks!

[michaeluno]

v2.1.7.1 now supports dashisoncs in the setRootMenuPage() method.

[soderlind]

That was quick. Thank you :)

[michaeluno]

Now the development branch is ready to be tested: https://github.com/michaeluno/admin-page-framework/tree/3.0.0b

[Knorcedger]

Are there any plans to create an autocomplete field?

[michaeluno]

I don't mind adding it. Can you post the details in a new thread?

[Knorcedger]

I created this issue that describes the autocomplete field in detail
#71

Thank you for your time

[michaeluno]

No more feature will be added to v3 but for v3.1 or later. So I'm closing this topic.