1. Без автокомплита чужому человеку будет очень тяжко разбираться в вашем коде
2. Без кодестайла -//-
3. Без PHPDoc -//-
Даже отбросив любовь к ООП, то, если честно, не увидел ничего привлекательного в подобном вызове: Code::E('Security/CAPTCHA', 'Generate', array('Ticket'=>Client::$Ticket));
Неужели так хуже?: \Security\Captcha\Generate(Client::$Ticket);
И да, любовь к статическим классам надо пресекать, подумайте о тестировании…
Надо было страничку обновить :(
Насчет же querySelectorAll — то лучше бить запрос на куски, если есть сомнения, что querySelectorAll его не прохавает, к примеру при использовании кастомных фильтров.
// Take a shortcut and set the context if the root selector is an ID
// (but not if it'll be faster if the inner selector is an ID)
if ( !seed && parts.length > 1 && context.nodeType === 9 && !contextXML &&
Expr.match.ID.test(parts[0]) && !Expr.match.ID.test(parts[parts.length - 1]) ) {
var ret = Sizzle.find( parts.shift(), context, contextXML );
context = ret.expr ? Sizzle.filter( ret.expr, ret.set )[0] : ret.set[0];
}
Если ищем в рамках контекста Document, и первым идет #id (и не идет при этом последним), то в качестве контекста таки будет использоваться элемент #id
Посмотрел в исходниках, проверка на id железная quickExpr = /^[^<]*(<[\w\W]+>)[^>]*$|^#([\w-]+)$/ (html или id), так что оптимизации селекторов с #id не нашел.
1.2 Пункт не верен, в данном примере $('#id input') будет работать медленнее чем просто $('input'), для ускорения необходимо указывать контекст, для этого и служит второй параметр: $('input', $('#id')[0]), или $('#id').find('input');
1.3 Тоже неверное рассуждение, будут найдено множество .button потом к нему применен фильтр по тэгу, сам же селектор вида tag.class будет работать быстрее только относительно браузеров у которых нет поддержки функции getElementsByClassName (IE <= 7 кажись)
2. jQuery не кеширует селекторы, для поиска используется движок Sizzle — в нем нет механизма кеширования.
Одна из моих прямых обязанностей — оценка проектов заходящих в отдел, так вот точность оценки зависит от времени потраченном на изучение и анализ документации.
Если спросите о моих промахах в оценке, то список будет не так уж и велик:
— не хватило времени на анализ документации — когда оценку нужно сделать на вчера, а документации пару сотен страниц, это просто мозг ломает (львиная доля ошибок)
— про… л сноску на какую-то НЁХ, т.е. моя невнимательность (отмазок конечно можно придумать с пачку)
— недооценил риски — фигли, как оценить время на изучение и изменение чужого «индуского» кода (это же относится к 3-rd party библиотекам)?
— переоценил ресурсы которые будут делать проект, меряешь ± по себе, а проект отдают зашедшему с испытательного
Обрабатывать бизнес логику с помощью исключений считаю вполне приемлемым, получается очень читаемый код (т.к. ветвления убрали), только для этого нужно создать отдельную иерархию исключений.
Немного абстрактный пример кода:
try {
//
// редактирование профиля
//
} catch (AuthException $e) {
// надо быть авторизированным
} catch (AccessException $e) {
// надо иметь доступ
} catch (ValidationException $e) {
// надо правильно заполнять форму
} catch (ApplicationException $e) {
// таки shit happens
}
Microsoft Silverlight may not be supported on this browser.
This Web browser or operating system may not be compatible with Silverlight. Please review the system requirements and, if you wish to proceed, choose the link for your operating system.
На выходных читал книгу на нуке — экран не напрягал, но создалось впечатление, что экран не на своем месте и занимает место, т.к. черный прямоугольник на светлом девайсе привлекает внимание…
2. Без кодестайла -//-
3. Без PHPDoc -//-
Даже отбросив любовь к ООП, то, если честно, не увидел ничего привлекательного в подобном вызове:
Code::E('Security/CAPTCHA', 'Generate', array('Ticket'=>Client::$Ticket));
Неужели так хуже?:
\Security\Captcha\Generate(Client::$Ticket);
И да, любовь к статическим классам надо пресекать, подумайте о тестировании…
Насчет же querySelectorAll — то лучше бить запрос на куски, если есть сомнения, что querySelectorAll его не прохавает, к примеру при использовании кастомных фильтров.
// Take a shortcut and set the context if the root selector is an ID // (but not if it'll be faster if the inner selector is an ID) if ( !seed && parts.length > 1 && context.nodeType === 9 && !contextXML && Expr.match.ID.test(parts[0]) && !Expr.match.ID.test(parts[parts.length - 1]) ) { var ret = Sizzle.find( parts.shift(), context, contextXML ); context = ret.expr ? Sizzle.filter( ret.expr, ret.set )[0] : ret.set[0]; }Если ищем в рамках контекста Document, и первым идет #id (и не идет при этом последним), то в качестве контекста таки будет использоваться элемент #id
1.3 Тоже неверное рассуждение, будут найдено множество .button потом к нему применен фильтр по тэгу, сам же селектор вида tag.class будет работать быстрее только относительно браузеров у которых нет поддержки функции getElementsByClassName (IE <= 7 кажись)
2. jQuery не кеширует селекторы, для поиска используется движок Sizzle — в нем нет механизма кеширования.
Еще хороший пример:
$('#selector').click(function(){ $(this).find('.class')....; });Лучше
$('#selector').click(function(){ $('.class', this)....; });4. Делегирование описано без упоминания метода delegate?
XSLT конечно всем хорошо, только гибкости в нем маловато.
Zend_View отличненько так написан в ZF кстати…
Пожалуй исправьте:
$front = $this->getBootstrap()->getApplication()->getBootstrap()->getResource('frontcontroller');Если спросите о моих промахах в оценке, то список будет не так уж и велик:
— не хватило времени на анализ документации — когда оценку нужно сделать на вчера, а документации пару сотен страниц, это просто мозг ломает (львиная доля ошибок)
— про… л сноску на какую-то НЁХ, т.е. моя невнимательность (отмазок конечно можно придумать с пачку)
— недооценил риски — фигли, как оценить время на изучение и изменение чужого «индуского» кода (это же относится к 3-rd party библиотекам)?
— переоценил ресурсы которые будут делать проект, меряешь ± по себе, а проект отдают зашедшему с испытательного
Немного абстрактный пример кода:
try {
//
// редактирование профиля
//
} catch (AuthException $e) {
// надо быть авторизированным
} catch (AccessException $e) {
// надо иметь доступ
} catch (ValidationException $e) {
// надо правильно заполнять форму
} catch (ApplicationException $e) {
// таки shit happens
}
This Web browser or operating system may not be compatible with Silverlight. Please review the system requirements and, if you wish to proceed, choose the link for your operating system.
Если что-то из этого не делается — проект будет топтаться на том же месте.