[development] Blocks and Regions rethink (concept needs feedback)
barry at jaspan.org
Tue Jul 10 00:22:54 UTC 2007
I gave a perfectly useful example of a module-provided region: "just
before the the Nth paragraph of the body of a node." Many sites want
to place ads within body content, and such a region would allow them
to do so. The module would not need to provide CSS, just insert the
block at the specified location with a class and id tag. The site's
style.css would then perform necessary themeing.
Another example: "Just after the Nth result in a search or views
result page." Again, this would be quite useful for ads.
Another example: "In $node->content['my_custom_block'] with a #weight
of N." This would show among all the other pieces of a node's content.
Another example: "Absolutely positioned on the page at offset
X,Y." This might be useful for setting a block as an overlay on top
of certain pages. In this case, the module would need the provide
its own CSS, but it could do so via the standard drupal_add_css() function.
In short, regions are NOT just about themes. A region can be defined
(or, rather, should be defineable) within any piece of content with a
sufficiently predictable structure and for which a hook exists to
allow it to be modified.
At 11:06 AM 7/8/2007, Sam Tresler wrote:
>Barry Jaspan wrote:
>>My (fairly simple, I think) desired improvement for Regions is to
>>allow modules to declare them, e.g. hook_regions(), instead of just
>>allowing the theme to declare them. For example, I'd like to have a
>>"Node Regions" module that lets me declare a region "floated left at
>>the beginning of the third paragraph of a node's body field"; any
>>block could then be added to the region. I've actually already
>>written the module but it requires manually editing the theme's
>>template.php file. It should not have to.
>>I should have submitted a hook_regions() patch for D6 but did not, so
>>now I'm just trying to get my pet feature added to your rethink. :-)
>Sorry to be a downer, but that is perhaps the one thing that I
>wouldn't want in something like this. And I'm not certain why you
>would want it in a module-form, so maybe there is something I'm
>missing about what you are saying here.
>If we did anything like that it would need to generate CSS with it,
>and also need to be overridable. I can't imagine us hitting upon a
>default region design that would be even close to universally useful
>to people - if one region is floated left in your node-content
>-despite the design its in- every time you enable a module, well,
>that would get annoying quick - to always need to overrie it to kill
>the module specific region.
>Blocks are just content that can be themed, regions are very theme
>specific. We need to keep a solid separation of data and design in this.
>I guess what I'm proposing would be changing both the data stored
>(allowing blocks to be cloned and appear in multiple regions) and
>the input interface - but not really touching on any block's theme() calls.
More information about the development