Home : Journal : Archive

Tuesday August 1, 2006

Jani responds

Anglosphere

On Slashdot, I predicted that Jani Taskinen would respond to the outcry over his remarks:

If we follow Occam's razor then surely he would deny the words if the logs aren't true while if they are he would apologise for a sad, emotional rant. I suspect returning from his decision that he cannot work on PHP as long as Israeli Zend backs it is rather impossible at this point, but that decision in itself is respectable even for people like me who disagree with the logic (or even viewpoint) behind it. It is his right not to want to work with Israelis, but for his own sake I hope he tries to do some damage control.

And I think his PHP contributions are not the most notable background here. He's a UN peacekeeper and has in fact been stationed in Lebanon. If you think the PHP team is not going to be happy about this publicity, think of how the UN should feel when there own forces make such emotional hateful rants in public after a "friendly" fire incident - as bad as that incident may be.

And indeed he has responded:

I apologize for the wrong choice of words in "fuck jews" where it should have been "fuck israel". And of course I mean the government of Israel when I say "I'm anti-israel". I have friends who are jews and it does not bother me at all. Hopefully they don't get offended by those remarks I made.. :(

Unfortunately there is no explicit apology for the call to "nuke Israel", which is more worrisome than someone merely opposing Israel's government. However, any apology is better than none. I'm not Jewish nor Israeli so it's not for me to accept it, but it may please those who are.

Of course I still have doubt whether people demonstrating emotional outbursts in are fit for duty. In the specific case of Jani, I find it hard to find a firm position on whether his views of Israel are relevant to the UNAMA-AFG mission assisting NATO-ISAF. But I hold it possible that the UN will be more careful now to assign him to any mission in the Middle East in the future, or that Jani himself would turn down such an assignment. I'm curious, but I think this wraps matters up.

Most annoying MSN emoticon (ever)

Software

In MSN Messenger, you can specify keyphrases to be replaced with images. Usually used to make punctuation extremely dominant and expressive (pretty ironic for a medium where punctuation is often ignored), or to put some wicked randomness in phrases such as lol.

Most of the time, emoticons are harmless at worst and fun at best. Sometimes, they nearly cause a heart attack.

https://robertjohnkaper.com/img/journal/20060801-lol.png

(In case your browser doesn't support animated PNGs, the text has a border: large, red and blinking. HT: iluvpingviini)

Put HTML in your code!

Software

Most web developers will tell you to separate your HTML from your code. I'm going to defend an unorthodox view: put HTML in your code!

Let us be honest here: HTML is not going away. Web sites aren't going away. The ones from 1993 still render and most sites haven't even upgraded to the latest standard yet, let alone that they would abandon it alltogether for something radically different. So who cares if there are bits of HTML in your web site application? One could argue that separation would make it easier to expand the engine to radically different presentation layers, but in practice.. who seriously needs that? HTML works pretty well for most people. Add CSS and (now that's useful to normalise and separate, also for the sake of graphic designers), and JavaScript (also easy to separate with includes as dynamic JavaScript code should not be necessary with the right hooks) for xmlHttpRequest and web sites can do very much on many media (screen, print, etcetera).

I also don't think that separate HTML templates make maintenance easier. If the code base is properly normalised, that's sufficient aid to a developer to find what needs editing. HTML templates can contain references to variables, arrays, other templates, Javascript calls and often some simple scripting logic (if/else, loops).and so on. Anyone using them will need to have some skills in working with the code base anyway. Might as well keep it in one language without the proxy template scripting and echo the necessary HTML.

In fact, when a change of logic alters the desired output, it's a lot easier to see bit of HTML within code than both having to look for a template and needing to adjust to the new scripting rules in it.

And just look at the state of affairs: most template systems I've come across tend to lead to extreme amounts of duplication. I have one single line in all of my code which is responsible for, say, the

tag. If I've called $page->onLoad() with a string, it will attach onLoad="string()" to the tag and the JavaScript will load. This line is in Page::header() which I need to call on all pages. Most template systems don't even normalise these basics and those who do become a game of constant guessing which string is where.

A method in my User class:

function userPage( $urlOnly = false )
{
$url = "/users/". urlencode( strtolower( $this->login ) ). "/";
if ( $urlOnly )
return $url;
else
return "". htmlspecialchars( $this->login ). "";
}

Perhaps I could move the "/users/" part to a User::baseURL() variable. I believe there is a wrapper that prepends http:// and the domain name that could be handled in a nicer way. But other than that.. why, for a freaking web site, is this considered to be ugly? I bet my web site code and HTML are far easier to maintain than the majority of template-based systems or other attempts to separate code and output.

Seriously.. my code is full of echo statements, even though a lot of output is first pre-generated in strings by class methods. Definitely beats having a gazillion tiny templates or worse, template scripting in yet another hacked together language.

It's wonderful that some people use Java, PHP or Perl to write a scripting language for their web site, but don't try to tell me it's a silly idea to just write the web site directly.

Next day: Thursday August 3, 2006 Previous day: Monday July 31, 2006

© Copyright 1995-2007 Robert John Kaper. All rights reserved.

Powered by the delicious Kiki CMS! (#8/9)