On 6/22/06, Moshe Weitzman <weitzman@tejasa.com> wrote:
A theme switch module which allowed you to choose theme engines/themes based on the view being generated may be fun, but how often on a site do you really need this level of abstraction in the presentation layer?
lets get pragmatic here. sometimes users want a different look for their "space". "different look" might meen customized blocks and customized colors. for example, the Brazil organic group might want the Soccer News feed on top and the yellow color scheme. their organic group. is that a valid requirement. if so, how should it be implemented?
Yes, that's a good question. We've had some discussion in og's case here: http://drupal.org/node/66155. I've also been irritating you here http://drupal.org/node/67787 with a different approach to a slightly different version of the problem. I hope we can find some good answers. I suspect part of the challenge is that we're working on different sets of unwritten requirements (along with the usual pressure to deliver results).
it is fine to say that most sites/modules not switch the theme. thats accurate. but sometimes it is a valid system requirement IMO.
This is semantics, but I would call "modules/sites switching the theme" an implementation decision - the "requirements" would describe the user's experience rather than how that would be achieved. On the other hand, I think your concept behind og is that each organic group behaves like it's own site, and that includes a custom theme that could be separately chosen and maintained by each group. And that would be pretty ugly to implement with a single theme.
alan's link points to a bootstrap bug thats been fixed. i don't think it strengthens anyone's argument unless you believe in folklore like "bad things happen when you switch themes"
Okay, sorry - I should have provided more narrative. The thread was resolved by moshe's excellent patch to the bootstrap process, and it was og's use of theme functions in og_init that made the problem with the bootstrap apparent. So this is good - og pushed the boundaries of the code (in conjunction with 18n) and a problem was discovered and resolved. Another narrative in there is that hook_init is dangerous and that modules have to think carefully about what code in there might do. But my point of including the example was the observation that the reason you were using og_init was because you wanted to set the theme early enough in the process, which (as I understand it - but you'd know better) isn't part of the basic drupal code assumption. So my conclusion is - it's worthwhile to step back and rethink the requirements and see if it can be implemented without modules having to switch themes. If (as you've concluded) it can't, then I'd guess that the bootstrap problem might not be the only consequence, and some core support for this idea would be important (e.g. what happens when two modules are trying to both set different themes?). -- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/