[development] more consistency in theme functions and output concepts.

Bèr Kessels ber at webschuur.com
Thu May 11 09:57:51 UTC 2006

Hi there,

For my helpers module I am trying to be ACAP (as consistent as possible). And 
some things I have (not yet) decided on, but which IMO could be very usefull 
for the codyng guidelines and core:

* I filter ONLY in the theme function. That way you can be assured that theme 
functions get the raw data. Having ONE place, and one way where/how we filter 
makes it easier to look for sec. issues. 'My rule' is: As soon as we make an 
HTML string from something, we filter it. Anything that gets HTML 
programatically is therefore filtered.
* t(): on the same level. Only in the theme level do we output t()ed strings. 
This makes it a lot simpler, because you know that functions and methods pass 
the original strings along, and that they are only translated in the VERY 
END. This should also make testing against strings a lot easier. I even found 
a critical sec. issue that opened the "access control open to the world" 
because I translated two string similar. 
* whenever a (theme) function can receive HTML as optional string, that string 
is NOT translated. eg theme_emtpy_placeholder($message = NULL) will return 
t('not available'), if no param is passed. But the doxygen states: @param 
$message: Optional. Provide a translated message string.
* Theme functions can call other theme functions. They should do so, at all 
times if there is a function that formats what they want to output (ie call 
theme_item_list() instead of internally building up LI strings!). 

These are merely ideas, and I think we can and should make something simpler 
or maybe even this as guideline. We can then make sure that all changes to 
core at least follow these guidelines. 

More information about the development mailing list