On 06 Jun 2006, at 5:59 PM, Jenny Hsueh wrote:
but having the notion of "enabled" and "default" theme is essential to us, we use groups on our sites and having the ability for each group to choose their own theme seems a kicker, people feel that's a space belong to themselves. If there are other ways to achieve the same result it will be fine, but we don't want to lose the user specified theme capabilities -- i.e. make sure the contribute module for multi-theme support is available at the same time when it disappears from the core.
Well. I'd like to see the multi-theme support module in contrib be done 'right (tm)'. Please forgive the terminology I am going to be using , the confusion is due to the views module coming into existence. This is one of the two ideas I have that could both conceivably be called 'views'. (the other being the V, from the mvc pattern that fapi is moving us towards). Here are some pics i made up a long long time ago, about how i feel it should be done. Essentially the combination of theme selection + configuration settings + block layer (+ additional theme config modules) = a 'view' , or a 'layout' or a 'section'. I will use 'views' in this post. Basically underneath the hood, the admin/display page is actually just configuring the default view. When you install the multi-view module, you get a new menu item, which opens to a page like this : http://drupal.org/files/issues/Picture%202.jpg Each one of these views is exactly the same as the default view, with exactly the same options. Except each of these views has a 'weight' , and a set of rules that need to match for it to be selected. Any module can create rules. Some basic ones would be based on date, based on role , based on OG .. whatever. The view's rules get configured via an interface (http://drupal.org/ files/issues/Picture%203.jpg) that's almost exactly like your web browser. Ideally, I would like to see this kind of interface completely supplant the n*count($themes) + m*count(blocks) + o*count(throttle settings) + p * count(possible sections module config) ... ... ... ... ... which all have weird interdependent ways of changing exactly what you are going to see on your site. Additionally, we can ship with a special 'admin' view, pre- configured, that can't be modified, unless you have the multi-view module enabled, in which case you can adjust it at leisure. Also part of this, now that every 'view' is just a collection of settings, stored in the variables table, is the possibility to spawn one of these config pages for every user blog for instance, or per user. The loading would happen in exactly the same way we have the $custom_theme loading now, so we wouldn't be making the interface unusable. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com