PHP singleton class which extends the mysqli class

0

<?php
/**
*  Database class to implement singleton pattern on top of mysqli
*/
class Database extends mysqli {

/**
*  @var object Singleton instance
*/
private static $instance = null;

// DB connection parameters:
private $dbHost = ‘localhost’;
private $dbUser = ‘xxxxxx’;
private $dbPwd = ‘yyyyyy’;
private $dbName = ‘zzzzzzzz’;

/**
*  Constructor
*  @return void
*/
private function __construct() {

@parent::__construct( $this->dbHost, $this->dbUser, $this->dbPwd, $this->dbName);

if(mysqli_connect_errno()) {

throw new Exception(mysqli_connect_error(), mysqli_connect_errno());

}

}

/**
*  Do the singleton thing
*  @return object Database
*/
public function getInstance() {

if(self::$instance === null) {

$c = __CLASS__;
self::$instance = new $c;

}

return self::$instance;

}

public function __clone() {

throw new Exception(“Cannot clone “.__CLASS__.” class”);

}

}

Referenced in:  http://www.webdeveloper.com/forum/showthread.php?t=176905

PHP, MySQL e File Encoding

0

Após a recente instalação de um novo IDE para desenvolvimento web, uma das principais preocupações que tive foi a de me certificar que esse editor grava os ficheiros no tipo de encoding certo, uma vez que é o bastante para dar algumas dores de cabeça no que toca à correcta manipulação de strings.

Na realidade este problema começa um pouco atrás. Por defeito o MySQL utiliza o encoding ISO-8859-1 (também conhecido como Latin 1) e a maioria de nós, se actualmente não usamos, pelo menos começámos por usar sistemas Windows para desenvolver o nosso código PHP, onde o encoding utilizador por defeito é também o ISO-8859-1 ou melhor uma versão específica de ISO-8859-1 também conhecida por Windows Latin 1 ou Windows-1252.

Um dos problemas com que me deparei frequentemente (mais desde que mudei para Mac) foi o facto de que em Mac o encoding por defeito é normalmente UTF-8, o que transforma num pesadelo a edição de ficheiros que foram gravados em ISO-8859-1.

Pesadelo apenas se (como me aconteceu a mim) estiver-mos distraídos em relação a este assunto, e porque por vezes os editores optam por gravar os ficheiros no encoding que têm definido por defeito, ao invés de detectarem o encoding que o ficheiro que acabaram de abrir, traz.

Assim, muitas vezes é tarde demais, pois já editámos uma série de ficheiros, acabando por corromper muitas das strings lá usadas, especialmente se tiverem caracteres especiais (normalmente as nossas mensagens de feedback da aplicação), pois acabámos por gravar os ficheiros que originalmente vinham em ISO-8859-1, agora em UTF-8.

Este tipo de situação costuma revelar-se quando começamos a ter erros quer seja nas ditas mensagens de feedback quer no caso de strings enviadas a partir de formulários via POST, tais como frequentes dificuldades em processar essas strings de forma correcta e inseri-las de forma correcta na base de dados (MySQL – ISO-8859-1).

Assim pretendo aqui sobretudo chamar a atenção para este problema, mostrar como determinar o encoding de um ficheiro e apresentar a forma de nos certficar-mos que estamos a gravar ficheiros no encoding certo, definindo o encoding por defeito nos nosso IDEs preferidos.

Abaixo seguem instruções sobre como determinar o encoding de um ficheiro em 4 IDEs/editores de ficheiros.

A minha recomendação é para que leitor altere o encoding / character set quer de MySQL quer do editor que usa, para utf8 e em MySQL escolha ainda a collation para utf8_unicode_ci . Assim não terá problemas na edição de ficheiros na maioria dos editores, passará a utilizar um sistema de caracteres mais completo e eficaz (UTF-8) suportado pela maioria das aplicações e estando mesmo definido por defeito na maioria destas.

Determinar o Encoding de um ficheiro

No caso de estar a usar TextMate, tem uma forma rápida para visualizar o encoding do ficheiro, indo ao menu File -> Re-Open With Encoding, como pode visualizar na seguinte imagem:

TextMate - Re-Open With Encoding

TextMate - Re-Open With Encoding

Por vezes queremos simplesmente saber qual é o encoding de um determinado ficheiro. Em pesquisas recentes sobre o tema descobri este artigo muito interessante.

Definir o Encoding por defeito nos nossos IDEs preferidos (Mac)

TextMate
Menu TextMate -> Preferences -> Advanced -> Saving
TextMate

Dreamweaver
Menu Dreamweaver -> Preferences -> New Document Dreamweaver

Nota: No caso do Dreamweaver está também disponível o encoding Western (Windows Latin 1). Nos testes que realizei não consegui detectar incompatibilidades entre a escrita numa versão e na outra, ao abrir os ficheiros no Zend Studio e no Aptana Studio que me pareceram as aplicações que mais acusavam a abertura de ficheiros com encoding diferente do definido por defeito.


Zend Studio
Menu Zend Studio ->
Preferences -> Desktop -> Appearance
Zend Studio
Nota: No Zend Studio defini o encoding como sendo windows-1252, uma vez que verifiquei incompatibilidades escolhendo iso-8859-1 ao ler ficheiros escritos por algumas das outras aplicações cujos encodings estão definidos para ISO-8859-1 ou Windows Latin 1.

Aptana Studio
Menu Aptana Studio -> Preferences -> Workspace -> Text file encoding
Aptana Studio

Go to Top