Abstract is_module_page functionality

[cojennin]

Opening up a separate issue to track what was discussed in #239 about abstracting how modules check what page they should be enqueueing content on.

This is a rough draft which contains two new functions:
register_module_page
is_module_page

After a little poking around I think we can definitively determine Edit Flow module pages based on the file name and page $_GET parameter. Assuming as much, reigster_module_page takes the name of the module, an array of file names and an array of page parameters.

is_module_page checks the current page and matches it with the file name and looks to see if there's a page parameter and matches it with a given page parameter.

Few things to note:

1. The mapping between file names and page parameters (should there be some kind of more formalized mapping?)
2. Need to add some documentation
3. As this function is rolled out across modules, need to deprecate old checks and balances
4. Currently leaving the whitelisting function for the settings page as is and using that to determine if we're on a settings page. (Should is_module_page also determine if we're on a settings page?).

[danielbachhuber]

I like the direction you're headed. Couple of initial thoughts:

• The way pages are registered seems a bit kludgy. Rather than having an explicit register_module_page method call, I think the pages would be better off as attributes of the module (and defined in the array right above). Or something like that.
• "page" as a word to describe where resources are enqueued doesn't work as well as I think it should. "view" is the alternative I have to suggest, but I'm not 100% sold on that.

[cojennin]

Yea, think I was looking at register_module_page in a way that is_module_page could be called from any module to determine what module page is active (if one module wanted to see if they shared a page, or a third party wanted to determine what module pages they were on). But I guess it doesn't really make sense to have the parent class be aware of the module's pages, since all other options are module specific.

The other thing I think I was considering was moving module options out of just acting as constructor arguments and into something like a builder pattern, but that'll need more consideration (and possibly another class or two, plus the arguments should still stay attached to modules). That would mean a class that would encapsulate all the register_x_option or build_x_option methods, which I think would have benefits in encapsulating module options (without having to resort to defaults, etc).

Needs more thought.

In the meantime, I've updated the code here: cojennin@542d558

[danielbachhuber]

Looking better!

[cojennin]

Closing in favor of #351