Постове 1 - 5 от 24 в категория PHP

Наскоро се наложи да поработя по един доста стар PHP проект, по който не бях работил от години. И там видях нещо, което ведна опреличих като code smell (Всъщност видях много такива неща, но само на това ще обърна внимание).

$cart = CartManager::getCurrentCart();
$cart->setClientInfo('atype',    $user['account_type']);
$cart->setClientInfo('fname',    $user['fname']);
$cart->setClientInfo('lname',    $user['lname']);
$cart->setClientInfo('street',   $user['street']);
$cart->setClientInfo('postnum',  $user['postcode']);
$cart->setClientInfo('epost',    $user['mail']);
$cart->setClientInfo('city',     $user['city']);
$cart->setClientInfo('company',  $user['company']);
$cart->setClientInfo('orgnum',   $user['orgnum']);
$cart->setClientInfo('phone',    $user['phone']);
$cart->setClientInfo('country',  $user['country']);

Което ако идвате от  Java света може и да ви изглежда нормално, но мен ме дразни.

На първо време направих метода setClientInfo да връща $this зада може да използвам прост method chaining. И кода стана така:

CartManager::getCurrentCart()
    ->setClientInfo('atype',    $user['account_type'])
    ->setClientInfo('fname',    $user['fname'])
    ->setClientInfo('lname',    $user['lname'])
    ->setClientInfo('street',   $user['street'])
    ->setClientInfo('postnum',  $user['postcode'])
    ->setClientInfo('epost',    $user['mail'])
    ->setClientInfo('city',     $user['city'])
    ->setClientInfo('company',  $user['company'])
    ->setClientInfo('orgnum',   $user['orgnum'])
    ->setClientInfo('phone',    $user['phone'])
    ->setClientInfo('country',  $user['country']);

Малко по-добре, но пак ми изглеждаше не естествено. Затова просто добавих възможността да може да се предава масив като аргумент. И така стана доста добре:

CartManager::getCurrentCart()->setClientInfo(array(
    'atype',    => $user['account_type'],
    'fname',    => $user['fname'],
    'lname',    => $user['lname'],
    'street',   => $user['street'],
    'postnum',  => $user['postcode'],
    'epost',    => $user['mail'],
    'city',     => $user['city'],
    'company',  => $user['company'],
    'orgnum',   => $user['orgnum'],
    'phone',    => $user['phone'],
    'country',  => $user['country']
));

За нещастие в този проект, нямаше как да направя кода стане още по-чист, без да се налага пренаписване на голяма част от проекта:

CartManager::getCurrentCart()->setClient($user);

Като цяло тази седмица мина под знака на Rails 3, на който излезе бета версия.

Понеделник 01.02.2010

SafeBuffers and Rails 3.0 – в Rails 3 има вградена xss защита, и Yehuda Katz обяснява последните промени по тази система и защо са се наложили.

8 Chrome Extensions For Web Developers – Напоследък Firefox започва да се държи все по зле и леко да изостава от браузъри като Chrome и Safari. И докато в Safari все още ми липсват 2-3 малки неща, то Chrome може в много скоро време да стане предпочитания ми браузър.

Вторник 02.02.2010

Google Apps Drop IE6 Support – Е време беше. След скорошната атака срещу Google извършена с IE6, Google решиха да дръпнат шалтера на това нещо. В Германия вече го забраниха, така че още малко живот му остава. И усещам как скоро ще се вдигнем мерника към IE7.

One-click Minifier Gadget (OMG) – initial checkin – Българското Yahoo! гуру Стоян Стефанов пусна много полезен инструмент за минимизиране. Кода го има в github. ( Статията е от 31 Януари, но чак във Вторник я видях )

Basic Cappuccino Tutorial - Добър на урок за Cappuccino. Което е добре защото, един от най-големите проблеми на Cappuccino, според мен, е липсата на добра документация и уроци.

How Internet Explorer 8 document mode affects JavaScript – Оказва се че в IE8 имало доста промени по самия JavaScript.  Nicholas C. Zakas разяснява голяма част от тях.

The touch action – В България до голяма степен сме 1-2 години назад в IT отношение. Така че е доста лесно да се предскаже че в следващите години и у нас както навън ще навлязат все повече “умни телефони” и особено такива с touch screen (то май всички са такива). Затова е важно да се знае как може да се работи със touch събитието. В Quirksmode имаше цяла серия за тези събития през седмицата.

an HTML5 offline image editor and uploader application – Наскоро започнах да правя първите залежи за новата ни cms система ControlDepo 4. И мисля в нея да вградя нещото такова в една или друга степен.

HipHop for PHP: Move Fast – Това беше новината на деня. Facebook пуснаха HipHop, което компилира (или по-точно трансформира) PHP кода до оптимизиран C++ код, който след това се компилира с g++. От което е излишно да казвам какви са ползите като скорост и CPU. За повече подробности самия пост и това видео.

