There are getting to be more and more cases where people will need to put multiple instances of the same field in a view. ui_name() has no way of distinguishing which is which. There are also more instances where these fields are being used externally, such as in Panels. Being able to override the ui_name() could be very valuable in keeping Views understandable.
I think this is mostly a textfield that becomes an option in the base views_handler and ui_name() tests it; if it's not empty, it uses it, otherwise it uses the existing formula.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 972620-custom_ui_name.patch | 3.96 KB | dawehner |
| #2 | 972620-custom_ui_name.patch | 3.95 KB | dawehner |
| #1 | 972620-custom_ui_name.patch | 3.87 KB | dawehner |
Comments
Comment #1
dawehnerHere is a patch.
This added quite some calls " parent::options_form"
Perhaps the title/description could get some native language love.
Comment #2
dawehnerNew version: It overrides the "group", too
Comment #3
merlinofchaos commentedSo far my only issue with this is taht "Custom UI Name" probably isn't meaningful to users. Let's go with "Administrative title" and explain that this is how the field will show up in the View edit as well as anywhere else that the view might be administered.
Comment #4
merlinofchaos commentedWhoops. Didn't mean to change status.
Comment #5
dawehnerUpdated the patch based on the feedback.
Comment #6
merlinofchaos commentedCommitted to 3.x in 6 and 7, with a slight wording tweak.
Comment #8
iamjon commentedmarked #922952: Please add naming in views filters for "Taxonomy: Term ID (with depth)" as a duplicate.