Active
Project:
User Display API
Version:
5.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
22 Jun 2009 at 14:30 UTC
Updated:
14 Jul 2009 at 14:11 UTC
Would be great to put this API into core now that the build_modes patch is in. One hitch I see is that this module works upon extending theme('username') but it should not work at theme layer in d7/ it should work during a 'build' layer in order to use build_modes.
Hopefully someone will take this on.
Comments
Comment #1
sunyeah, the "how" is the tricky part. yched already created #499192: Fix display and forms for "Fieldable terms" , which is a prerequisite for all of this.
Braindump:
a) Straight mapping of this module's terminology to core:
- "decorator" == "field"
- "user display style" == "build mode"
- "user display class" == non-existing
b) Display classes, i.e. an additional argument to theme('username') and theme('user_picture') is still required to make this work. Classes are specified by developers, to specify the logical appearance of a user. In many cases, __FUNCTION__ might work as well though. Classes do not specify the build mode -- the site administrator maps available classes to build modes instead.
c) Given b), hook_user_display($op == 'classes') would still be required in modules. That said, I'm not entirely sure whether all possible display style elements can be replaced with fields:
d) The (currently non-existing) UI to map classes to build modes could live in contrib, if that turns out to be not suitable for core. Although that's also the least complicated part:
e) Markup. For flexible theming in different locations and states, depending on the user display style and its elements, one needs a fair amount of markup and CSS classes. I could imagine that this flexibility is not needed on all Drupal sites or in all situations of a Drupal site - that's why User Display API falls back to theme_username()'s regular output when none of its styles shall be rendered.
f) In correlation with c) and e): For proper theming, it's pretty important to be able to re-order all elements in a style. Fields could probably be re-ordered via build mode UI already, but when considering that above mentioned elements/decorators are rather auto-generated information and links from modules, it gets a bit complicated. Since there is no UI currently, ordering is done hard-coded:
g) Technically, theme('user_picture') is superfluous with User Display API's approach and could be nuked.
Comment #2
guillaumeduveauSubscribe