Явно вторник е бил много “натоварен” ден.

Сряда 03.02.2010

YUI Theater — Douglas Crockford: “Crockford on JavaScript — Volume 1: The Early Years” – Когато Douglas Crockford, говори и Чък Норис слуша . В случая говори за история на JavaScript и програмните езици като цяло. Първите 10-15 са необичайно скучни. Главно защото говори за първите компютри и темата е повече насочена към хардуера от колкото към софтуера. Но после нещата се оправят.

Stop Being an Idiot – Колкото пъти сме се оправдавали с това че потребителите са “идиоти”, е време е да спрем.

Четвъртък 04.02.2010

The Rails Module (in Rails 3) -  Rails 3 идва с доста променен Rails module, в който има доста полезни методи. От тази статия може да се научат доста странични неща за Rails като цяло.

Също интересен факт е и че Basecamp стана на 6 години. Като един ден преди това стори и Facebook.  Което като се замисли човек е много странно съвпадение. Защото никои не може да се отрече че и двата продукта косвено или директно промениха мрежата.

Петък 05.02.2010

SD Ruby – Episode 077: Building Your Own Hosting Environment – това стои във readera ми от доста време, но чак в Петък имах време и повод да го гледам. Доста добро ми се стори и ако някои мисли сам да си хоста Rails приложенията ( и даже каквото и да е друго сам да си хоства) е много добра начална точка.

Преч седмица най-сетне намерих една от най-запомнящите реклами, който съм гледал (незнайно защо бях останал с впечатлението  че е за Ferrari, а тя била за Porsche ):

Доста често ми се е налагало да пиша нещо такова

if ($something){
  $a = 1;
  $b = 'a';
} else {
  $a = '2'
  $b = 'c';
}

За което обикновено ми трябват 5-6 и повече реда, което ме дразни. Но вече на 2-3 места ползвам следния синтаксис:

list($a, $b) = $something ? array(1, 'a') : array(2, 'b');

Може и да не е по-бързо и за някои хора да е “леко” не четимо, но аз си го харесвам. От една страна веднага се вижда, че от операцията $a, $b излизат със нови стойности. Две, вижда се кои са тези стойности. Три доста по-кратко и cбито е.

По принцип list e доста подценявана функционалност в php и доста често грешно използвана. Преди много време я използвах за router в моите проекти и се държеше много добре:

list($controller, $action, $id) = explode('/', $url);

Друг доста малко известен факт, е че всъщност list може да се използва и с ArrayAccess обекти. Още малко трикове има тук.

Надявам сe някои да намери това за полезно.

От началото на месеца, голяма част от работата ми включваше почти изцяло пренаписване на повечето unit тестове на основните ми PHP библиотеки. Основната причина за това беше че повечето тестове бяха на повече от година, като през този период само съм добавял код за нови методи. И през това време тестове станах доста големи и тежки затова се наложи това малко “освежаване”

Основното нещо което исках да тествам по-добре този път бяха ‘protected’ методите на голяма част от класовете. Примерно основния ми Controller клас има само 2 публични метода и всичко друго е protected. Защото идеята на този клас  е да се ползва “отвътре”.

Преди какво правех? Просто си дефинирах един помощен decorator клас през който виках protected методите. Обаче това винаги ми се е струвало доста “мръсно” решение.  Затова реших потърся дали някой не се е сетил нещо по-добро от мен. И затова потърсих -  “php testing protected methods“. И от там намерих този пост – Testing protected Methods in Unit Tests от Frontalaufprall. Което на този етап ми се вижда перфектното решение. И така с много малко промени се получи този код с който тестването на protected методи става изключително лесно:

