Closed (outdated)
Project:
Drupal core
Version:
7.x-dev
Component:
theme system
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
18 May 2008 at 17:55 UTC
Updated:
29 Oct 2009 at 19:49 UTC
Jump to comment: Most recent
Comments
Comment #1
joachim commentedAdding context information to the node object and subsequently the node template would open up many possibilities for modules and the theme.
Currently we have a few flags that follow the node object around: 'teaser' and 'page'. These get abused by quite a number of contrib module to get a desired effect, but doing so can have negative side-effects on other modules (eg nodeblock loads nodes as non-teaser, but community tags gets broken by this).
By the time we get to the node template, we also have is_front and sticky variables.
We could generalize these and allow the modules that contribute to the node to also add their data here.
Some practical examples of what data to store:
General nodes
We already have 'teaser' and 'list' that follow the node object around in node_view calls. 'sticky' is stored in the node object itself. We can fold all these in.
In addition:
- nodes in a list would get 'first', 'last', 'even' and 'odd'. Various possibilities for themers :)
- location in the page: most nodes are in the main content area, but some modules load nodes for display in a region.
Blog nodes
Each blog node would get:
- blog
- blog-user
This means we can avoid the current odd situation where an individual's blogroll at blog/user/1 shows their user picture over and over and over again. With the 'first' context flag, a theme can show the picture on only the first post.
Alternatively, a site could put the user picture and user details in a block and hide the userpic completely on in the individual blogroll. Either way, we get something a lot snazzier.
Taxonomy
We could hide the current term in the list at taxonomy/term/1, or highlight it in some way.
Views
There's a huge number of things this would be good for views.
I often find I do a load of view theming, when all I really want to do is say 'don't show the node links on teaser nodes in this view' (and I want a teaser list; really don't want to reinvent the wheel styling a list view).
If the views module dropped the ID of the view into context, a simple switch in the node template would do the job.
The hardest part of this is going to be figuring out a clean, simple, and extensible data structure that is easy to access.
My very vague current thinking is that the keys should be the flag names and the values either TRUE or some sort of data if needed.
This is just a rough initial sketch to start a discussion on:
An alternative would be to store the name of the module that set the flag as the value instead of just a TRUE -- I'm not sure this would have any useful applications though, just seems like potentially a good idea:
Comment #2
Farreres commentedI am very sorry that I didn't see your reply. I don't have that profound knowledge, but I agree with you, theming should be empowered and made more flexible. I hope others join the discussion sooner or later.