Комментарии 135
по мне так ZF неоправданно жрет много ресурсов проца
да? ну ладно. удалю его со всех проектов. да лучше вообще их на Перле перепишу, вот это скорость, вот это мощь!
о вкусах не спорят, но признаюсь перл мне по душе =)
не спорю, у него есть плюсы :)
давайте эта ветка будет единственной и последней веткой, в которой будет обсуждаться сам вопрос использования ZF. я пишу для тех, кто уже выбрал его ;) спасибо за ваше мнение
давайте эта ветка будет единственной и последней веткой, в которой будет обсуждаться сам вопрос использования ZF. я пишу для тех, кто уже выбрал его ;) спасибо за ваше мнение
не знаешь, как вручную установить контроллер и акцию?
я не могу использовать ссылки вида /module/controller/action/parameters
у меня уже готовый сайт, и моё приложение выглядит как example.com/somepath/index.php?id=xxx
но я могу добавлять любые get-параметры, и таким образом мог бы передавать controller и action:
example.com/somepath/index.php?id=xxx&controller=somecontroller&action=someaction
то, что мне нужно, это устанавливать в bootstrap контроллер и акцию вручную, из get-параметров, а потом уже запускать своё ZF-приложение
пытаюсь разобраться с route, но пока безрезультатно
я не могу использовать ссылки вида /module/controller/action/parameters
у меня уже готовый сайт, и моё приложение выглядит как example.com/somepath/index.php?id=xxx
но я могу добавлять любые get-параметры, и таким образом мог бы передавать controller и action:
example.com/somepath/index.php?id=xxx&controller=somecontroller&action=someaction
то, что мне нужно, это устанавливать в bootstrap контроллер и акцию вручную, из get-параметров, а потом уже запускать своё ZF-приложение
пытаюсь разобраться с route, но пока безрезультатно
надо не со стандартным роутером колдовать, а свой писать. вам в помощь framework.zend.com/manual/en/zend.controller.request.html обьект запроса и дальше мануал
я эту страницу уже два дня читаю.
сделал проще:
сейчас времени нет разбираться, потом ещё почитаю
сделал проще:
function main($content, $conf)
{
...
$front = Zend_Controller_Front::getInstance()
->setModuleControllerDirectoryName('controllers')
->setControllerDirectory('mvc/application/controllers')
->setDefaultControllerName('index');
$front->dispatch();
...
}
***
public function init()
{
$action = $this->_request->getParam('act');
if (method_exists($this, $action.'Action')){
$this->_forward($action);
}else{
$this->_forward('index');
}
}
сейчас времени нет разбираться, потом ещё почитаю
Давайте перепишем ZF на ассемблере ))
Не, ну на плюсах можно :) PHP ведь на плюсах :)
Как раз то ли здесь, то ли на PHP форуме каком-то были подробные инструкции о том, как писать свои расширения к PHP на C++.
Под высоко нагруженные проекты или просто часто используемые вещи можно и написать…
Как раз то ли здесь, то ли на PHP форуме каком-то были подробные инструкции о том, как писать свои расширения к PHP на C++.
Под высоко нагруженные проекты или просто часто используемые вещи можно и написать…
А можно как-нибудь поподробнее? Мне как раз нужно написать своё расширение для PHP!
phpclub.ru/talk/forumdisplay.php?s=&forumid=44
Вроде вот это.
Вроде вот это.
да? а в курсе сколько ресов жрёт обычный include или require? и учитывая портовость зенда — ну-ка, прикинь, что будет лучше — своя маленькая гибкая МВЦ или «три кита в ещё одном гипербольшом ките»?
я серьезно абсолютно. каждому — своё. мне нравится ZF и я готов пару минут поколдовать с eAccelerator-ом и другими штуками ради веселого и простого кодинга. вам не нравится? окей, напишите свой фреймворк, придумайте что-нибудь еще — но не навязывайте мне своего мнения! пожалуйста
а если обьеденить все нужние файли в один;)?
проверено, що include[_once] забирает какую-то там мимлсекунду.
так зачем нужно тратить время на подгрузку всех необходимих файлов, если можно всю основную библиотеку класов собрать в один файл? при етом время ускоряется до 22-х раз… Статья Дмитрия Котерова: dklab.ru/chicken/nablas/49.html
проверено, що include[_once] забирает какую-то там мимлсекунду.
так зачем нужно тратить время на подгрузку всех необходимих файлов, если можно всю основную библиотеку класов собрать в один файл? при етом время ускоряется до 22-х раз… Статья Дмитрия Котерова: dklab.ru/chicken/nablas/49.html
А зачем нужна маленькая «МВЦ»? Для маленьких сайтов-визиток? При создании проекта покрупней эта «маленькая» обрастёт кучей… кода, и станет головной болью. Уж лучше Zend, где есть некоторая избыточность, но именно она обеспечивает хорошую гибкость и конфигурируемость MVC-инфраструктуры.
а «маленькая» не может быть гибкой и конфигурируемой?
А использовать акселераторы уже не модно? Затраты на include закешированного акселлератором скрипта — ноль миллисекунд.
Да, ZF перегружен кодом, это плата за 1) возможность взаимоменяемости компонентов (посмотрите например на код для работы с БД, ) 2) попытку сделать универсальный фреймворк.
Да и одни названия классов по 30 символов чего стоят… брр… проще надо.
Возвращаясь к DAL в ZF — нагородили кучу кода, и что? Даже нормальной работы с плейсхолдерами нет, то есть надо поверх всего этого еще совй код писать, получается в результате монстр.
Да и одни названия классов по 30 символов чего стоят… брр… проще надо.
Возвращаясь к DAL в ZF — нагородили кучу кода, и что? Даже нормальной работы с плейсхолдерами нет, то есть надо поверх всего этого еще совй код писать, получается в результате монстр.
А вы будете дома на 600 селероне размещать крупный проект? Да и как говорилось, кеширование спасает всю ситуацию.
НЛО прилетело и опубликовало эту надпись здесь
а может Вы его просто использовать не умеете?
не забанят…
* rouses.php [1]
Поправь плиз на routes.php
Поправь плиз на routes.php
"(часов за 6 легко делается без особого напряга набор авторизация+регистрация+посты+лента+древовидные комменты+чай+кофе+потанцуем"
не вижу смысла тратить на такую мелочь целых 6 часов.
не вижу смысла тратить на такую мелочь целых 6 часов.
да вообще, челябинские мужики делают сервер за минуту на перле
Сейчас еще любители джумлы припрутся.
сразу видно кто юзает зенд — тот отчаянно минусует ;)) хомячки
вот если кто-нибудь попробует написать свою МВЦ, только нормально продумывая каждый шаг, то тогда будет иметь право плюсовать или минусовать за зенд.
лично я попытался и написал свою МВЦ, которая поместилась дай бог в несколько килобайт.
Ну да там нету миллиона optional пакетов, зато есть гибкость и легкость построения, на которой остался настоящий принцип МВЦ, без лишнего мяса и миллиарда ненужных проверок.
давайте-ка вспомним сколько всего нужно чтобы сделать обычную форму в зенде. И это, вы скажете, «гибкая система»?
в общем я хотел лишь сказать, что «суровые» кодеры юзают сторонние фреймворки, а «свою крепость строить даже не пробовали»
вот если кто-нибудь попробует написать свою МВЦ, только нормально продумывая каждый шаг, то тогда будет иметь право плюсовать или минусовать за зенд.
лично я попытался и написал свою МВЦ, которая поместилась дай бог в несколько килобайт.
Ну да там нету миллиона optional пакетов, зато есть гибкость и легкость построения, на которой остался настоящий принцип МВЦ, без лишнего мяса и миллиарда ненужных проверок.
давайте-ка вспомним сколько всего нужно чтобы сделать обычную форму в зенде. И это, вы скажете, «гибкая система»?
в общем я хотел лишь сказать, что «суровые» кодеры юзают сторонние фреймворки, а «свою крепость строить даже не пробовали»
Согласен с тобой.
Свой фреймворк — вещь хорошая.
Но как-то совпало так, что я сейчас учу ZF и это статья именно о нем. Когда я пойму в чем соль ZF, что в нем хорошо, что плохо — напишу свой, мелки, но сочни фреймворк.
Свой фреймворк — вещь хорошая.
Но как-то совпало так, что я сейчас учу ZF и это статья именно о нем. Когда я пойму в чем соль ZF, что в нем хорошо, что плохо — напишу свой, мелки, но сочни фреймворк.
никто не запрещал использовать отдельние компоненти ZF в своих приложениях… они легко подключаются ж не создавая никаких трудностей)
Я собираюсь писать свой фреймворк для того, чтоб не зависеть ни от кого.
Плюс, во время написания своего фреймворка я подниму намного больше опыта, чем при использовании ZF-компонент в отдельном приложении.
А еще это будет большим плюсом при трудоустройстве куда угодно.
Плюс, во время написания своего фреймворка я подниму намного больше опыта, чем при использовании ZF-компонент в отдельном приложении.
А еще это будет большим плюсом при трудоустройстве куда угодно.
Нет, не будет. По крайней мере — не куда угодно.
Читая чужой код Вы получите гораздо больше опыта, чем если бы Вы сами придумали несколько реализаций одной задачи. Проверенно. Тем более код таких монстр-программеров.
P.S. Не читайте код вордпресса, во избежание взрыва мозга :-)
P.S. Не читайте код вордпресса, во избежание взрыва мозга :-)
Хехе :)
Но есть мнение, и не только мое, что теория без практики мертва. А чтение кода, без его написания — разве не теория? ;)
И да, придумывание своих реализаций задачи только развивает мозг, что вовсе неплохо, не так ли? :)
Но есть мнение, и не только мое, что теория без практики мертва. А чтение кода, без его написания — разве не теория? ;)
И да, придумывание своих реализаций задачи только развивает мозг, что вовсе неплохо, не так ли? :)
Ну удачи Вам в изобретении велосипедов.
По вашей теории оставаться надо было на ассемблере и не повышать уровень языков, развивая мозг придумыванием алгоритмов под него.
Фреймворк это повышение уровня языка, да он требует большего, но и сервак с 4 гигами оперативы и четырёхядерниками уже обычное дело.
По вашей теории оставаться надо было на ассемблере и не повышать уровень языков, развивая мозг придумыванием алгоритмов под него.
Фреймворк это повышение уровня языка, да он требует большего, но и сервак с 4 гигами оперативы и четырёхядерниками уже обычное дело.
Уважаемый, я просто поделился своими планами на будущее.
Моя теория — это развитие мышления. А это дело глобальное, оно не ограничивается языком или фреймворком.
Мой план — это только мой план, и ничего более. Я не призываю к холиварам, не навязываю своего мнения. Просто поддержал человека, с которым у нас схожие мнения.
Взаимно желаю добра и плюсую Ваш пост :)
Моя теория — это развитие мышления. А это дело глобальное, оно не ограничивается языком или фреймворком.
Мой план — это только мой план, и ничего более. Я не призываю к холиварам, не навязываю своего мнения. Просто поддержал человека, с которым у нас схожие мнения.
Взаимно желаю добра и плюсую Ваш пост :)
я конечно жутко извиняюсь, но и сейчас есть люди, которые пишут и под асм и под си… Системщиками их кличут… Просто разные направления деятельности. Более того, взгляните на ситуацию в геймдеве — там часто пишут новые движки, хотя можно использовать чужие.
И да, своя рубашка ближе к телу.
ЗЫ. все это имхо
И да, своя рубашка ближе к телу.
ЗЫ. все это имхо
Изучение чужого кода ближе к практике, чем к теории. Ведь мы изучаем конкретное решение, а не какие-то общие понятия.
Когда-то я тоже проходил через стадию «Напишу своё, чтобы набраться опыта» и считаю это очень полезным для «развития мозга». Это полезно, когда учишься. Я много чего понял, когда писал свой фрэймворк на основе теории из книг «Design Patterns: Elements of Reusable Object-Oriented Software» и «Patterns of Enterprise Application Architecture». И я не жалею, что сидел и изобретал колёса в то время.
А сейчас я предпочитаю использовать готовые решения, такие как ZF, потому что они заметно ускоряют скорость и качество разработки. К тому же, так как я многое узнал, пока изобретал велосипеды, я понимаю бОльшую часть логики, на основе которой построен ZF.
Поэтому, считаю, вопрос не в том, какой из подходов — изобретать велосипед или использовать готовые решения — лучше, а в том, что для Вас является важнее — обучение или быстрая разработка проекта.
А сейчас я предпочитаю использовать готовые решения, такие как ZF, потому что они заметно ускоряют скорость и качество разработки. К тому же, так как я многое узнал, пока изобретал велосипеды, я понимаю бОльшую часть логики, на основе которой построен ZF.
Поэтому, считаю, вопрос не в том, какой из подходов — изобретать велосипед или использовать готовые решения — лучше, а в том, что для Вас является важнее — обучение или быстрая разработка проекта.
Я написал на досуге свою MVC за 2 часа — там и контроллер запросов, и экшны, и шаблоны. Просто для прикола. Немного файлов, несколько килобайт. Для тренировки может быть полезно, но на практике бессмысленно — лучше использовать готовую реализацию из какого-либо фреймворка.
MVC в Zend гибок, в работе не раз убеждались. Можно управлять и представлением, и роутингом и многим чем ещё — используя написание своих, отнаследованных классов, плагины и т.п.
Формы — отдельный разговор. Делать формы «от руки» я бы не сказал, что проще. А валидация? А подстановка значений?
Одно дело, когда разработчик пишет сам, потому что имеющихся решений объективно не хватает (но он их изучил), другое — когда страдает синдромом «сделано не здесь» или считает себя самым умным.
Конечно, хорошо, когда человек начал путь в разработке с написания своей мегапростой и мегаудобной и производительной CMS — сделать не сделает, но чему-то научится. Но изучение на первых порах фреймворка, думаю, не менее (а может быть и более) полезно при правильном подходе. Исходные коды ZF хороши как образец того, к чему можно стремиться.
MVC в Zend гибок, в работе не раз убеждались. Можно управлять и представлением, и роутингом и многим чем ещё — используя написание своих, отнаследованных классов, плагины и т.п.
Формы — отдельный разговор. Делать формы «от руки» я бы не сказал, что проще. А валидация? А подстановка значений?
Одно дело, когда разработчик пишет сам, потому что имеющихся решений объективно не хватает (но он их изучил), другое — когда страдает синдромом «сделано не здесь» или считает себя самым умным.
Конечно, хорошо, когда человек начал путь в разработке с написания своей мегапростой и мегаудобной и производительной CMS — сделать не сделает, но чему-то научится. Но изучение на первых порах фреймворка, думаю, не менее (а может быть и более) полезно при правильном подходе. Исходные коды ZF хороши как образец того, к чему можно стремиться.
не путайте мвц за 2 часа и готовый фреймверк, пусть и самописный, ваши 2 часа и в подметки не будут годиться «маленькому» фреймверку, и то что Вы перечислили из преимуществ у зенда, в любом самописном фреймверке реализовано:
роутинг — первостепенная реализация (как минимум урл разобрать в дефолт)
фронт контроллер — надо ведь откуда-то начинать работу фреймверка
вью — один интерфейс и любой шаблонизатор можно подключить
наследование не зависит от фреймверка, да и формы можно повторить… эти вещи есть везде
роутинг — первостепенная реализация (как минимум урл разобрать в дефолт)
фронт контроллер — надо ведь откуда-то начинать работу фреймверка
вью — один интерфейс и любой шаблонизатор можно подключить
наследование не зависит от фреймверка, да и формы можно повторить… эти вещи есть везде
Мммм, всегда считал MVC (Model-View-Controller) паттерном проектирования/программирования…
Причему тут все, что Вы написали, я не понимаю…
Причему тут все, что Вы написали, я не понимаю…
Делал это дважды. Сначала свой собственный велосипед, потом еще обвес для такого кошмара как DJEM. В результате, обнаружил, что начал дублировать функционал зенда. В данный момент разрабатываю именно на нем)
странно, вот передо мной мвц самописная, и тут отнюдь не несколько килобайт, в вашей мвс были роутеры? перехват ошибок с последующей отдачей пользователю? любой темплейтовый движок можно было подключить без проблем? и + бд уже дотянет до полуметра, так это лишь вершина айсберга для «гибкости и легкости построения»…
зы: в ZF формы делаются на ура, один обьект = одно поле, добавил в форму, и все! проверка валидности одной строчкой (isValid) так же по одной строчке на валидаторы для поля… не вижу ничего страшного в этом — «как 2 пальца»
вот Вы попробуйте настроить на своей мвц роутер на пути
зы: в ZF формы делаются на ура, один обьект = одно поле, добавил в форму, и все! проверка валидности одной строчкой (isValid) так же по одной строчке на валидаторы для поля… не вижу ничего страшного в этом — «как 2 пальца»
вот Вы попробуйте настроить на своей мвц роутер на пути
Кому ресурсы, а кому удобство. Если надо, что бы быстро, то действительно на перле или на сях надо писать. Только вот потом с вопросами «а не дописать ли нам чего-то там, да так что б быстро, и так что б 50 других девов разобрались..» лучше не приставать.
Интересный стиль изложения материала :)
Мне понравилось читать!
Что ZF — да, он хорош, гибко, масштабируемо и доступно.
Впрочем как и сам PHP
Мне понравилось читать!
Что ZF — да, он хорош, гибко, масштабируемо и доступно.
Впрочем как и сам PHP
согласен с va1en0k, ZF удобная и хорошая вещь. Я потрали как-то небольшое колличество времени, и сделав удобную структуру, добавив свои классы, переписав для себе (точнее дополнив) Zконтроллер и Zaction получил каркас, который теперь с легкостью использую в проектах. При этом все влитает очень быстро, так что на выходе получаю результат и малое колличество проблем.
оффтоп, не пинайте больно, изучаю в данный момент рельсы, так вот перечисленное делается на рельсах не за 6 часов, а за меньше часа…
Хотел бы я посмотреть, как Вы это сделаете за час. Полуготовое тяп-ляп решение без тестов же сделанным не считается?
в рельсах система тестирования встроена, тесты там пишуться тоже просто и легко.
И не надо ругаться, посмотрите лучше, я сам был очень удивлен насколько быстро и просто. Опять же говорю что я лично в рельсах новичек как незнамо кто, и почемуто даже у меня получается все быстро.
И не надо ругаться, посмотрите лучше, я сам был очень удивлен насколько быстро и просто. Опять же говорю что я лично в рельсах новичек как незнамо кто, и почемуто даже у меня получается все быстро.
Вообще-то я программист на rails :)
Может просто я тормоз, но мне слабо представляется, как я вот так сходу за час это сделаю.
Может просто я тормоз, но мне слабо представляется, как я вот так сходу за час это сделаю.
авторизация+регистрация+посты+лента+древовидные комменты+чай+кофе+потанцуем
— авторизация+регистрация — script/plugin install restful_authentication
посты+лента+комменты — ну это уж точно Вы в рельсах сделаете за пять минут script/generate model…
древовидность загоняем в модель (добавляем у коммента ссылку на себя)
и всё, потом быстренько правим .html.erb что нагенеирровались по умолчанию, и меньше чем за час управляемся с описанной задачей.
— авторизация+регистрация — script/plugin install restful_authentication
посты+лента+комменты — ну это уж точно Вы в рельсах сделаете за пять минут script/generate model…
древовидность загоняем в модель (добавляем у коммента ссылку на себя)
и всё, потом быстренько правим .html.erb что нагенеирровались по умолчанию, и меньше чем за час управляемся с описанной задачей.
дайте мне кармы и я покажу в посте как я сделаю за час пользователей, авторизацию, посты, древовидные коменты и ленту на рельсах :)
зачем минусовать когда есть способ всё показать и объяснить? :)
кстати ничем не умоляет ZF, очень мощная система, рельсы наверное попроще будут…
зачем минусовать когда есть способ всё показать и объяснить? :)
кстати ничем не умоляет ZF, очень мощная система, рельсы наверное попроще будут…
подкинул кармы. жду пост, ну или в личку)
До того как прочитал ваш комментарий про 1 час, подумал то же самое про Django :)
Конечно, так торопиться не стоит, но по-моему это гораздо более приятная штука, чем ZF.
Рельсы тоже хороши, но тут уже вопрос личных предпочтений. Вообще не стоит ограничиваться языком программирования, многие разработчики на Django и RoR прежде не писали на питоне и руби, но это не проблема, можно освоить достаточно быстро в процессе.
Конечно, так торопиться не стоит, но по-моему это гораздо более приятная штука, чем ZF.
Рельсы тоже хороши, но тут уже вопрос личных предпочтений. Вообще не стоит ограничиваться языком программирования, многие разработчики на Django и RoR прежде не писали на питоне и руби, но это не проблема, можно освоить достаточно быстро в процессе.
я не специалист в джанго, не специалист в RoR, если в Django всё настолько же просто, связно, понятно и логично как в RoR, то я снимаю шляпу :) смотрю на эту статью по ZF и понимаю — что ZF более открыто позволяет делать сложные вещи, но для простых вещей приходится делать лишнюю работу.
У меня тоже сложилось такое впечатление.
собственно статью накатал, в сумме кодинга получилось даже меньше чем на час, больше времени убило написание самой статьи :)
сцылку в студию!
а заглянуть в тутошний мой «blog» никак? :) xiwera.habrahabr.ru/blog/
Очень хочется увидеть подробный туториал «авторизация+регистрация+посты+лента+древовидные комменты».
Если такой где-то есть в интернетах (а я уверен, он есть) не ставьте мне минусик, а киньте ссылку, пожалуйста.
Если такой где-то есть в интернетах (а я уверен, он есть) не ставьте мне минусик, а киньте ссылку, пожалуйста.
кто-нибудь знает, как запихать диспетчера
в main()-функцию расширения typo3?
хотелось бы иметь нормальную структуру ZF-приложения под typo3.
пока у меня получилось установить автолоадер (расширением) и подключить Zend_View, но хотелось бы всех ништяков MVC от ZF. сижу вот правлю Zend_Controller_Dispatcher_Standard
Zend_Controller_Front::getInstance()->dispatch()в main()-функцию расширения typo3?
хотелось бы иметь нормальную структуру ZF-приложения под typo3.
пока у меня получилось установить автолоадер (расширением) и подключить Zend_View, но хотелось бы всех ништяков MVC от ZF. сижу вот правлю Zend_Controller_Dispatcher_Standard
А кто-то может внятно объяснить, зачем во всем ZF насильно пишутся require 'blablabla.php', всодя на нет все возможности автолоада, упаковки ядра в один файл и тд и тп?
потому что не всем по душе Zend_Loader
а упаковать ядро в один фаил это не мешает, надо только вычистить их, м? ;)
а упаковать ядро в один фаил это не мешает, надо только вычистить их, м? ;)
А можно сорцы вашего приложения выложить куда-нибудь для скачивания? Хотелось поближе посмотреть…
сорцы чего? :) «скелета»? хм, давайте тогда попробую их подготовить и в следующую «главу» закину
zendframework.ru/articles/tutorial-building-basic-site-on-zend-framework-1-5 поиск по слову «Заключение»
НЛО прилетело и опубликовало эту надпись здесь
я, кстати, первым делом однажды прикрутил к ZF смарти
потом уже осознал, что смарти — бессмыслица :) Zend_View отлично справляется сам по себе
потом уже осознал, что смарти — бессмыслица :) Zend_View отлично справляется сам по себе
НЛО прилетело и опубликовало эту надпись здесь
почитайте Смирнова: spectator.ru/technology/php/easy_templates — он, в общем, во многом сформировал такое мое мнение :)
ну да ладно, не хочу холиваров. я же не занимаюсь антипиаром смарти, чтобы доказывать, что он не нужен — мне за это не платит никто 8)))
ну да ладно, не хочу холиваров. я же не занимаюсь антипиаром смарти, чтобы доказывать, что он не нужен — мне за это не платит никто 8)))
НЛО прилетело и опубликовало эту надпись здесь
А php-шаблоны — не компилируемые? Аксселераторы байт-кода не в счет?
Я не спорю, мне правда интересно.
Я не спорю, мне правда интересно.
НЛО прилетело и опубликовало эту надпись здесь
Мне казалось, автор коммента выше говорил о компилируемости в контексте скорости, а не удобства для верстальщиков-неучей.
Видимо, мне повезло — все верстальщики, с которыми я работаю, не настолько ленивы, чтобы не быть в состоянии выучить 5-10 простых конструкций на php, выполняющих функции, совершенно аналогичные приведенным вами.
Видимо, мне повезло — все верстальщики, с которыми я работаю, не настолько ленивы, чтобы не быть в состоянии выучить 5-10 простых конструкций на php, выполняющих функции, совершенно аналогичные приведенным вами.
Вы бы изучили возможности ZF поглубже, особенно Zend_Layout и view helpers — очень может быть, что возвращаться к Smarty пропадет всякое желание.
Кстати, в тех компаниях, где доводилось работать мне, верстальщики никогда не верстали непосредственно шаблоны — они верстали «мёртвые» HTML-ки, которые девелоперы потом «оживляли» при помощи того шаблонизатора, с которым им комфортнее работать.
Кстати, в тех компаниях, где доводилось работать мне, верстальщики никогда не верстали непосредственно шаблоны — они верстали «мёртвые» HTML-ки, которые девелоперы потом «оживляли» при помощи того шаблонизатора, с которым им комфортнее работать.
Ура. Дождались.
Про всю чушь уже написали мензурки-коробки и прочие части.
Наконец и про ZF!
Про всю чушь уже написали мензурки-коробки и прочие части.
Наконец и про ZF!
Спасибо за обзор ZF, как раз на днях решил, что стоит переделать свою небольшую CMS под него, теперь разбираться, думаю, будет чуть проще. Конструктивно: понравилось описание контроллера, согласен с мыслью что «в Видах должен быть весь-весь HTML», релизация тут уж как кому нравится, а вот модель я думаю можно сделать поинтереснее, для отражения составных иерархический сущностей, хотя в большинстве случаев такого варианта будет достаточно. К стати, должно все работать быстро, так как архитектура фреймворка простая, компоненты маловзаимозависимы, что хочеш, то и используй как больше нравится, помоему шикарно. Что-то я сильно сомневаюсь, в том что те у кого «тормозит» смогут показать мне свою более-мение внятную php альтернативу ZF.
мне показалось, что то что написано в статье новичку ЗФ непонять никак, а те кто поймут, уже всё это знают. Будьте немного помягче с читателем. А так я бы с удовольствием почитал продолжение, только мне кажется не стоит писать про Auth блоги и тд. потому что на хабре уже была такая статья и даже не одна. в самом начале с тех пор ничего не изменилось вроде сильно в этих вопросах.
Я бы с удовольствием почитал о рациональном использовании ЗФ, потому что чувствую во многих моментах себя быдлокодером (
Я бы с удовольствием почитал о рациональном использовании ЗФ, потому что чувствую во многих моментах себя быдлокодером (
Кстати, я совершенно случайно пару дней назад искал реализованный каркас, чтобы почерпнуть новые мысли по эффективной разработке на базе ZF. Тут некоторые спрашивали исходники. Ну и пока автор статьи подготавливает их, особо нетерпеливым предлагается «поковырять» довольно свежее opensource решение, естественно на базе ZF: Digitalus CMS.
Порадовало, что в отличии от, например, тяжеловесного Magento, в вышеназванном приложении всё довольно просто и лаконично, без диких цепочек наследований и туманной реализации EAV. Рекомендую обратить внимание на pageBuilder. В общем нетерпеливым продуктивного изучения, а от автора ждём скорого продолжения :)
Порадовало, что в отличии от, например, тяжеловесного Magento, в вышеназванном приложении всё довольно просто и лаконично, без диких цепочек наследований и туманной реализации EAV. Рекомендую обратить внимание на pageBuilder. В общем нетерпеливым продуктивного изучения, а от автора ждём скорого продолжения :)
О подробностях БД-части модели хотелось бы отдельную статью. С использованием Zend_Db и разных хитрых типов связей таблиц.
жду продолжения.
Статья хорошая, спасибо вам.
Немного критики, если позволите :)
Вместо хелперов типа "<?=$this->printUser($this->user)?>", часто бывает удобнее использовать механизмы типа view helper'а partial — иначе придется генерировать много HTML-кода внутри хелпера, конкатенировать его в строку и т.д., а мне это кажется неудобным.
Кроме того, называть собственные классы с префиксом Zend (типа Zend_View_Helper_Errors) — это моветон.
Создайте собственную директорию внутри library, выберите себе префикс по вкусу и называйте классы, например, Super_View_Helper_Errors, складывая их в library/super/view/…
Конечно, в данном конкретном случае, нужно будет отдельно добавить эту директорию в настройки View (к примеру, в бутстрапе) при помощи $view->addHelperPath('/my/cool/project/library/super/view/helper', 'Super_View_Helper').
Немного критики, если позволите :)
Вместо хелперов типа "<?=$this->printUser($this->user)?>", часто бывает удобнее использовать механизмы типа view helper'а partial — иначе придется генерировать много HTML-кода внутри хелпера, конкатенировать его в строку и т.д., а мне это кажется неудобным.
Кроме того, называть собственные классы с префиксом Zend (типа Zend_View_Helper_Errors) — это моветон.
Создайте собственную директорию внутри library, выберите себе префикс по вкусу и называйте классы, например, Super_View_Helper_Errors, складывая их в library/super/view/…
Конечно, в данном конкретном случае, нужно будет отдельно добавить эту директорию в настройки View (к примеру, в бутстрапе) при помощи $view->addHelperPath('/my/cool/project/library/super/view/helper', 'Super_View_Helper').
Привет, va1en0k! Мы рады, что ты вернулся :)
Несмоторя на то что дочитал до конца (ну это правдо из за того что есть большое желание хорошо въехать в ZF), всякие выражения и названия классов к стиле «упячки», очень отбивали желание продолжать делать это (дочитывать до конца), и хотелось все закрыть и заминусовать… Но несмотря на это, спасибо за статью, и жду следующею, надеюсь без этих выражений…
НЛО прилетело и опубликовало эту надпись здесь
URL обрабатывается с помощью роутов и если мы использовали роут, например, 'post/:post_id/*', то в контроллере мы сможем с помощью $this->_getParam('post_id') получить этот параметр.
При этом совсем необязательно, что бы имя контроллера совпадало с post. Модуль, контроллер и экшен — это всё указывается в настройках роута.
Один из роутов, используемый в нашем проетке, выглядит так:
new Zend_Controller_Router_Route('user/:login/:action/*', array('module' => 'default', 'controller' => 'user', 'action' => 'index'));
Если нужны объяснения — спрашивайте :)
При этом совсем необязательно, что бы имя контроллера совпадало с post. Модуль, контроллер и экшен — это всё указывается в настройках роута.
Один из роутов, используемый в нашем проетке, выглядит так:
new Zend_Controller_Router_Route('user/:login/:action/*', array('module' => 'default', 'controller' => 'user', 'action' => 'index'));
Если нужны объяснения — спрашивайте :)
стиль повестоваавания поста понра!
продолжайте в том же духе — спасибо (:
продолжайте в том же духе — спасибо (:
Сразу видно влияние Лепры на автора :)
1. перегружать Zend_Action_Controller и Zend_Front_Controller зачастую не нужно. Зенд предлагает для упомянутых задач использовать плагины.
2. Отказываться от Zend_Form не обязательно. Вы не учитываете что помимо генерации верстки это еще и весьма удобный механизм компоновки валидаторов, фильтров, метаданных относящихся к форме. Zend_Form вообще не заставляет вас выводить форму. Лично мне работать с формой как с объектом бывает весьма удобно. Хотя при сложных дизайнерских формах конечно проще будет ее верстку написать руками. Подробнее свою позицию изложил тут.
2. Отказываться от Zend_Form не обязательно. Вы не учитываете что помимо генерации верстки это еще и весьма удобный механизм компоновки валидаторов, фильтров, метаданных относящихся к форме. Zend_Form вообще не заставляет вас выводить форму. Лично мне работать с формой как с объектом бывает весьма удобно. Хотя при сложных дизайнерских формах конечно проще будет ее верстку написать руками. Подробнее свою позицию изложил тут.
2. Тяжеловаты примеры. Дело в том, что цель сделать «легкодорабатываемое» приложение, а использование Zend_Form тут же прячет от нас генерацию html-кода или заставляет расписывать его вот как-то так, как там у вас, да?
Окей, по-моему, это не круто ;-) От Zend_Form будет трудно резко отказаться уже потом, когда все уже сделано на нем, а использование его превращается в кропотливую работу, ну, как мне кажется
1. Спасибо, я посмотрю еще раз. Не помню, почему от них отказался. Когда я впервые субклассировал фронт_контроллер, был еще зф 1.5.0 и что-то там нужное мне не работало (или я просто не разобрался, возможно, так)
<?php echo $this->formRegister->name->getLabel(); ?>
<input
type="text"
name="<?php echo $this->formRegister->name->getName(); ?>"
value="<?php echo $this->formRegister->name->getValue(); ?>"
maxlength="<?php echo $this->formRegister->name->getAttrib('maxlength'); ?>"
/>Окей, по-моему, это не круто ;-) От Zend_Form будет трудно резко отказаться уже потом, когда все уже сделано на нем, а использование его превращается в кропотливую работу, ну, как мне кажется
1. Спасибо, я посмотрю еще раз. Не помню, почему от них отказался. Когда я впервые субклассировал фронт_контроллер, был еще зф 1.5.0 и что-то там нужное мне не работало (или я просто не разобрался, возможно, так)
Выше я написал что генерацию верстки можно не делать. Но это не значит что нужно полностью выбросить Zend_Form, в любом случае придется писать какой то свой механизм обработки ошибок к примеру.
А чем пример тяжеловат, ну допустим метку можно вывести еще руками.
а name, value, maxlength это явно не забота верстальщика. И хорошо если эти параметры можно настраивать из одного места.
Если очень хочется можно упростить даже до такого
Проще этого не будет даже если вы будете делать полностью руками.
А чем пример тяжеловат, ну допустим метку можно вывести еще руками.
а name, value, maxlength это явно не забота верстальщика. И хорошо если эти параметры можно настраивать из одного места.
Если очень хочется можно упростить даже до такого
<iinput
type="text"
name="email"
value="<?php echo $this->formRegister->name->getValue(); ?>"
maxlength="20"
/>
Проще этого не будет даже если вы будете делать полностью руками.
Так я вот подумали изменил свою точку зрения насчёт того, что статьи типа «написание блогового движка» не нужны. Мне кажется что всё что я читал ранее было написано немного недобросовестно. Всего по чуть чуть и в итоге ничего серьёзного. Вот если кто-то возьмётся написать такую статью, где будет всё грамотно и полно описано, так чтобы придраться не было возможности, то цены такой статье не будет, хотя возможно договоримся)) На пример одного модуля или контроллера рассказать о ЗФ так, чтобы дальше любой другой модуль не вызывал никаких трудностей и при этом чтобы была уверенность, что Зенд используется наиболее эффективно. По-моему это вполне реально написать и многим поможет
Есть такая статья, правда, не одна, а серия. Здесь первая часть.
Вряд ли этот туториал претендует на звание «придраться нет возможности»
В целом считаю в любом объемном труде будет авторский стиль, который другим может не подходить.
В целом считаю в любом объемном труде будет авторский стиль, который другим может не подходить.
В отличие от многих авторов подобных туториалов, Padraic Brady реально участвует в разработке ZF, и уж кому, как не ему знать, как эффективно и идеологически правильно использовать данный фреймворк.
Я его весьма подробно прорабатывал в свое время. Он хорош, но не идеален, и не совсем для полных новичков. Padraic Brady один из большой команды, со своим мнением, хотя здесь framework.zend.com/community/contributors, о нем почему-то забыли. К примеру в некоторых моментах его подход отличается от подхода Matthew Weier O'Phinney, который является разработчиком ZF еще в большей мере.
А я чего-то не понял. Продолжение-то ждать? Или рыдать и колоться самому? :)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Zend Framework первой свежести, ч1: зендируем MVC