function getProtectedMethodsProxy($className){
	$proxyClassName = $className . 'PrivateMethodsProxy';

	if (!class_exists($proxyClassName, false)){
		eval('
			class ' . $proxyClassName . ' extends ' . $className . ' {
				public function __call($method, $arguments){
					$method = str_replace("_", "", $method);

					if (!method_exists($this, $method)){
						return parent::__call($method, $arguments);
					}

					return call_user_func_array(array($this, $method),  $arguments);
				}
			}
		');
	}

	if (func_num_args() == 1){
		return new $proxyClassName();
	}

	$class = new ReflectionClass($proxyClassName);
	return $class->newInstanceArgs(array_slice(func_get_args(), 1));
}

Начин на ползване:

$class = getProtectedMethodsProxy('Controller_Action');
$class->_redirect('http://next.pixeldepo.com');
// и вариант с параметри в конструктора
$class = getProtectedMethodsProxy('SomeClass', 1, 2, 3); // new SomeClass(1, 2, 3);
$class->_someVeryProtectedMethod('test');

Все пак eval не винаги е толкова лош

Днес почетох този пост във veselin.bg, пробвах в един коментар да събера най-основните “стандарти” по който пиша PHP код. Обаче коментарът доста набъбна и реших да го направя като пост.

В PHP за разлика от повечето (да не кажа всички) програмни езици няма точно установен стандарт структориране и писане на кода. Донякъде това се дължи на самата история на езика и това, че написан на PHP3 код може да върви дори и на PHP6. От друга страна PHP се води най-лесния за учене език, точно защото каквото и да напишеш все ще ти излезе резултат. Тази страна на PHP колкото и позитиви да има, като цяло според мен е грешка на самия език и придава малко статус “аматьори” на PHP програмистите му.

В послените години започват да се оформя що годе няколко стандарта на писане, но като цяло поне според мен докато PHP5.3 – PHP6 не започне да се ползва масово нещата няма много да се променят.

Основния начин да се започне да се работи по стандарт е да се работи с някой PHP framework, защото всички те си имат свой достатъчно добре дефинирани “стандарти” и самия framework ви кара да пишете по неговия стандарт за да изглежда кода ви добре. И тъй като никой PHP framework неможа да ме спечели, аз си направих мой. Който вече от 1 година се ползва във всички проекти които правя за Pixeldepo ( и които са на PHP разбира се ) и съм страшно доволен от това как работи. В неговите coding conventions съм “взаимствал” доста идеи, главно от  Zend Framework и CodeIgniter.

Именуване на променливи и функции и методи.

Променливите и методите ми са със CamelCase, фунцкиите са с подчертавки. Което е малко старанно за повечето хора, но поне според мен има известна логика ( иначе нямаше да пиша по този начин де ). Самия PHP, като език ако се погледне дългия списък със фунцкии ще се види че основно те са с почертаване и когато се ползва фунция инстиктивно знам че е такава. Докато класовете  (повечето от тях) използват CamelCase стандарт подобно на Java и когато се работи с класове изглеждат някак естествено. По принцип използвам много малко фунции и обикновенно те са просто wrapper/shortcut към някой клас.

Не използвам долни черти за разделянето на private променливи фунции. Пример за променлива / фунция / метод

$name = '';
$totalPrice = "";

function url_for($params){ /* ... */ }

class Foo {
public function isValid(){ /* ... */ }
}

Именуване на класове

Начина на именуване на класовете в Zend Framework, ми допадна най-много, от висички останали които бях гледал в различни PHP-та. Общо взето идеята е в името на класа да се съдърже “namespece” му. И същевременно класа да се намира в директория, пътя на която отговаря на това име. Примери:

// намира се в ActiveRecord/Plugin/Attachable.php
class ActiveRecord_Plugin_Attachable {}

// намира се в Model/Validation/Errors.php
class Model_Validation_Errors {}

// намира се в Tool/Script/Genererate/Applition.php
class Tool_Script_Generate_Application {}

Това е много ползено за _autoload на класове и доста ще улесни бъдеща интеграцията на PHP5.3 – PHP6 namespace-овете. Само да вметна, че доста хора не го знаеха за autoload, най-добре да се ползва spl_autoload.

Като тук проблема с абстрактните класове го решавам, като ако класа е абстрактен се кръщава Base. Тъй като Zend имаха проблем със класове като Zend_Controller_Plugin_Abstract, който в щеше да стане просто клас Abstract от PHP6 и щеше да е в namespace Zend\Controller\Plugin.  А Abstract е ключова дума и неможе да има клас който се казва така. При мен такъв клас се казва просто Base.

С подобна структура на класовете е много удобна и въпреки че много хора казват, че с такива имена писането става трудно.  Има доста техники с който се избягва писането на целите имена. Като пример ще дам моята script функция която изпълнява script  класове.

script('generate:model'); // Прави клас Tool_Script_Generate_Model го изпълнява
script('db:dump:data'); // Прави клас Tool_Script_Db_Dump_Data и го изпълнява

// като могат много лесно се добавят плъгини:
script('your:custom:script'); // Това е клас Tool_Script_Your_Custom_Plugin

В заключение…

Основната идея на стандартите е не само вие да може да си разчетете кода след 1-2 месеца, но и други хора да могат да работят над него. Също така е важно и да не ви е толкова срам от него след време, което рядко ще стане, но е важно да се опита. Kода да изглежда естествено в средата в която работите било то PHP / Ruby / Java и т.н. За PHP това не е лесно, защото самия език не изглежда естествено понякога.

За стандарти за писане лично аз препоръчвам тези на Zend Framework и донякъде тези на CodeIgniter. Ако пишете изцяло собствени неща, ако не пишете по стандартие на системата в която сте.

To be continue…

Това е тема с продължение, която най-вероятно утре ще продължа

Тъй като исках да напиша още за коментари / гетъри и сетъри / php файлове плюс няколко други неща, ще има още един пост.

Ако имате някви коментари и / или съвети може да ги споделите. Също така ще се радвам и да чуя и по какви стандарти пишете и вие.