Обновить
19
0

Пользователь

Отправить сообщение
Деструктор – это специальный метод класса с именем __destruct(), который будет гарантированно вызван при потере последней ссылки на объект в программе.

переименуйте
function __constuct($a) {
в
function __construct($a) {
и оно чудесным образом будет поймано)
эксепшн возник еще ДО выполнения конструктора, и логично что пхп прервал его выполнение и вызвал деструктор.
а что ДОЛЖНО БЫЛО произойти? чтоб выполнение продолжилось и эксепшн был проигнорирован? тогда бы вы еще больше начали кричать о нелогичности поведения )))
вы выковыряли несколько известных проблем php и на основании этого делаете далекоидущие выводы.
я с вами несоглашусь.
В php все достаточно логично и предсказуемо, просто есть свои особенности — которые нужно знать. но это касается любого языка.
надо нам всем вступить в РАО и получать свои законные проценты
php без регекспов
$p1=$p2=false;
while (($p2 = strpos($str,'}'))!==false && ($p1 = strrpos(substr($str,0,$p2),'{'))!==false) {
    $a = explode('|', substr($str, $p1+1,$p2-$p1-1));
    $str = substr_replace($str, $a[rand(0,count($a)-1)], $p1, $p2+1-$p1);
}
а есть ли менее многословный способ описания формы? типа:
$form->add( new Zend_Form_Element_Text('username', 'Username', 'required minlen:3 regex:^[a-zA-Z0-9]+' ) );
передать то хакер сможет, а вот валидатор как раз при проверке и заругается что пришло слишком длинное поле, и данные в БД не попадут…

>При этом если вы ее не будете фильтровать в обработчике, то рискуете получить много проблем.
так а Zend_Form это и есть обработчик в данном случае, валидация то отрабатывает на стороне сервера
начало хорошее.
а вот дальше, когда надо изменить схему роутинга, использовать разные классы spring-овских контроллеров, добавить больше логики приложения и отображения, подключить БД…
вот тут вопросов гораздо больше )
думаю начинающим это очень поможет.
бред
дальше прейдете к постам из одних букв?
и гордо назовете это пикоблоггинг…
лучче я создам коллекцию типа «Сумма прописью на 120 языках программирования»
спасибо, учту на будущее)
я у себя работал с объектом Money, и там были еще некоторые специфичные методы.
а в этом виде — вы правы, логичнее сделать статик
вы ведь прекрасно знаете зачем придумали регулярные выражения…
чтобы описывать легко СЛОЖНЫЕ шаблоны.
проверить что строка начинается со слова «cached_» — это не сложный шаблон, и логично использовать обычные строковые функции.

быть логичным или нет — каждый выбирает сам)
$parts = explode('_', $name);
if (sizeof($parts)==2 && 'cached'==$parts[0] && method_exists($this,$parts[1]) ) {

)
$parts = explode('_', $name);
if ('cached'==$parts[0] && method_exists($this,$parts[1]) ) {

?
а кеш получается вечный? Где задается время жизни кеша?
Ведь для разных моделей нужно будет разное время обновления информации
причем здесь понт.
jinxal правильно написал. при работе с большими объемами данных для быстрого и эффективного решения задач просто необходимо знать и применять все возможности и функции используемой СУБД. средний запрос там занимает обычно больше 20-30 строк и это нормально. потому что идет работа с десятками связанных таблиц и гора условий и фильтров.
если говорить о HAVING — его использование(при необходимости) помогает строить запрос с минимумом кода, не занимаясь перегрузкой запроса лишними подзапросами, так как они только читаемость ухудшают.
в целом код понравился
но:
1) нет ничего готового для автоматизации построения и работы с формами
2) зачемто в каждом методе контроллера прописано $data['baseurl'] = Doo::conf()->APP_URL; почему бы не прописать это один раз у родителя, а при необходимости уже переопределять
3) используются компилируемые шаблоны, тоесть всегда есть дополнительные проверки на валидность файла-компиляции, следовательно в этом месте он проигрывает фреймворкам изначально построенным на нативных php шаблонах.

ну и еще есть места спорные… но это уже наверное IMHO
class UsersController extends AppController {
 var $name = 'Users';
 function beforeFilter() {
  //...
 }
}

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность