Деструктор – это специальный метод класса с именем __destruct(), который будет гарантированно вызван при потере последней ссылки на объект в программе.
эксепшн возник еще ДО выполнения конструктора, и логично что пхп прервал его выполнение и вызвал деструктор.
а что ДОЛЖНО БЫЛО произойти? чтоб выполнение продолжилось и эксепшн был проигнорирован? тогда бы вы еще больше начали кричать о нелогичности поведения )))
вы выковыряли несколько известных проблем php и на основании этого делаете далекоидущие выводы.
я с вами несоглашусь.
В php все достаточно логично и предсказуемо, просто есть свои особенности — которые нужно знать. но это касается любого языка.
передать то хакер сможет, а вот валидатор как раз при проверке и заругается что пришло слишком длинное поле, и данные в БД не попадут…
>При этом если вы ее не будете фильтровать в обработчике, то рискуете получить много проблем.
так а Zend_Form это и есть обработчик в данном случае, валидация то отрабатывает на стороне сервера
начало хорошее.
а вот дальше, когда надо изменить схему роутинга, использовать разные классы spring-овских контроллеров, добавить больше логики приложения и отображения, подключить БД…
вот тут вопросов гораздо больше )
думаю начинающим это очень поможет.
вы ведь прекрасно знаете зачем придумали регулярные выражения…
чтобы описывать легко СЛОЖНЫЕ шаблоны.
проверить что строка начинается со слова «cached_» — это не сложный шаблон, и логично использовать обычные строковые функции.
причем здесь понт.
jinxal правильно написал. при работе с большими объемами данных для быстрого и эффективного решения задач просто необходимо знать и применять все возможности и функции используемой СУБД. средний запрос там занимает обычно больше 20-30 строк и это нормально. потому что идет работа с десятками связанных таблиц и гора условий и фильтров.
если говорить о HAVING — его использование(при необходимости) помогает строить запрос с минимумом кода, не занимаясь перегрузкой запроса лишними подзапросами, так как они только читаемость ухудшают.
в целом код понравился
но:
1) нет ничего готового для автоматизации построения и работы с формами
2) зачемто в каждом методе контроллера прописано $data['baseurl'] = Doo::conf()->APP_URL; почему бы не прописать это один раз у родителя, а при необходимости уже переопределять
3) используются компилируемые шаблоны, тоесть всегда есть дополнительные проверки на валидность файла-компиляции, следовательно в этом месте он проигрывает фреймворкам изначально построенным на нативных php шаблонах.
ну и еще есть места спорные… но это уже наверное IMHO
function __constuct($a) {
в
function __construct($a) {
и оно чудесным образом будет поймано)
а что ДОЛЖНО БЫЛО произойти? чтоб выполнение продолжилось и эксепшн был проигнорирован? тогда бы вы еще больше начали кричать о нелогичности поведения )))
я с вами несоглашусь.
В 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-овских контроллеров, добавить больше логики приложения и отображения, подключить БД…
вот тут вопросов гораздо больше )
думаю начинающим это очень поможет.
дальше прейдете к постам из одних букв?
и гордо назовете это пикоблоггинг…
а в этом виде — вы правы, логичнее сделать статик
чтобы описывать легко СЛОЖНЫЕ шаблоны.
проверить что строка начинается со слова «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() { //... } }