[development] Switching themes in modules

[Alan Dixon]

On 6/22/06, Moshe Weitzman <weitzman at 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/