[drupal-devel] [feature] Enable multiple block regions (not just
"left" and "right" sidebars)
Bèr Kessels
drupal-devel at drupal.org
Thu May 12 18:17:34 UTC 2005
Issue status update for http://drupal.org/node/16216
Project: Drupal
Version: cvs
Component: block.module
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: paragkenia
Updated by: Bèr Kessels
Status: patch
nedjo,
I am not a fan of your solution for blocks that dissapear. It breaks
the ability to allow more themes on a site. if important blocks dont
show up, your site will simply break. I would rather suggest that every
theme MUST have a region called 'default'. any blocks that want to go
into a non-existing region, will be placed there.
We must define a standard listy of suggested region names. to avoid a
wildgrowth of names.
I am not sure if i like the way you do function phptemplate_regions().
these regions should be defined in the templqtes, not the engine.
Otherwise all phptemplate themes will still all have two regions.
Note that i did not test your patch thouroughly, just applied and
looked at.
Bèr Kessels
Previous comments:
------------------------------------------------------------------------
January 26, 2005 - 11:27 : paragkenia
I read the comparision discussion between *Drupal* and *Mambo*. In
several messages it was outlined that Drupal can place blocks only in
right and left and not flexible to put them on anywhere where one want.
It will be great if this can be changed in upcoming versions.
I am no pro at PHP, so don't know how much time this task will take,
but I think it is very important.
parag
------------------------------------------------------------------------
April 15, 2005 - 02:44 : nedjo
This issue was apparently partially addressed in issue
http://drupal.org/node/19694 [1].
[1] http://drupal.org/node/19694
------------------------------------------------------------------------
April 17, 2005 - 01:24 : nedjo
Attachment: http://drupal.org/files/issues/block-dynamic-regions.patch (8.17 KB)
This much-requested functionality - to have the ability to place blocks
in more than the two predefined regions - was partially addressed in
issue http://drupal.org/node/19694. [2]. But "blocks" are still
limited to the "left" and "right" sidebars (hard-coded in
block.module).
This patch is a first step designed to enable multiple (eventually,
admin-definable) regions for blocks. I've moved the existing "left"
and "right" block regions to a 'region' table (with ids of 0 and 1, as
currently used in themes). Then all references to the regions are
drawn dynamically from the table. This way, if further records are
added, they will appear in the list of available regions for block
placement.
Doing this actually reduces some duplicated code, since it's no longer
necessary to repeat code blocks for each of "left" and "right".
As it stands, the patch doesn't add any new functionality--but I don't
think it breaks anything either. New functionality would need (a) new
regions defined, and (b) changes to themes. A simple first step might
be, e.g., to add a "footer" region and then add a call in the footer
generation to append any blocks assigned to the footer region there.
I'm setting this to patch, but I'm aware that it needs some discussion
and refining before it'll be ready to apply.
[2] http://drupal.org/node/19694.
------------------------------------------------------------------------
April 17, 2005 - 02:05 : nedjo
Attachment: http://drupal.org/files/issues/block_regions.png (5.65 KB)
Here's a screenshot showing the block admin page, with drop-downs for
region placement (the options are dynamically generated based on
defined regions).
------------------------------------------------------------------------
April 17, 2005 - 03:57 : adrian
The biggest problem with this is that you can have multiple themes, and
each of these themes can have different regions available.
Also, the method of defining which regions are available needs to be
standardised. Some of the work that me and Vlado are working on for the
install system would go towards solving that problem (ie: meta
information for modules, themes and styles).
This has been discussed to death, but the general consensus has been
that we _want_ to do this, but we need to solve a few other problems
properly first, the most pertinent being the interface issue. Chris
(factoryjoe) recently did a whole mess of workflows for something
related to this.
------------------------------------------------------------------------
April 17, 2005 - 05:09 : syscrusher
The first paragraph of adrian [3]'s post is a point that occurred to me
also, as I read this thread.
One suggestion would be to separate the definition and configuration of
blocks, on one hand, from the placement of those blocks, on the other
hand.
In other words, Drupal core provides a mechanism defining what blocks
exist, which of these are on by default or off by default and
user-selectable vs. which are forced on for all users, and the
configuration (if applicable) of specialized blocks defined by
particular modules.
Each theme provides a standard hook function that returns an array of
region names and help/description text, e.g., array('left'=>t('This
vertical region is left of the main content area'), 'right'=>t('This
vertical region is right of the main content area'), 'footer'=>t('The
footer is below the left, right, and main content areas of the page')).
The theme part of Drupal core (i.e., theme.module itself, not the
individual themes) provides a standard UI that is displayed within
config of *each theme* (but is one physical code base within
theme.module) that allows the administrator to map blocks defined by
Drupal core into regions defined by the theme, and storing that mapping
as an theme-to-block_ID-to-region_ID (with weight) table in the
database. From there, the actual page rendering is similar to what's
being done now, but there is more of it.
I guess what I'm trying to say is that the key to solving this problem
is breaking it along its degrees of orthogonality, and there are three
-- two in Drupal core and one in the individual theme.
Scott
[3] http://drupal.org//user/1517
------------------------------------------------------------------------
April 17, 2005 - 08:14 : Dries
Scott, is right. The theme should export its available regions. Then
the administrator's task is to assign blocks to regions (not to setup
regions). A theme could have configurable regions, but that internal
to the theme.
To me, the real challenge is the UI and the interaction design.
Configuring blocks could easily become a real pain (while most themes
continue to use 'left' and 'right'.)
Of course, we can implement all the functionality, default everything
to 'left' and 'right', and worry about the UI later. This should be
fairly straightforward to implement and nedjo's patch looks like a
first step in the right direction.
------------------------------------------------------------------------
April 17, 2005 - 22:09 : nedjo
I agree with the suggested approach of themes registering their regions.
I'd see this happening when a particular theme is activiated (or
upgraded). Regions would be an array of names (e.g., 'left', 'right',
'footer'). New records would be created in the region table only for
region names not previously registered.
Some areas I'm not clear on, or that need further work:
Table naming
Should a new table be 'region' or 'regions' (I've used 'region')? I
don't see a convention among existing table names, some of which are
singular and others plural.
Default values
I've kept the existing '0' and '1' ids for regions (left and right,
respectively), for backward compatibility. But this means we can't use
autoincrement for the region id (rid), since autoincrements seem to
begin with 1. Likely we should change to autogenerated ids.
Initial records
Using the INSERT INTO statements as I've done for the initial region
entries is probably counterproductive, since sooner or later they'll
have to be dynamically generated. I was hoping this could be a
preliminary patch, with the main work coming later, but likely we need
to solve region registration by themes before this patch is applied. I
don't have a good idea of how region registration by themes would be
implemented (a hook on theme activation?), and invite suggestions or
implementations.
Theme system changes
Besides region registration, the other change I'm seeing that would be
needed in the theme system is loading blocks by region name, rather
than region id. This is because the ids currently used ('0' and '1')
in theory might be diffferent on a particular install.
------------------------------------------------------------------------
April 17, 2005 - 22:18 : syscrusher
Instead of having themes "register" their regions, why not just add a
theme API hook called them_regions() that returns an associative array
of $region_name=>t($region_helptext)? This would be in keeping with
other similar API functions, such as those that return what permissions
apply to a module or what node types are defined by a module. Most
themes are going to define only a small number of regions (two being
the typical case now, but I could see five or six in a complex theme),
so returning a constant array will be faster than querying SQL to
obtain an array of rows.
There could be (optionally, at the discretion of whoever builds this
thing) another API hook like theme_region_properties($region_name) that
returns an associative array with detailed info for a given region, such
as extended help text with recommended usage instructions for the
region.
Scott
------------------------------------------------------------------------
April 17, 2005 - 22:19 : syscrusher
s/them_regions/theme_regions/g
------------------------------------------------------------------------
April 17, 2005 - 23:47 : adrian
Because. The most common 'theme' is a phptemplate theme.
And there needs to be a generic method for specifying the regions
available, in a non hook_function format..
Themes get their names from the directory in which they are contained..
when copying the theme to another directory, there must be _no_
modifications necessary to allow normal usage. This is one of the
tenets of the new template system I designed.
You would need a standard way to define meta-information for themes,
that does not need to be modified when copied to a new directory. We
are working on this in the install system work, as you need a way
external of Drupal to define the module dependencies and some other
things.
My approach would be to add a theme.dsc text file to the directory,
which would allow you to specify meta-information. For instance :
----
regions: left, right, footer, center, mountie
author: Johnny McAngstyPants
----
------------------------------------------------------------------------
April 18, 2005 - 03:00 : syscrusher
Adrian wrote:
"
Themes get their names from the directory in which they are contained..
when copying the theme to another directory, there must be _no_
modifications necessary to allow normal usage. This is one of the
tenets of the new template system I designed.
"
A very good point. But region names don't have to be unique across
different themes, so my hook function wouldn't have to be modified. The
suggestion I made for the mapping metadata was three factors: theme ID
or name, region ID or name, and block ID (plus one non-key weight value
to order the blocks within a region, but this is not relevant here).
I'm not familiar enough with PHP template to be able to respond to your
comments on that one, so if you say it's not feasible to work with my
schema, then I'll take your word for it. :-)
Scott
------------------------------------------------------------------------
April 18, 2005 - 03:03 : syscrusher
Oh, wait.....I see now what you mean! It's not the output of the
function that is the problem, but the *name* of the function.
Never mind. I concede your point.
Scott
------------------------------------------------------------------------
April 18, 2005 - 08:44 : Jaza
I'm probably jumping ahead a bit here... but something that this patch
will have to eventually account for, is how to allow regions to be
defined as inline. Allowing a theme to define a region's position as
being anywhere on the edge of the page (i.e. top, left, right, bottom,
corners, etc) is relatively easy. But what about having a region that's
in the middle of a node's body, or somewhere else that's not the edge of
the page?
What I'm thinking of, is eventually allowing the custom region system
to integrate with the CCK. Like I said, I admit that I'm jumping ahead
into the future - the CCK still has a long way to go before it's ready.
But ultimately, it would be cool if a theme could define a region as
being after, say, the "rating" field in nodes of type "movie review".
This would make the region (and the blocks in it) truly inline and in
context with the actual content of the node.
This would be a huge step forward compared to the current block system,
which doesn't allow you to mix the presentation of blocks and nodes at
all. In Drupal ATM, blocks and "the rest of the page" are totally
separate, and really you have no choice but to display them as such.
The result of this is that information in blocks that really should be
displayed as part of a node, gets literally "pushed to the side", and
always seems secondary to the actual content. Often the block has
content that is just as important as the content of the node itself.
Another option (of less merit, IMO - because of the extra maintenance
work, and lack of enforced consistency) would be to have a region
filter. You could then choose where to place an inline region on a
per-node basis, by entering text such as [region:2] (example based on
image_filter syntax) into the node body.
Anyway, just thought I'd throw that idea into the open. I don't expect
it will be implemented any time soon, but it's something to think
about.
Jeremy
------------------------------------------------------------------------
April 18, 2005 - 09:54 : stefan nagtegaal
Attachment: http://drupal.org/files/issues/regions---possibility-1.png (1.29 KB)
Imo the 'regions' are more than you guys name here.. FOr example I
attached 2 screens which only shows you the regions.. What I think is
that it should always be possible to have free names for the regions.
No matter if i call - the region where my content appears in -
'content' or 'site items'..
See attached screens..
------------------------------------------------------------------------
April 18, 2005 - 09:56 : stefan nagtegaal
Attachment: http://drupal.org/files/issues/regions---possibility-2.png (1.39 KB)
And the second...
See these links:
- http://drupal.org/files/issues/regions---possibility-1.png
- http://drupal.org/files/issues/regions---possibility-2.png
------------------------------------------------------------------------
April 18, 2005 - 16:22 : nedjo
Attachment: http://drupal.org/files/issues/block-dynamic-regions2.patch (13.39 KB)
Here's a revised patch implementing some of the ideas so far. I've used
the theme engine - rather than individual themes - to generate the list
of available regions. I know this isn't ideal, but e.g. for xtemplate
it's at present the only option--no logic is possible in the individual
theme.
region is changed to a varchar field from the current tinyint.
I've roughed in several regions--really just for demo purposes. More
thought and work would be needed to refine them (e.g., styling, etc.).
But this maybe moves the conversation forward.
------------------------------------------------------------------------
April 18, 2005 - 22:26 : Dries
This patch enables different regions to be used. That is a good thing.
The next question is: should we take into account that different themes
could assign blocks to different regions? Lots of problems would be
solved if (i) there could only be one active theme on a website or (ii)
if all themes would have a common set of regions.
(This "let users select their own theme"-thing is a left-over from the
early days, except for WAP stuff maybe.)
------------------------------------------------------------------------
April 18, 2005 - 22:37 : killes at www.drop.org
Giving up multiple theme support would be a great thing. People could
still select from multiple style sheets. WAP shoud not be a user
preference setting, but automatically detected and redirected to a
special site with a WAP theme.
------------------------------------------------------------------------
April 18, 2005 - 22:48 : adrian
You would then lose the ability to make a special front page theme for
use with the sections module, for instance.
Also, currently styles exist in the same namespace as themes, and we
would have to make more a distinction of styles vs templates (or
themes), but I do think this could help simplify things.
------------------------------------------------------------------------
April 21, 2005 - 17:54 : nedjo
Attachment: http://drupal.org/files/issues/block-dynamic-regions3.patch (15.69 KB)
The main issue raised, if I'm understanding well: if a theme or theme
engine is present that offers regions other than those available in the
default theme, any blocks assigned to those regions will be invisible to
most users.
Here's a revised patch addressing the concern. I've added a test for
each region to see whether it's also available in the current default
theme. (Actually, I'm realizing as I write this, I've used the theme
engine--so it would need to be updated to test first if an engine is
being used.)
In any case, any regions not available by default are starred, and a
message text appears (only if necessary).
If there's support for the approach, I'd be happy to finish the patch.
Remaining work:
* extend to work with non-engine themes
* finalize base set of regions to implement
* implement common region set in all core themes (for now I've only
done xtemplate)
* work on CSS display (how blocks in each region should look)
This last point I'm not too confident on and would look for
help/suggestions.
Screenshot to come.
------------------------------------------------------------------------
April 21, 2005 - 17:56 : nedjo
Attachment: http://drupal.org/files/issues/block_regions_message.png (12.34 KB)
Screenshot showing starring of non-default regions plus message.
------------------------------------------------------------------------
April 21, 2005 - 18:19 : killes at www.drop.org
I like that approach. +1
------------------------------------------------------------------------
April 21, 2005 - 18:23 : resmini
My two cents.
If this has to be done (and it should), better get rid of spatial
definitions for areas such as left, right, top, bottom, etc.
Use semantic names related to content and let the theme take care of
their positioning interely.
Also note that there in an ongoing debate in IA trying to build up a
standard naming convention for page regions in a way that is
semantically (and logically) correct. Just for the sake of it, you can
check
http://www.stuffandnonsense.co.uk/archives/whats_in_a_name.html
http://www.stuffandnonsense.co.uk/archives/whats_in_a_name_pt2.html
with follow-ups, including Eric Meyer's. There are more substantial
contributes in the AIfIA web site, but I can't seem to find them now.
I'll post a link or an abstract if I manage to.
--
vector at exea dot it
------------------------------------------------------------------------
April 21, 2005 - 19:15 : nedjo
Good points, useful references. The default regions I'm thinking of
are:
'banner' => t('banner'),
'left' => t('left sidebar'),
'right' => t('right sidebar'),
'body_top' => t('body top'),
'body_bottom' => t('body bottom'),
'footer' => t('footer')
Perhaps "body" would be better as "content"? It would be easy enough
to add in more regions, e.g., within the content (after title, after
help, etc.) One issue is that many of these regions will already have
rendered content. Should the blocks come before or after that other
content? I've assumed after for banner and footer, while giving both
options in body.
In any case, refinements or suggestions would be great.
------------------------------------------------------------------------
April 21, 2005 - 19:56 : resmini
Well,
'banner' => t('banner'),
'left' => t('left sidebar'),
'right' => t('right sidebar'),
'body_top' => t('body top'),
'body_bottom' => t('body bottom'),
'footer' => t('footer')
The classic (as far as classic goes for something Web related) scheme
comprises 5 spatial regions, much like stefan's
http://drupal.org/files/issues/regions---possibility-1.png with a left
area mirroring the one called 'blocks'. Call them top, left, center,
right, bottom.
Variants usually exclude one or more of these, layout-wise.
If we talk content (semantic) instead, things get a bit more
complicated, as these spatial regions normally include more than one
content-area. The top, for example, could include ad banners and the
site's header, or the main menu. But these merge seamlessly with CSS
definitions, which are definitely something that should get properly
standardized (most of the errors / inconsistencies I'm encountering
with Drupal today are related to this), but this is out of scope in
this thread.
What I somewhat object to the definitions above is that it mixes the
two approaches.
'banner' is not spatial, is content, as it is the distinction between
body top and bottom. If 'banner' goes there, it is 'top', whatever that
might be. I designed a couple of web sites which had
headers/logos/banners at the bottom of the page, and I'm not exactly
the wildest designer you'll probably meet.
And if we include body_top and _bottom, we should also add
'navigation', or 'menu' and some other content-related semantic region
(impressum, or company_data, or whatever).
I suggest that either we go along
'top' => t('banner'),
'left' => t('left sidebar'),
'center' => t('body'),
'right' => t('right sidebar'),
'bottom' => t('footer')
or we dedicate some time to detailing what could possibly fit there
semantically, which is perfectly possible without limiting design
freedom or whatever, since the vocabulary is not infinite, but not
something you do out of the blue.
Please note that I understand t('something') to be an example, since
such a layout only defines regions on the page, not semantic regions.
My main content could fit nicely in the bottom region.
As for the names for the regions, they are not important, as much as
they are coherent and enforced.
------------------------------------------------------------------------
April 21, 2005 - 22:16 : stefan nagtegaal
Attachment: http://drupal.org/files/issues/regions-final.png (2.39 KB)
Maybe something like this???
But, I have to say that I _really_ liked the solution to split the
'content'-region into the 'content' and 'beneath content'.. I love
that!
------------------------------------------------------------------------
April 21, 2005 - 23:20 : resmini
Stefan, yes.
That's basically what you can build if you stick with spatial, and this
layout can generate quite an amount of (sane) layout variations even if
you interpret it strictly (suppose a default) as
<div id="header">
</div>
<div id="left-bar">
</div>
<div id="content">
</div>
<div id="right-bar">
</div>
<div id="footer">
</div>
What you can do with this is left basically to the theme designers and
their use of CSS, CSS-P or tables (brrr), but this could be an easy and
proper way to identify macro-regions in which more accurate positioning
happens at a more specific level.
I'm all in favour of subsequent identification of sub-areas (top and
bottom in body), but I don't think it would be a good idea to mix the
different approaches I mentioned in my previous post.
A site with lots of things going on or which is not just blogging
surely has the need to use its content area in a wiser manner than just
putting there 'content', the number of modules doing precisely this is
more than proof, but that falls more in a 'Drupal definitive guide to
semantics', in which CSS selectors are used or suggested strategically
for such a scope.
>From this point of view and for the sake of this thread, any unique
area / div (#name) could (should?) be a target for blocks, and this in
my opinion (*) would be the perfect solution, but I do not know if and
how this is even remotely possible in the current Drupal.
(*) It's quite late, local time, and it was a looong working day.
------------------------------------------------------------------------
April 21, 2005 - 23:38 : resmini
Attachment: http://drupal.org/files/issues/regions-final-variation.png (1.9 KB)
Just to be clear, I add a variation of stefan's scheme that shows how
this is *not* by any means positional, but spatial, or better
relational. Use your CSS imagination to take out regions, reduce them
to empty containers, enlarge them, make them taller, shorter, whatever.
5 regions, do what you like.
------------------------------------------------------------------------
April 21, 2005 - 23:44 : resmini
Sorry, I forgot.
And this is also why I'm not too keen on calling anything 'content'. If
I enlarge my right region enough, why not put my content there?
Shouldn't this be a theme-level concern?
It's nothing serious, but if my center area is called 'center' (or
something similar and more sexy), I won't confuse anybody.
This is left, center, right: do with them what you prefer. Content in
the bottom? Show me.
If I call something 'content', I'm more than suggesting that content
goes there, and only there.
------------------------------------------------------------------------
April 22, 2005 - 09:17 : stefan nagtegaal
Resmini, maybe it is only me but I think that you are making a mistake
in your way of thinking..
I get the feeling that you're mixing the 'regions' and 'divs'.. the
'regioins' should have meaningfull sentences, but the divs
shouldn'thave..
As an example:
$region_name => $content_body
here we go:
'header' => $logo
'left sidebar' => theme('blocks', 'left')
'right sidebar' => theme('blocks', 'right')
'content' => $content
'footer' => $footer.
So, $region_name does not have to be equal to the id or class of the
divs..
------------------------------------------------------------------------
April 22, 2005 - 10:27 : resmini
Stefan,
>So, $region_name does not have to be equal to the id or class of the
divs..
Yes, absolutely. I probably didn't make myself very clear: what I'm
trying to point out is that in
'header' => $logo
'left sidebar' => theme('blocks', 'left')
'right sidebar' => theme('blocks', 'right')
'content' => $content
'footer' => $footer.
there is no reason at all to call 'content' the region that holds
$content.
nedjo asked in #24
'body_top' => t('body top'),
'body_bottom' => t('body bottom'),
if /Perhaps "body" would be better as "content"?/ and all my reasoning
is simply that no, that is not content, or it shouldn't be (or better:
it may happen that main content is elsewhere). As a matter of fact,
even the connotation 'sidebar' doesn't fit very well logically.
To make it short: Today's method works, but has limits. Mambo, which
paragkenia quotes at the beginning, handles more 'user regions' but in
pure Mambo style conventions are so loose that they are hardly useful.
If we define regions, as in nedjo's example, in my opinion these
regions shouldn't imply informational layouting, only relational
positioning (that is, where they stay in the browser viewport).
I know it may look like overdesigning, but Drupal constantly enforces
conventions and coding guidelines everywhere: this is one of the best
aspects of the project and I think it should carry to the layout.
------------------------------------------------------------------------
April 22, 2005 - 10:32 : stefan nagtegaal
While I think that 'body_*' is not as self explaining as 'content_*' I
vote for using 'content_*'..
------------------------------------------------------------------------
April 25, 2005 - 18:48 : chx
Let's get back to the code. If my understanding is correct the big
discussion is about how to name potiental rectangular areas _after_
this is commited. So, first get this committed. What's need to make
that happen?
------------------------------------------------------------------------
April 25, 2005 - 19:56 : chx
I spoke with Moshe, Steven, JonBob and the result is: keys shall be
numbers, and themes shall define the values. We will make region zero
and one required. There will be a define('REGION_CONTENT', 0) and a
define('REGION_SIDEBAR', 1); so you can have readable code still.
Either wait for me to code it or feel to do it yourself, just drop me a
mail via the contact form if you are doing it.
------------------------------------------------------------------------
April 27, 2005 - 17:14 : nedjo
Károly, it's great if you're willing to take on finishing this. I
tried to summarize remaining work in update 20, above [4].
The numerical keys look fine to me.
In terms of an initial default set of regions, one quirk is this: for
now, so far as I can see (and assuming the approach I sketched in),
available regions can be defined only in (a) theme engines and (b)
individual themes that don't use an engine. So, for instance, an
individual xtemplate based theme can't define its own custom regions;
they need to be defined in the theme engine. (Unless and until the
whole theme system should switch to the sort of configuration file
adrian suggested above [5].)
Which is to say that, under this approach, we'll be defining a set of
regions for each engine, and then all themes using that engine should
try to implement those regions. (Otherwise, if a site admin selects a
region defined in the engine but not implemented in the default theme,
the content won't appear.)
Please let me know if there's anything in what I've done that isn't
clear, or if you want to pass some or all of this back.
Thanks!
[4] http://www.drupal.org/node/16216#comment-27398
[5] http://www.drupal.org/node/16216#comment-27052
------------------------------------------------------------------------
May 9, 2005 - 21:36 : chx
I had a "short" discussion with the UI team leader ie. Ber Kessels. The
outcoming is that we will change hook_block so that it uses callbacks a
bit like menu system. Here's an example:
<?php
function module_block() {
$items = array();
$items['module_header'] = array('callback' => 'mymodule_page',
'weight' => -50, 'region' => 'content' , 'cache' => TRUE, 'pages' =>
"node/*\n<front>");
return $items;
}
?>
Please note that we are allowing caching the themed output of each
block independently.
The theme system will execute hook_block as it does now and it'll
execute the callbacks defined in module_block as well. Of course if the
callback is cacheable and in the cache, it'll print it from cache. If
it's themeable and not in the cache, it'll cache it before printing.
Pages contains a string (could be PHP code!) which can be overriden in
the block configuration screen.
Callbacks defined in hook_menu will have lot less functionality after
this, they will be used for non-themed pages mainly.
------------------------------------------------------------------------
May 9, 2005 - 21:45 : chx
More explanation is requested for the example.
module_header is the unqiue name of the block.
pages define on which pages the block is visible. ('pages' in the block
configuration screen.) Maybe I'll implement 'visibility' from the same
screen as well.
callback, weight are well known Drupal terms.
cache is a boolean which defines whether given output is cacheable or
not.
------------------------------------------------------------------------
May 9, 2005 - 21:47 : chx
Ber, Dries, do not kill me! Ber chaired the usability meeting in
Antwerp, that's all.
------------------------------------------------------------------------
May 9, 2005 - 21:52 : Bèr Kessels
Attachment: http://drupal.org/files/issues/more_regions_principle.png (123.29 KB)
attached is a schematic which might clarify this a little.
And I would also like to comment on me being the UI leader: I do not
consider myself any leader, no ofeence, though. Just to clarify that.
------------------------------------------------------------------------
May 9, 2005 - 23:42 : nedjo
I am not opposed to the idea of changing the _block() hook to use
callbacks (I have no opinion on it, not immediately grasping the need),
but this seems quite distinct from the aim of enabling multiple and
extensible regions. Why can't we just move ahead with the block
generalization?
I suggest:
* quickly implement the proposed block region generalization, using
only the two existing regions (i.e., implementing them in core themes)
* later worry about:
- adding further regions (the details of which are best done by those
primarily responsible for the particular themes)
- possible changes to the _block() hook.
Wouldn't this make sense? Or am I missing some pressing reason for
which the block generalization has to wait?
------------------------------------------------------------------------
May 10, 2005 - 02:28 : killes at www.drop.org
"Or am I missing some pressing reason for which the block generalization
has to wait?"
I might be missing something too, but I thought Chx was just talking
about the block generalization and proposing a way to code it.
------------------------------------------------------------------------
May 10, 2005 - 03:41 : factoryjoe
I wanted to chime in with this discussion because it's an important one
and has some really huge implications for Drupal moving forward. That
said, I also have a day job pulling all my attention which means that
the big ideas I have for this problem can't be put into a complete
visual form for at least a week or more. In the meantime, I'd like to
offer a few thoughts on the matter.
*Regions do not belong in themes.* Blocks were originally separate from
themes for a reason. Themes should define the general look and feel of a
site -- and to some extent a site's behavior. Layouts which define the
spatial relationship between regions belong in some intermediary
between style and content, which does not currently exist in Drupal.
I would propose that *layouts become a new kind of CCK tool.* By that I
mean that they can be defined, shared and deployed very easily -- even
as simply as tossing a directory of some .layout textfiles into a
layouts/ directory. Note that this suggestion has nothing to do with
the way CCK /might actually/ work right now; instead I'm suggesting how
I would like it to work. I would like, for example, to create a CCK item
like a "person" and ship it with a .layout file that carries all the
semantic goodness needed to output that "person" to the screen in
juicy, semantic markup... which anyone can come along and theme to
their heart's content.
*Creating shareable layouts should be relatively painless.* Dashboard
[6] sets the bar for easy hackability. It should be that easy to create
layouts for Drupal... I can imagine creating an "iTunes layout" or an
"Image Gallery" layout and so on... If we used something akin to PHPTal
to develop the layouts, we could keep development fairly standard while
making it possible for more folks to hack up cool and innovative
layouts.
*Layouts should be extensible.. to a degree.* I see a huge problem with
how this discussion has floated back and forth between semantic and
spatial region naming. Because we talk about this problem in those
terms, we fail to identify the real problem and opportunities presented
to us. Here's the thing: when you predefine regions, you limit
creativity and the ability of people to really use the system. On the
other hand, when you make a system too flexibile, it quickly becomes
unwieldy. In all the mockups presented above, both classes of problems
would arise. Therefore we need to think about a way to stay flexibile
while "taming the beast."
To that end, I suggest developing *self-contained layouts that are
contextually-complete.* So for the example of the iTunes search
layout... you would know before hand that you get a couple multiple
select boxes that you can hook up to whatever taxonomies you want to
progressively filter [nodes]. You could even change the .layout file,
allowing you to theme it to your liking -- even though that would
totally optional, given the layout's internal default styling. Once
you've got your layout, you would go into a layout module UI [7],
create a new layout [8], select the layout from a list [9] and then
give it a path so you can access the layout... You would then walk
through a wizard [10] that would help you populate that layout with all
kinds of nice Drupally goodies... feeds, node listings, PHP code, etc.
The power in this approach is multifold. For one, it snaps Drupal out
of its block mentality and allows designers to really innovate with
individual page designs. In fact, I've already thought out how I could
reimplement Flickr using this system, combined with Drupal's native
feeds, taxonomy and menu module, and I'd barely break a sweat... sort
of. ;)
But anyway, this is a very productive conversation to be having, but I
really think that we should consider whether the old paradigm, as such,
really pushes Drupal as far forward as we have the opportunity to go.
[6] http://drupal.org/apple.com/macosx/theater/dashboard.html
[7] http://photos4.flickr.com/6944826_90af237c99_o.png
[8] http://www.factorycity.net/demos/civicspace/layout/new.html
[9] http://www.factorycity.net/demos/civicspace/layout/new_layout.html
[10]
http://www.factorycity.net/demos/civicspace/layout/testing_add.html
------------------------------------------------------------------------
May 10, 2005 - 05:34 : chx
While factoryjoe may be right, I could be right as well.
Regions has definitely something to do with themes, after all it's the
theme that renders the page, and it can only render regions that it
knows of.
So, instead of postponing this into the far future when someone comes
out with a layout system, I code this now.
------------------------------------------------------------------------
May 10, 2005 - 06:22 : Dries
The proposed 'weight', 'region' and 'pages' would be configurable, not?
Are these just defaults? The 'callback' and 'cache' options are nice to
have.
------------------------------------------------------------------------
May 10, 2005 - 06:25 : chx
Yes, blocks can provide a default for everything on the block and and
configuration screen. Of course, you can override these in the UI.
------------------------------------------------------------------------
May 10, 2005 - 10:02 : Bèr Kessels
Dries: yes, the region, weight and pages will be configurable from an
admin interface. What we tried to address here, is a method for
developers to choose good defaults. Take for example "logo". that
should be enabled by default in a regions called header, rendered on
all pages, and have a very light weight. We should not force an admin
to visit the blocks admin before she can see or use the logo.
Chris: I do not know if you have ever tried typo3. Its concept is some
form of builder system. I do not like thar, because far too complex. If
we ever get sme kind of builder in core (if ever) it will require a lot
of work, and even more usability research. So for now such a builder is
far out of our reach. Lets aim at goals that are more realistic ;) So:
it does belong in themes, its the best place that is still realistic.
I do like your visions, Chris, but I hope you agree they are not
realistic, yet. So, maybe you can think of a path towards your visions,
ow we can reach such a builder-system, you describe?
------------------------------------------------------------------------
May 10, 2005 - 15:52 : factoryjoe
My browser crashed before I was able to submit my followup to chx's
comment... I have no problem with the current work going forward and am
happy to see it happening. I know that my ideas are typically
outlandlish and far off... That's the kind of design I enjoy doing!
In any case, I see chx's solution being a means to an end; once we have
abstracted the region code, it become much easier for me to get some
help creating my vision.
In the meantime, and as a demonstration of how I see this layout system
working (to answer, I hope, Ber's concerns about clunkiness), I've
created a workflow movie that shows off how fast you'd be able to add
content to the system.
Check it out:
http://factorycity.net/demos/civicspace/layout/media/layout_workflow_v1.mov
Feedback appreciated. And, if you want to try the demo out yourself
(it's all hardcoded, like a "movie set" for my UI), go here:
http://factorycity.net/demos/civicspace/layout/
------------------------------------------------------------------------
May 12, 2005 - 17:45 : nedjo
Attachment: http://drupal.org/files/issues/block-dynamic-regions4.patch (13.56 KB)
"I might be missing something too, but I thought Chx was just talking
about the block generalization and proposing a way to code it.
"
Well, if I can say so respectfully, I don't think so. Not so far as I
can see identifying problems with my original patch, this interesting
discussion is rather addressing the (useful, but logically subsequent)
question "once we have multiple regions, how should we work with
them?". It's perhaps demonstrating our propensity to try to do more
rather than less with a given patch--to talk for a long time when a
first step solution is already in place. So here is a (yes, interim!)
small, focused, and tested patch to remove the hard-coded regions.
I've stripped it down so it does nothing more than (a) make block
regions declared by themes rather than hard-coded and (b) implement the
existing left and right regions in existing core themes. Please, try it
out, I think you'll like it. I'm of the (I'm hoping not scandalous)
opinion that it can be applied right away, and so clear the way for
further progress. In particular, this patch leaves the adding and
configuring of additional regions to theme authors/maintainers, who are
best qualified for the work.
"I spoke with Moshe, Steven, JonBob and the result is: keys shall be
numbers, and themes shall define the values. We will make region zero
and one required.
"
The reason I moved from numbers to strings (e.g., "left") is that a
theme author defining regions has no way of knowing what regions might
have already been defined, and therefore what integers might have
aleady been used. It's like module and theme names--we'd have to use
random numbers to avoid conflicts, so we're better off with string
names.
More information about the drupal-devel
mailing list