add $build_mode param to term display
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | taxonomy.module |
| Category: | task |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | API clean-up, Fields in Core |
Jump to:
Kind of a followup to #409750: Overhaul and extend node build modes:
Just like we transformed $teaser into $build_mode in node_view() and friends, we should add a $build_mode param to the user and term buidling workflow.
Reason: even if user and term entities currently only expose one build mode ('full'), there's no guarantee it will stay that way before we ship, and even if it does, build modes are extensible from contrib anyway - only currently, adding a build mode for either terms or users is useless, because there's no way to specify a build mode for a displayed user or term.
For users, it means adding a $build_mode param to user_build_content() and related hooks: hook_user_view(), hook_profile_alter()
(note: functions and hooks names consistency is terrible - not to be solved in this thread, though)
For terms, it's a little more tricky, there's no taxonomy_term_build() API function, so it needs to be introduced...
I'd be thrilled if someone took the lead on this ;-)
#1
subscribing
Required for #498694: D7 core patch? (User Display API in core).
#2
Now that I thought about it some more (in the other issue), a $build_mode param for users would only make sense to force a special, known-to-exist build mode for rendering a user. I am able to foresee a few hard-coded build modes:
- 'full': The full user account/profile page content.
- 'teaser' or 'name': A username.
- 'picture': A user picture.
Eliminating theme('username') and theme('user_picture') by replacing it with theme('user', $account, $build_mode = 'name') ...
However, since modules output users in all kind of locations (not necessarily in views, blocks, or nodes), I don't think this really buys us something. To achieve the flexibility of User Display API (see issue above), we would pass a "class" only and allow the site administrator to configure which class should use what build mode.
#3
"a $build_mode param for users would only make sense to force a special, known-to-exist build mode"
Which could be defined by core (currently only 'full') or by contrib. We cannot reason only on what core currently uses.
Since Views can list users, having alternate build modes is precious.
To provide an example I already used in other places, a contrib module that lets admins add custom build modes would be both super easy and super useful (this is also true in D6 land, BTW...)
I'm not sure I get your point, but what i mean is that having user display support build modes has use cases aside from User Display in core (which would be awesome).
I'd even say that, since available build modes are extensible from contrib, 'supporting build modes' is a part of the 'being fieldable' contract, even if the entity itself doesn't actually uses them in its base code.
#4
theme('user', $account, $build_mode = 'name'). this is mixed up. The build mode is for *building*, not theming. It would be user_build($user, $build_mode). See node_build() for a working example. I think we can just punt on which user build modes to introduce. Leave that for contrib. As yched says, we just need to assure that build_mode is supported for users.Not at all sure what build modes are needed for terms. Maybe for vocabulary sharing or some odd case like that.
#5
re moshe #4: "Not at all sure what build modes are needed for terms"
example: list of terms in a side block as a navigational element - I want the term name + description + the picture.
More generally, anything that's 'listable' (Views) has use cases for build modes - of course, you can use 'Field'-style Views for this, but they're harder to theme and reuse, and with Field cache and multiple load, they are not even really faster in simple cases.
But, true, I'm not sure what could be *core* use cases for term build modes. Ni big deal, time will tell :-)
#6
Bumping, + moving this one to taxonomy.module and a twin to user.module
#7
Additionally, it would be really good to move term display to a template.
#8
Introducing a new tag for feature freeze: API clean-up.