[buddypress-trac] [BuddyPress Trac] #3278: @mentions autosuggest support

[buddypress-trac]

#3278: @mentions autosuggest support
---------------------------+-----------------------
 Reporter:  DJPaul         |       Owner:
     Type:  enhancement    |      Status:  assigned
 Priority:  normal         |   Milestone:  2.1
Component:  Notifications  |     Version:
 Severity:  normal         |  Resolution:
 Keywords:  dev-feedback   |
---------------------------+-----------------------

Comment (by boonebgorges):

 Thanks for the work on this, DJPaul. Huge improvement on what we've
 already got, and it's exciting to think that it'll be a good basis for
 future enhancements that involve autocomplete/suggest.

 A question/comment about the design. I find the pattern elegant. By
 routing all suggestions through `bp_core_get_suggestions()`, you reduce
 the amount of duplicate code that'd otherwise be required through the
 components. Likewise, filtering the query args for the members suggestions
 in order to power group membership suggestions is clever and results in
 less code repetition.

 But I must admit that, while elegant, it's not altogether straightforward.
 In order to understand how the group member suggestions work, you have to
 follow the filter train back through 'bp_members_get_suggestions', which
 itself is a callback that is indexed by the 'type' param passed to
 `bp_core_get_suggestions()`. This is not transparent for the developer
 who's looking to add custom suggestions to her own plugin.

 I don't have any super concrete suggestions for more straightforward
 designs. One very rough idea is to have an `abstract class BP_Suggestions`
 that handles some of the basic sanitization and authorization logic that
 is currently in `bp_core_get_suggestions()`. It would have abstract
 methods along the lines of `validate_params()` (see
 `bp_friends_suggestions_filter_query_args()`) and `get_item_data()` (which
 would contain the actual query logic). Use would then be something like:
 `$gm_suggestions = new BP_Group_Member_Suggestions();
 $gm_suggestions->setup( $args ); $gm_suggestions->get_results();`

 This is not fundamentally different from what you're doing (you could even
 daisy-chain Friends and Group Members classes on top of the central
 Members suggestions, much as you've done here), but it would put things
 together in a way that might be a bit easier to understand than the
 current system of (1) registering the service by filtering
 'bp_suggestions_get_types', (2) passing a callback to
 `bp_core_get_suggestions()`, and then perhaps (3) filtering some query
 arguments when extending an existing suggestions service. With an abstract
 class, everything would be in one place, and there'd be no filtering
 required.

 Again, this is just a thought. If others prefer your design, I'm happy
 enough with it, and won't say another word. I'm just trying to think about
 how easy to parse this will be for the newcomer.

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