Remove $handler from views

[ewinslow]

The menu registering code should be the only code that has to concern itself with what the "handler" in urls is going to be. This was put into views, I assume, as a shortcut to encourage standard url structure.

It would be much better if, instead, plugins were encouraged to use hooks to override links with their own custom url, as opposed to the view passing $handler to its metadata menu. We just need to document the names of standard links, such as "edit" on the metadata menu.

[cash]

I think this comes up in 2 places:

• the entity menus - it is passed as 'handler'
• the content filter menu - it is passed as 'context'

We could use context as the default value and if a plugin wants to change that, use the plugin hook to override. We'd need to add a function to get the top level context (or grab it manually from $CONFIG).

The content filter menu would involve more work.

[cash]

Example code from blog plugin:

object/blog view

$metadata = elgg_view_menu('entity', array(
	'entity' => $vars['entity'],
	'handler' => 'blog',
	'sort_by' => 'priority',
	'class' => 'elgg-menu-hz',
));

and

page/layouts/content view

/**
 * Main content area layout
 *
 * @uses $vars['content']        HTML of main content area
 * @uses $vars['sidebar']        HTML of the sidebar
 * @uses $vars['header']         HTML of the content area header (override)
 * @uses $vars['nav']            HTML of the content area nav (override)
 * @uses $vars['footer']         HTML of the content area footer
 * @uses $vars['filter']         HTML of the content area filter (override)
 * @uses $vars['title']          Title text (override)
 * @uses $vars['context']        Page context (override)
 * @uses $vars['buttons']        Content header buttons (override)
 * @uses $vars['filter_context'] Filter context: everyone, friends, mine
 * @uses $vars['class']          Additional class to apply to layout
 */

Evan, do you still feel this needs to change?

[cash]

This is one that we need to either change soon or close.

1. For the entity menu as shown above for object/blog, it's done this way because there is no method to map between object subtype and handler.

2. Something similar is done for the add button on content listing pages for the same reason.

I'm not feeling the purist vibe on this one. Making every content plugin register for two more menu plugin hooks just so we're not passing a handler variable in a view seems like too much.