[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