I think that what you're describing, Barry, would be better understood (by me at least) as a 'sub-region'. Node content is normally displayed within a region, such as the content region by default, or perhaps in a sidebar block (using views). Having a region placed within node content would end up being a potentially recursive function, particularly when combined with Views. I would rather see that in the domain of a special module, as what you've proposed. I would envision it being something like Panels, which defines its own regions outside the theme engine. I do not know how your module handles it, but I can think of several ways to implement what you want without resorting to rewriting any template file, most of which involve hook_nodeapi or filters. Aaron ----- Original Message ----- From: "Barry Jaspan" <barry@jaspan.org> To: "Sam Tresler" <sam@treslervania.com> Cc: development@drupal.org, "Barry Jaspan" <barry@jaspan.org> Sent: Monday, July 9, 2007 8:22:54 PM (GMT-0500) America/New_York Subject: Re: [development] Blocks and Regions rethink (concept needs feedback) 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.