Ok, well there is all this arguing about skins and different usability of certain visible elements, and cheese (etc.) . I mentioned templates the otehr day. We need them, it's the only way to put an end to this stuff, plus It'll make The whole process of changing the look of the wikipedia a lot easier. This is the standard I am proposing, if anyone wants to start coding this cheese up drop me a line and we'll do it, I don't have CVS access but I have a sourceforge account, besides I don'nt need it, I'll just submit it as a patch because it might not even get accepted. Point being, heres my idea
Template sytem: SMARTY (http://smarty.php.net)
-/WIKIROOT |-/skins |-/skin1 |-view_article.php |-edit_article.php |-preview_edit.php |-/templates |-template1.tpl |-template2.tpl |-template3.tpl ... |-/skin2 |-/skin3 ...
You get me? Baiscally wiki.phtml just gathers the data, places it into variables and then includes() the necessary file from the correct skin directory. That file puts the data into its necessary templates and then spits it out. What do you think?
Here is the crucial part. HTML should completely disappear from the rest of the script. EVERYTHING. no HTML and no strings in the code, AT ALL. strings go into a localization file, HTML goes into templates. The apropriate *.php file from the skin's dir.
i8n is handled by the main program, the skin files should be "dumb" to a certain degree. They should be handed all the data they need, all they have to do is put it in the right place and format it a little bit. To acomodate localization correctly we should have a couple of flags, for example one for bi-di. The rest is up to the skin.
Markup. This is kinda weird.. because if the main script handles it then we break the no HTML thing, but then again, if it doesn't we have a bunch of skins with different mark-up parsers? I don't know. The only thing I can think off is to have a file especially for that function. Skins should include() that file and use that function, but if it comes down to it. we could just switch files for different markup parsers. eg, we could have a normal html one, and one that makes totally valid, (no depracated) html, and even one that spits out XHTML. of course It'd be important to make sure these are synched up. anyways, what does everyone think? Anyone want to Join me on this task?? I mean I want to do it, but if no one really thinks this is a good idea it's kind of a lot of work to do, so I only really would be willing to do it if people think this is a worthwhile effort.
Lightning