Object based logic

[GoogleCodeExporter]

It occurs to me that the admin pages have a lot in common with a few other
html based projects I have worked on that use a library of objects. A
similar approach could work well, assuming it is within the vision of the
project.

For example, instead of

$myTestPlugin->RegisterAdministrationPage( PLUGIN_ADMIN_MENU_TITLE,
PLUGIN_ADMIN_MENU_PAGE_TITLE, PLUGIN_ADMIN_MENU_PAGE_SLUG,
PARENT_MENU_PLUGINS, RIGHTS_REQUIRED_ADMIN );

It would be easier to do:

$plugin_options = new wpf_admin_page();
$plugin_options->page_title = '';

and on to adding other objects to that particular page, e.g.

$plugin_option_of_some_kind = new wpf_admin_control(OPTION_TYPE_TEXTBOX);
...

$plugin_options->add_control($plugin_option_of_some_kind);

If it isn't clear what I am getting at I can quite easily mock something
quick up as an example.

Original issue reported on code.google.com by andrew.r...@gmail.com on 14 Nov 2007 at 10:35

[GoogleCodeExporter]

I definitely see where you are going here...

For now, I would really like to keep the WPF interface to a minimum set of 
functions 
so that this framework doesn't become overly complex like a lot of other 
frameworks 
have become. Your methods will definitely allow for more flexibility but for 
now I 
would like to focus on keeping the WPF less flexible and more standardized so 
as to 
hopefully attract more entry and intermediate level developers.

Basically, I don't want a developer to have to read a 50 page user manual in 
order 
to use this framework. I would like to keep this issue open so that we can 
revisit 
it after the WPF gains some success and we receive from feedback from the 
initial 
design. If we find that developers are requesting more flexibility in the WPF 
interface then I will be more than happy to work on this with you.

For now, why don't you go ahead and mock something up so that we can archive it 
with 
this issue. That way when we come back to revisit it we will already have a 
starting 
point.

By the way... I have added a "Deferred" status to handle issues like this that 
we 
will want to revisit at a later date.

Original comment by hust...@gmail.com on 15 Nov 2007 at 4:32

• Changed state: Deferred

[GoogleCodeExporter]

I have attached a rough sample. It uses objects to add admin pages and includes 
a
sample plugin.

Original comment by andrew.r...@gmail.com on 16 Nov 2007 at 9:39

Attachments:

• wpf_object_sample.zip

[GoogleCodeExporter]

Great job on the sample app. It's too bad that many of the class features (i.e. 
variable scope, etc...) are not available in PHP4. Also, this design looks like 
it 
will have the same "duplicate class name" issue as the v0.02 release of the 
WPF. 
Unfortunately, neither PHP4 or PHP5 support namespaces so all classes will need 
to 
have a custom name. So the user would be required to rename each of the library 
classes and the associated references for each plugin.

A solution for this naming issue could be handled in two distinct manners. The 
first 
solution would be to install the WPF as a common framework for all plugins (see 
issue #16). The second solution would be to maintain the current design of the 
WPF 
and add a feature to your online plugin generator to automatically add the 
custom 
prefix to all of the library class names.

We will need to decide on a plan of action soon as to how we want to tackle all 
of 
these options. I will try to spend some time this weekend thinking through each 
of 
these options to try to get a grip on which architecture would be the best 
solution 
for usability, maintainability, and performance. I have created a 
[http://code.google.com/p/wordpress-plugin-
framework/wiki/WordpressPluginFrameworkArchitecture WPF Architecture Wiki Page] 
for 
this dicussion.

Original comment by hust...@gmail.com on 16 Nov 2007 at 4:05

• Added labels: Priority-Medium
• Removed labels: Priority-Low