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

[Barry Jaspan]

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.