Re: [development] someone make a theme out of these templates
Adrian Rossouw wrote:
What I would like to see us do, is remove all html from module files and move them into tpl.php files. Fantastic idea. I'm all for it. But on behalf of people using other template engines, will it work with anything but phptemplate?
while we are doing this, we completely refactor all the html Again an excellent idea, and whilst doing it all at once is a big job it really gives us the opportunity to standardize.
you can override any theme function by just copying the file to your theme directory, no fucking around with template.php. Which makes it even easier. Nice.
It becomes a LOT simpler to write a theme editor, Not so excited about that one. I've got BBEdit, Smultron, Dreamweaver, Quanta Plus and CSSED. Professional tools win out over in page editors every time :)
Still, I can see that certain people and companies using Drupal would welcome that.
it becomes possible to distribute alternative template files, like different node views etc. That's also excellent!
I don't suppose we could also say that modules don't need to ship with their own CSS files could we? -- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
On Wednesday 08 March 2006 15:42, Adrian Simmons wrote:
Adrian Rossouw wrote:
you can override any theme function by just copying the file to your theme directory, no fucking around with template.php.
Which makes it even easier. Nice.
it becomes possible to distribute alternative template files, like different node views etc.
That's also excellent!
I don't suppose we could also say that modules don't need to ship with their own CSS files could we?
I'd actually suggest that CSS files then become like the tpl.php files. The module ships with its own that is named module.css definitively. A theme can then override it by including its own CSS file of the same name. Poof, no more dealing with the legacy bits from that module. (And if we can get core modules into their own directories and break drupal.css up for them, that solves most drupal.css issues.) I'm wary about everything as a tpl.php file, though. That's a LOT of disk hits per page then. I've also found that frequently a theme function in my module is all I need, whereas thinking about a template file requires my brain to switch gears. I don't know that I want to have to make my brain switch gears every time I get to an output command. :-( -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Op woensdag 8 maart 2006 22:42, schreef Adrian Simmons:
What I would like to see us do, is remove all html from module files and move them into tpl.php files.
Fantastic idea. I'm all for it. But on behalf of people using other template engines, will it work with anything but phptemplate?
I really do not like the idea of having all those files araound. I foresee a (CVS (and no please do not shout BZRSVNETC)) maintainance hell. A hel that will wipe all beneifits of this approach from the map. 1) they need to be called on every page anyway, so no memory benfit (like locale.module). 2) they are highly inter-related. If you change something in file A you need to do so in B C and D. with CVS, or without CVS a hel to maintain, let alone to understand, when learning an existing module. 3) All HTML that lives in modules is wrong there anyway. We need more HTML generation API's, true. But already we can assume that ANY HTML tag in ANY module is in fact a minor bug. I would rather call for a frenzy to actually remove ALL the HTML from any (contrib) module. IMO, the only part that is allowed to contain HTML is the theme layer, and the theme.inc. Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ] Hoe het naviatie blok te verbergen: http://help.sympal.nl/hoe_het_naviatie_blok_te_verbergen
Bèr Kessels wrote:
2) they are highly inter-related. If you change something in file A you need to do so in B C and D. with CVS, or without CVS a hel to maintain, let alone to understand, when learning an existing module. You're losing me here. If you updated the module you'd need to update the module.tpl.php, and maybe the module.css. You've gone from two files to three - all of which (if I understand Adrian's proposal correctly) are sitting in modules/modulename/ anyway? Going from two to three files per module doesn't seem all that much harder.
You're right, that from the module builders end this would make things more complicated and create some extra work. But from the theme-builders end things would get easier.
3) All HTML that lives in modules is wrong there anyway. We need more HTML generation API's, true. But already we can assume that ANY HTML tag in ANY module is in fact a minor bug. But isn't that part of what Adrian is proposing, the separation of xhtml from the module logic? And yes API's are obviously useful for common elements, but they'll never replace all xhtml, and some modules will always need custom xhtml.
I would rather call for a frenzy to actually remove ALL the HTML from any (contrib) module. Think of this as a step in that direction :) Drupal moves in drips, not big splashes, you know that.
-- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
Op donderdag 9 maart 2006 12:23, schreef Adrian Simmons:
You're losing me here. If you updated the module you'd need to update the module.tpl.php, and maybe the module.css. You've gone from two files to three - all of which (if I understand Adrian's proposal correctly) are sitting in modules/modulename/ anyway? Going from two to three files per module doesn't seem all that much harder.
You're right, that from the module builders end this would make things more complicated and create some extra work. But from the theme-builders end things would get easier.
If I change the way my theme function works, I suddenly need to do this ni two locations. The calling and implentation no longer live in the same location. e.g. theme_coffeemug_print($image); In the current system the caller theme('coffeemug_print', $image); and the function theme_coffeemug_print($image); live in one file. I now want to add a $location theme_coffeemug_print($image, $location) if its on file, this is rather easy to do. But if I have to do this in two places, its going to be hard to maintain [1]. I love the fact that our modules are most of the times selfcontaining: one file has it all. This, in fact is one thing I dislike about, for example flexinode. During development and upgrades, i have always had trouble with one (or more) of the .inc staying behind, becoming stale, conflicting etc. More then once I had to rush into vi to hand-edit such a file. Another thing that strikes me as not-so-good is that IMO a theme and a module are two different layers in Drupal. Having my theme spread over /themes/MyTheme/ and in /modules/*/*tpl.php is not my idea of clean and simpler development. The solution would be to move stuff around on _install strikes me as even less then ideal. My solution, the one i am working on right now is the scaffolding stuff I am doing for sympal_scripts. I tested a system that * calls drupal, checks for all node_types that are enabled. * takes a template node-type.tpl.php parses that to add some varibles in place of tokens * puts that in /sites/mysite.com/themes/mysite_custom_theme/node-$type.tpl.php Already workes on my laptop, but has some ugly apache/php permission issues, that i need so solve more globally. *I* (note the stress on the I) think that route I layout here, IE scaffolding and so, is a far better one for Drupal. In any way, a better one for us, developers and consultants. Joe with winzip, ws_ftp and plesk will not be able to use this, unfortunately. Bèr [1] maintainance includes CVS repositories, readme, updates done by all users, etc. -- [ Bèr Kessels | Drupal services www.webschuur.com ] Hoe het naviatie blok te verbergen: http://help.sympal.nl/hoe_het_naviatie_blok_te_verbergen
participants (3)
-
Adrian Simmons -
Bèr Kessels -
Larry Garfield