[themes] Re: Rapid Theme Development was: Re: [development] Administration Survey: Theme improvements, theme help system, theme mailing list

[Darrel O'Pry]

On Tue, 2005-12-13 at 09:37 -0500, Trae McCombs wrote:
> andre wrote:
> > Well - the 90-10 rule applies.  I get get 90% of a theme done very 
> > rapidly and have a pretty good looking site at the end of a short 
> > session (i.e. matter of hours).  But, its that last 10% that takes 90% 
> > of the time.  All the special cases - all the different forms - 
> > different node types - different 'sections' of a site that require a 
> > different look etc.  All the tiny annoying little bumps that require 
> > ironing.  That's what's a pain in the ass.
> 
> I think half of the problems I encounter themeing different drupal sites 
> is with the different modules.  Every single developer out there wants 
> to code something in one way or another.  And they all want to use page 
> breaks (<br /> [yes, that is the proper way you print out a "<br>" 
> people!) in places where you, the themer, might not necessarily want 
> them.  So if you are themeing all the different form elements, you are 
> constantly scrambling for different classes and ID's to try and theme a 
> particular form to look a certain way.
> 
> I honestly don't understand why there isn't, and wasn't, a common set of 
> practices decided on long ago for people to use when building modules. 
> I am thinking that's what this new "forms.api" stuff I keep hearing 
> about is for... I'm not sure.
> 
> The biggest bulk of a Drupal themers problem is, you typically can't 
> just theme, all generic selects, inputs, etc.  You have to specifiy 
> certain elements and my gosh, there can be tons and tons and tons of 
> them.  Ending up with a nasty huge giant amount of CSS.
> 
> Dries is right, it shouldn't be this hard to theme.  I should be able to 
> theme the header, sidebars, footer, content area, select, input, and a 
> few other things and be done.  But that is not the case.
> 
> Before anyone goes asking me to patch something, I do graphics, and know 
> CSS.  I don't code.  So, no, I can't "submit a patch"[tm]
> 
> Trae
> 
> > But, most of this is unavoidable.  This time consuming stuff isn't the 
> > fault of the themeing engine or the templates... its the natural result 
> > of people wanting to modify things because they don't want a 'stock' 
> > vanilla looking elements.  They want to mod almost every detail - and 
> > that kind of modification takes time.
> > 
> > And also keep in mind that some of these mods that make a site look 
> > 'unique' aren't just simple theme overrides - they are hacked and 
> > modified modules - that become completely new modules and/or new 
> > functionality contributed back to core modules.
> > 
> > andre


One of the things that often buggers me theming drupal, is modules that
randomly append their output to node->body... I like having their
output, but in a sensible way that will work with my theme.

Its easy enough to override the theme_* function, but I still have no
control of how they are ordered when they're attached to the node.
Same with links in a way.


I've been toying with the idea modifying  modules to write to
$node->html[modulename] instead of node->body so I can have better
control of where their output is placed and whether it is displayed or
not in different contexts... The a template engine can use a
foreach($node->html as $key => $value) {
	$content .= $value;
}

before passing it to its theme...

and if you could do something like array_sort($node->html) You could
have finer grained control through the ui for managing output added by
modules.

If this is a completely absurd idea, please someone knock sense into
me.