Sam, 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. Thanks, Barry 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. :-) Thanks, Barry
Barry,
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.