Include view names in $vars for use in extensions

[beck24]

Given that one file can be used to extend multiple views, it can be useful to know which specific view is being used at a given time.

The variable $view_orig can currently be used, but it's not documented or really considered good practice. If included in $vars it would be in line with existing practices, and allow developers additional flexibility with the views system.

Any other meta view info that could be useful could be included in the same way.

[beck24]

​http://community.elgg.org/pg/forum/topic/868461/how-to-determine-the-current-view/

Steve makes a potentially valid point about it having such data being separate from $vars

[ewinslow]

I'm not super comfortable with allowing views to tweak something based on the name of the view. Even steve backtracked and prefers removing this "meta" information about views entirely, IIRC.

What's the actual use case? Is there no other way to get what you're looking to do?

[beck24]

Steve just backtracked from including the info in $vars, he wanted a separate variable for this 'meta' information, I believe he still thought the idea was good.
I'm not too concerned either way. The use case was that I was extending a number of views with the same extension:

elgg_extend_view('object/'.$subtype,'myview',490);
elgg_extend_view('profile/details', 'myview',490);
elgg_extend_view('groups/profile/layout', 'myview', 490);

The "object/$subtype" view is used in two different ways determined by $varsfull_view? for listing vs. viewing - my view should only occur when $varsfull_view? is true - however profile/details and groups/profile/layout don't have full_view settings. So I simply wanted my view to be able to determine if it was profile/details or groups/profile/layout so it could ignore the 'full_view' check.

The other option would be to register a second view for profile/details and groups/profile/layout, but that view would be identical to the first with the exception of one line. I thought having a one-liner if statement would be better than duplicating views/code in terms of code maintenance.
I found that it can be done with the current system, the recommendation for this ticket was to move the variable into $vars (and then later suggested to a separate variable) - it doesn't really change anything other than giving an implicit nod that this is an acceptable use. I absolutely agree that we don't want to encourage controller code in views though.

[brettp]

The fact is you can sorta do this already. What it boils down to is do we make this official and extend it to be a bit more friendly or so we say "Yes you can do it but please don't."

[ewinslow]

Here's my suggested solution: Set a parameter on the part of the view you want changed. Create a new view which just calls the original view with the parameter set appropriately. Now you can extend each file with a different view but without code duplication.

I like that solution much better than supporting more meta-information.