[buddypress-trac] [BuddyPress Trac] #6534: A new API to manage single items navigation

[buddypress-trac]

#6534: A new API to manage single items navigation
------------------------------------+------------------
 Reporter:  imath                   |       Owner:
     Type:  enhancement             |      Status:  new
 Priority:  high                    |   Milestone:  2.4
Component:  API                     |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+------------------

Comment (by boonebgorges):

 > But a feature like: bp_single_item_display_nav( 45, 'groups' ) is imho
 complicating a lot.

 Yeah. But if we're going to break everything and build a compatibility
 layer, let's try to build a system that's maximally flexible.

 Plus, I do think that we should have intelligent defaults that make this
 schema invisible to existing plugins. So, eg, `bp_core_new_subnav_item()`,
 if called without an item_type and item_id, should have internal logic
 that looks schematically like this:

 {{{
 if ( ! $item_type ) {
     $item_type = bp_current_component();
 }

 if ( ! $item_id ) {
     $item_id = apply_filters( 'bp_nav_item_id_fallback', null );
 }

 $nav = new BP_Single_Item_Navigation( array(
     'item_type' => $item_type,
     'item_id' => $item_id,
     // etc
 ) );
 }}}

 It looks like you have some of this fallback logic happening in your
 patch, but I got a little lost with what appears to be the half-
 implemented `buddypress->single_item_id` stuff.

 Do we need to maintain the distinction between `bp_nav` (`main` in your
 patch) and `bp_options_nav` (`sub` in your patch)? Can't we put them all
 in a single place, like `WP_Admin_Bar` does, and then identify top-level
 items as those without a 'parent_slug'? It seems to me that it would help
 a lot to simplify our system if we had a single interface for *all* nav
 items.

 Speaking of interfaces, I wonder if we might talk broadly about separating
 *item nav* from *item nav items* in the code. We'd be able to enforce
 better principles of encapsulation if we had a class `BP_Item_Nav` with a
 property `nodes` that was an array of `BP_Item_NavItem` objects. (I know
 that you haven't done this in part because you've copied and pasted from
 existing `nav_item()` functions.)

 imath, what do you think of the above? Let's talk about it a little bit
 before you go and whip up another patch :) I want to dig in myself and
 start working with code, but I want to be clear on the high-level strategy
 first.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6534#comment:5>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac