Tag Archives: Form

Detecting Pressed Key with e.which in JavaScript

You have definitely decided to get which key has been pressed with JavaScript? This is very common when it comes to an Enter key press over a form element. Actually this should be automatically done by the browser, but when it comes to a default prevented form you’ve to check it for yourself.

The job can be done with a event’s which check. Let me show you some JavaScript/jQuery code:

$('.selector').click(function(e) {
	console.log(e.which);	
});

Note that this can be checked under Firefox and/or Safari like browsers which support the console object. This will give you the idea which key is pressed in a number value. The Enter is usually 13!
If you don’t have such browser, you can replace that code with something like:

$('.selector').click(function(e) {
	alert(e.which);	
});

Inline Scripts with Zend_View_Helper_InlineScript

Once I’ve posted about Zend Framework and script injections into the view of the app. However back than I didn’t mentioned the way the scripts can be injected on whatever place into the markup. This job’s done by Zend_View_Helper_InlineScript and that’s only an abstraction over the HeadScript.

However thus the PHP code goes quite clean and maintainable.

$scripts = $this->view->inlineScript();
$scripts->appendFile('/scripts/production.js');

This is quite interesting because in the case of multiple scripts you can chain them into this:

$scripts = $this->view->inlineScript();
$scripts->appendFile('/scripts/production.js')
            ->appendFile('/scripts/development.js')

But that’s not everything. Although it looks very pretty and clean, PHP gives you the correct syntax of something like this:

$scripts = $this->view->inlineScript();
$scripts
            ->appendFile('/scripts/production.js')
            ->appendFile('/scripts/development.js')

And that’s particularly good when it comes to fast switching between production and development scripts includes.

$scripts = $this->view->inlineScript();
$scripts
 //        ->appendFile('/scripts/production.js')
            ->appendFile('/scripts/development.js')

You’d ask why I’d to comment my script includes. Because as it appears to be fashionable the JavaScripts are concatenated and compressed. This gives you performance benefits on the client side when downloading and executing the script. So it’s usual to have one compressed/minified and several development scripts. That’s why this commenting strategy is very useful.

How to Sanitize User Input in PHP?

It’s a question almost every PHP developer asks yourself. By me the most simple way to sanitize the user input is to save everything in the database with no loosing of tags or whatever HTML markup and than on displaying this on the client side to strip_tags if needed.

In example when saving a HTML formatted text you can use simply the htmlspecialchars method

$description = htmlspecialchars($_POST['description']);

Than you can be sure everything’s in the database, but it’s not actually HTML. Thus you don’t have any tags at all in the database field.

When you show this in the client side and you’d like to strip some tags, i.e. to keep only the <a> tag you can do this:

echo strip_tags(htmlspecialchars_decode($description), '<a>');

That’s the most simple way to keep everything as the original source. By me it’s better to keep whatever HTML markup there is on the input.

jQuery tips – storing data

Storing data?

I was reading an article where the author says it is not a good practice to store data in the DOM. Indeed this is a bad practice and you should avoid it. After that he gives an example with using the DOM with the ALT attribute:

$('selector').attr('alt', 'data being stored');
// later the data can be retrieved using:
$('selector').attr('alt');

and after that the more clean:

$('selector').data('paramtername', 'data being stored');
// then later getting the data with
$('selector').data('paramtername');

OK, is more clean. But however it is bad practice to use such a “heavy” construction to store local data. It is obvious you can prefer to store it in a local variable. Thus you avoid the extra performance.