[development] Blocks and Regions rethink (concept needs feedback)

[Aaron Winborn]

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 at jaspan.org>
To: "Sam Tresler" <sam at treslervania.com>
Cc: development at drupal.org, "Barry Jaspan" <barry at 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.