Comments 135
по мне так ZF неоправданно жрет много ресурсов проца
-21
да? ну ладно. удалю его со всех проектов. да лучше вообще их на Перле перепишу, вот это скорость, вот это мощь!
+18
о вкусах не спорят, но признаюсь перл мне по душе =)
-2
не спорю, у него есть плюсы :)
давайте эта ветка будет единственной и последней веткой, в которой будет обсуждаться сам вопрос использования ZF. я пишу для тех, кто уже выбрал его ;) спасибо за ваше мнение
давайте эта ветка будет единственной и последней веткой, в которой будет обсуждаться сам вопрос использования ZF. я пишу для тех, кто уже выбрал его ;) спасибо за ваше мнение
+10
не знаешь, как вручную установить контроллер и акцию?
я не могу использовать ссылки вида /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, но пока безрезультатно
0
надо не со стандартным роутером колдовать, а свой писать. вам в помощь framework.zend.com/manual/en/zend.controller.request.html обьект запроса и дальше мануал
0
я эту страницу уже два дня читаю.
сделал проще:
сейчас времени нет разбираться, потом ещё почитаю
сделал проще:
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');
}
}
сейчас времени нет разбираться, потом ещё почитаю
0
Давайте перепишем ZF на ассемблере ))
+1
Не, ну на плюсах можно :) PHP ведь на плюсах :)
Как раз то ли здесь, то ли на PHP форуме каком-то были подробные инструкции о том, как писать свои расширения к PHP на C++.
Под высоко нагруженные проекты или просто часто используемые вещи можно и написать…
Как раз то ли здесь, то ли на PHP форуме каком-то были подробные инструкции о том, как писать свои расширения к PHP на C++.
Под высоко нагруженные проекты или просто часто используемые вещи можно и написать…
0
А можно как-нибудь поподробнее? Мне как раз нужно написать своё расширение для PHP!
0
phpclub.ru/talk/forumdisplay.php?s=&forumid=44
Вроде вот это.
Вроде вот это.
0
да? а в курсе сколько ресов жрёт обычный include или require? и учитывая портовость зенда — ну-ка, прикинь, что будет лучше — своя маленькая гибкая МВЦ или «три кита в ещё одном гипербольшом ките»?
-4
я серьезно абсолютно. каждому — своё. мне нравится ZF и я готов пару минут поколдовать с eAccelerator-ом и другими штуками ради веселого и простого кодинга. вам не нравится? окей, напишите свой фреймворк, придумайте что-нибудь еще — но не навязывайте мне своего мнения! пожалуйста
+3
а если обьеденить все нужние файли в один;)?
проверено, що include[_once] забирает какую-то там мимлсекунду.
так зачем нужно тратить время на подгрузку всех необходимих файлов, если можно всю основную библиотеку класов собрать в один файл? при етом время ускоряется до 22-х раз… Статья Дмитрия Котерова: dklab.ru/chicken/nablas/49.html
проверено, що include[_once] забирает какую-то там мимлсекунду.
так зачем нужно тратить время на подгрузку всех необходимих файлов, если можно всю основную библиотеку класов собрать в один файл? при етом время ускоряется до 22-х раз… Статья Дмитрия Котерова: dklab.ru/chicken/nablas/49.html
0
А зачем нужна маленькая «МВЦ»? Для маленьких сайтов-визиток? При создании проекта покрупней эта «маленькая» обрастёт кучей… кода, и станет головной болью. Уж лучше Zend, где есть некоторая избыточность, но именно она обеспечивает хорошую гибкость и конфигурируемость MVC-инфраструктуры.
0
а «маленькая» не может быть гибкой и конфигурируемой?
0
А использовать акселераторы уже не модно? Затраты на include закешированного акселлератором скрипта — ноль миллисекунд.
0
Да, ZF перегружен кодом, это плата за 1) возможность взаимоменяемости компонентов (посмотрите например на код для работы с БД, ) 2) попытку сделать универсальный фреймворк.
Да и одни названия классов по 30 символов чего стоят… брр… проще надо.
Возвращаясь к DAL в ZF — нагородили кучу кода, и что? Даже нормальной работы с плейсхолдерами нет, то есть надо поверх всего этого еще совй код писать, получается в результате монстр.
Да и одни названия классов по 30 символов чего стоят… брр… проще надо.
Возвращаясь к DAL в ZF — нагородили кучу кода, и что? Даже нормальной работы с плейсхолдерами нет, то есть надо поверх всего этого еще совй код писать, получается в результате монстр.
+1
А вы будете дома на 600 селероне размещать крупный проект? Да и как говорилось, кеширование спасает всю ситуацию.
0
UFO just landed and posted this here
а может Вы его просто использовать не умеете?
0
не забанят…
0
* rouses.php [1]
Поправь плиз на routes.php
Поправь плиз на routes.php
+1
"(часов за 6 легко делается без особого напряга набор авторизация+регистрация+посты+лента+древовидные комменты+чай+кофе+потанцуем"
не вижу смысла тратить на такую мелочь целых 6 часов.
не вижу смысла тратить на такую мелочь целых 6 часов.
-20
да вообще, челябинские мужики делают сервер за минуту на перле
+20
Сейчас еще любители джумлы припрутся.
+7
сразу видно кто юзает зенд — тот отчаянно минусует ;)) хомячки
вот если кто-нибудь попробует написать свою МВЦ, только нормально продумывая каждый шаг, то тогда будет иметь право плюсовать или минусовать за зенд.
лично я попытался и написал свою МВЦ, которая поместилась дай бог в несколько килобайт.
Ну да там нету миллиона optional пакетов, зато есть гибкость и легкость построения, на которой остался настоящий принцип МВЦ, без лишнего мяса и миллиарда ненужных проверок.
давайте-ка вспомним сколько всего нужно чтобы сделать обычную форму в зенде. И это, вы скажете, «гибкая система»?
в общем я хотел лишь сказать, что «суровые» кодеры юзают сторонние фреймворки, а «свою крепость строить даже не пробовали»
вот если кто-нибудь попробует написать свою МВЦ, только нормально продумывая каждый шаг, то тогда будет иметь право плюсовать или минусовать за зенд.
лично я попытался и написал свою МВЦ, которая поместилась дай бог в несколько килобайт.
Ну да там нету миллиона optional пакетов, зато есть гибкость и легкость построения, на которой остался настоящий принцип МВЦ, без лишнего мяса и миллиарда ненужных проверок.
давайте-ка вспомним сколько всего нужно чтобы сделать обычную форму в зенде. И это, вы скажете, «гибкая система»?
в общем я хотел лишь сказать, что «суровые» кодеры юзают сторонние фреймворки, а «свою крепость строить даже не пробовали»
-3
Согласен с тобой.
Свой фреймворк — вещь хорошая.
Но как-то совпало так, что я сейчас учу ZF и это статья именно о нем. Когда я пойму в чем соль ZF, что в нем хорошо, что плохо — напишу свой, мелки, но сочни фреймворк.
Свой фреймворк — вещь хорошая.
Но как-то совпало так, что я сейчас учу ZF и это статья именно о нем. Когда я пойму в чем соль ZF, что в нем хорошо, что плохо — напишу свой, мелки, но сочни фреймворк.
+1
никто не запрещал использовать отдельние компоненти ZF в своих приложениях… они легко подключаются ж не создавая никаких трудностей)
+1
Я собираюсь писать свой фреймворк для того, чтоб не зависеть ни от кого.
Плюс, во время написания своего фреймворка я подниму намного больше опыта, чем при использовании ZF-компонент в отдельном приложении.
А еще это будет большим плюсом при трудоустройстве куда угодно.
Плюс, во время написания своего фреймворка я подниму намного больше опыта, чем при использовании ZF-компонент в отдельном приложении.
А еще это будет большим плюсом при трудоустройстве куда угодно.
+1
Нет, не будет. По крайней мере — не куда угодно.
+1
Читая чужой код Вы получите гораздо больше опыта, чем если бы Вы сами придумали несколько реализаций одной задачи. Проверенно. Тем более код таких монстр-программеров.
P.S. Не читайте код вордпресса, во избежание взрыва мозга :-)
P.S. Не читайте код вордпресса, во избежание взрыва мозга :-)
+2
Хехе :)
Но есть мнение, и не только мое, что теория без практики мертва. А чтение кода, без его написания — разве не теория? ;)
И да, придумывание своих реализаций задачи только развивает мозг, что вовсе неплохо, не так ли? :)
Но есть мнение, и не только мое, что теория без практики мертва. А чтение кода, без его написания — разве не теория? ;)
И да, придумывание своих реализаций задачи только развивает мозг, что вовсе неплохо, не так ли? :)
+1
Ну удачи Вам в изобретении велосипедов.
По вашей теории оставаться надо было на ассемблере и не повышать уровень языков, развивая мозг придумыванием алгоритмов под него.
Фреймворк это повышение уровня языка, да он требует большего, но и сервак с 4 гигами оперативы и четырёхядерниками уже обычное дело.
По вашей теории оставаться надо было на ассемблере и не повышать уровень языков, развивая мозг придумыванием алгоритмов под него.
Фреймворк это повышение уровня языка, да он требует большего, но и сервак с 4 гигами оперативы и четырёхядерниками уже обычное дело.
+3
Уважаемый, я просто поделился своими планами на будущее.
Моя теория — это развитие мышления. А это дело глобальное, оно не ограничивается языком или фреймворком.
Мой план — это только мой план, и ничего более. Я не призываю к холиварам, не навязываю своего мнения. Просто поддержал человека, с которым у нас схожие мнения.
Взаимно желаю добра и плюсую Ваш пост :)
Моя теория — это развитие мышления. А это дело глобальное, оно не ограничивается языком или фреймворком.
Мой план — это только мой план, и ничего более. Я не призываю к холиварам, не навязываю своего мнения. Просто поддержал человека, с которым у нас схожие мнения.
Взаимно желаю добра и плюсую Ваш пост :)
+2
я конечно жутко извиняюсь, но и сейчас есть люди, которые пишут и под асм и под си… Системщиками их кличут… Просто разные направления деятельности. Более того, взгляните на ситуацию в геймдеве — там часто пишут новые движки, хотя можно использовать чужие.
И да, своя рубашка ближе к телу.
ЗЫ. все это имхо
И да, своя рубашка ближе к телу.
ЗЫ. все это имхо
+1
Изучение чужого кода ближе к практике, чем к теории. Ведь мы изучаем конкретное решение, а не какие-то общие понятия.
0
Когда-то я тоже проходил через стадию «Напишу своё, чтобы набраться опыта» и считаю это очень полезным для «развития мозга». Это полезно, когда учишься. Я много чего понял, когда писал свой фрэймворк на основе теории из книг «Design Patterns: Elements of Reusable Object-Oriented Software» и «Patterns of Enterprise Application Architecture». И я не жалею, что сидел и изобретал колёса в то время.
А сейчас я предпочитаю использовать готовые решения, такие как ZF, потому что они заметно ускоряют скорость и качество разработки. К тому же, так как я многое узнал, пока изобретал велосипеды, я понимаю бОльшую часть логики, на основе которой построен ZF.
Поэтому, считаю, вопрос не в том, какой из подходов — изобретать велосипед или использовать готовые решения — лучше, а в том, что для Вас является важнее — обучение или быстрая разработка проекта.
А сейчас я предпочитаю использовать готовые решения, такие как ZF, потому что они заметно ускоряют скорость и качество разработки. К тому же, так как я многое узнал, пока изобретал велосипеды, я понимаю бОльшую часть логики, на основе которой построен ZF.
Поэтому, считаю, вопрос не в том, какой из подходов — изобретать велосипед или использовать готовые решения — лучше, а в том, что для Вас является важнее — обучение или быстрая разработка проекта.
0
Я написал на досуге свою MVC за 2 часа — там и контроллер запросов, и экшны, и шаблоны. Просто для прикола. Немного файлов, несколько килобайт. Для тренировки может быть полезно, но на практике бессмысленно — лучше использовать готовую реализацию из какого-либо фреймворка.
MVC в Zend гибок, в работе не раз убеждались. Можно управлять и представлением, и роутингом и многим чем ещё — используя написание своих, отнаследованных классов, плагины и т.п.
Формы — отдельный разговор. Делать формы «от руки» я бы не сказал, что проще. А валидация? А подстановка значений?
Одно дело, когда разработчик пишет сам, потому что имеющихся решений объективно не хватает (но он их изучил), другое — когда страдает синдромом «сделано не здесь» или считает себя самым умным.
Конечно, хорошо, когда человек начал путь в разработке с написания своей мегапростой и мегаудобной и производительной CMS — сделать не сделает, но чему-то научится. Но изучение на первых порах фреймворка, думаю, не менее (а может быть и более) полезно при правильном подходе. Исходные коды ZF хороши как образец того, к чему можно стремиться.
MVC в Zend гибок, в работе не раз убеждались. Можно управлять и представлением, и роутингом и многим чем ещё — используя написание своих, отнаследованных классов, плагины и т.п.
Формы — отдельный разговор. Делать формы «от руки» я бы не сказал, что проще. А валидация? А подстановка значений?
Одно дело, когда разработчик пишет сам, потому что имеющихся решений объективно не хватает (но он их изучил), другое — когда страдает синдромом «сделано не здесь» или считает себя самым умным.
Конечно, хорошо, когда человек начал путь в разработке с написания своей мегапростой и мегаудобной и производительной CMS — сделать не сделает, но чему-то научится. Но изучение на первых порах фреймворка, думаю, не менее (а может быть и более) полезно при правильном подходе. Исходные коды ZF хороши как образец того, к чему можно стремиться.
+6
не путайте мвц за 2 часа и готовый фреймверк, пусть и самописный, ваши 2 часа и в подметки не будут годиться «маленькому» фреймверку, и то что Вы перечислили из преимуществ у зенда, в любом самописном фреймверке реализовано:
роутинг — первостепенная реализация (как минимум урл разобрать в дефолт)
фронт контроллер — надо ведь откуда-то начинать работу фреймверка
вью — один интерфейс и любой шаблонизатор можно подключить
наследование не зависит от фреймверка, да и формы можно повторить… эти вещи есть везде
роутинг — первостепенная реализация (как минимум урл разобрать в дефолт)
фронт контроллер — надо ведь откуда-то начинать работу фреймверка
вью — один интерфейс и любой шаблонизатор можно подключить
наследование не зависит от фреймверка, да и формы можно повторить… эти вещи есть везде
0
Мммм, всегда считал MVC (Model-View-Controller) паттерном проектирования/программирования…
Причему тут все, что Вы написали, я не понимаю…
Причему тут все, что Вы написали, я не понимаю…
+3
Делал это дважды. Сначала свой собственный велосипед, потом еще обвес для такого кошмара как DJEM. В результате, обнаружил, что начал дублировать функционал зенда. В данный момент разрабатываю именно на нем)
0
странно, вот передо мной мвц самописная, и тут отнюдь не несколько килобайт, в вашей мвс были роутеры? перехват ошибок с последующей отдачей пользователю? любой темплейтовый движок можно было подключить без проблем? и + бд уже дотянет до полуметра, так это лишь вершина айсберга для «гибкости и легкости построения»…
зы: в ZF формы делаются на ура, один обьект = одно поле, добавил в форму, и все! проверка валидности одной строчкой (isValid) так же по одной строчке на валидаторы для поля… не вижу ничего страшного в этом — «как 2 пальца»
вот Вы попробуйте настроить на своей мвц роутер на пути
зы: в ZF формы делаются на ура, один обьект = одно поле, добавил в форму, и все! проверка валидности одной строчкой (isValid) так же по одной строчке на валидаторы для поля… не вижу ничего страшного в этом — «как 2 пальца»
вот Вы попробуйте настроить на своей мвц роутер на пути
0
Кому ресурсы, а кому удобство. Если надо, что бы быстро, то действительно на перле или на сях надо писать. Только вот потом с вопросами «а не дописать ли нам чего-то там, да так что б быстро, и так что б 50 других девов разобрались..» лучше не приставать.
0
Интересный стиль изложения материала :)
Мне понравилось читать!
Что ZF — да, он хорош, гибко, масштабируемо и доступно.
Впрочем как и сам PHP
Мне понравилось читать!
Что ZF — да, он хорош, гибко, масштабируемо и доступно.
Впрочем как и сам PHP
+3
согласен с va1en0k, ZF удобная и хорошая вещь. Я потрали как-то небольшое колличество времени, и сделав удобную структуру, добавив свои классы, переписав для себе (точнее дополнив) Zконтроллер и Zaction получил каркас, который теперь с легкостью использую в проектах. При этом все влитает очень быстро, так что на выходе получаю результат и малое колличество проблем.
+4
оффтоп, не пинайте больно, изучаю в данный момент рельсы, так вот перечисленное делается на рельсах не за 6 часов, а за меньше часа…
-4
Хотел бы я посмотреть, как Вы это сделаете за час. Полуготовое тяп-ляп решение без тестов же сделанным не считается?
+2
в рельсах система тестирования встроена, тесты там пишуться тоже просто и легко.
И не надо ругаться, посмотрите лучше, я сам был очень удивлен насколько быстро и просто. Опять же говорю что я лично в рельсах новичек как незнамо кто, и почемуто даже у меня получается все быстро.
И не надо ругаться, посмотрите лучше, я сам был очень удивлен насколько быстро и просто. Опять же говорю что я лично в рельсах новичек как незнамо кто, и почемуто даже у меня получается все быстро.
0
Вообще-то я программист на rails :)
Может просто я тормоз, но мне слабо представляется, как я вот так сходу за час это сделаю.
Может просто я тормоз, но мне слабо представляется, как я вот так сходу за час это сделаю.
0
авторизация+регистрация+посты+лента+древовидные комменты+чай+кофе+потанцуем
— авторизация+регистрация — script/plugin install restful_authentication
посты+лента+комменты — ну это уж точно Вы в рельсах сделаете за пять минут script/generate model…
древовидность загоняем в модель (добавляем у коммента ссылку на себя)
и всё, потом быстренько правим .html.erb что нагенеирровались по умолчанию, и меньше чем за час управляемся с описанной задачей.
— авторизация+регистрация — script/plugin install restful_authentication
посты+лента+комменты — ну это уж точно Вы в рельсах сделаете за пять минут script/generate model…
древовидность загоняем в модель (добавляем у коммента ссылку на себя)
и всё, потом быстренько правим .html.erb что нагенеирровались по умолчанию, и меньше чем за час управляемся с описанной задачей.
+6
дайте мне кармы и я покажу в посте как я сделаю за час пользователей, авторизацию, посты, древовидные коменты и ленту на рельсах :)
зачем минусовать когда есть способ всё показать и объяснить? :)
кстати ничем не умоляет ZF, очень мощная система, рельсы наверное попроще будут…
зачем минусовать когда есть способ всё показать и объяснить? :)
кстати ничем не умоляет ZF, очень мощная система, рельсы наверное попроще будут…
+3
подкинул кармы. жду пост, ну или в личку)
0
ок, катаю пост, отпишу в личку как сделаю, думаю на пост уйдет не намного больше времени чем я сказал выше. Начал в 21:00 по москве. Пуск.
0
весь в предвкушении. секундомер запущен
0
да, печатаю я медленно, но зато я все что писал проверял, можно смотреть в моём личном, все что я написал сделал за полтора часа, остальное потратил на исправление мелких ошибок.
0
простите что влезаю, но мне тоже жутко интересно
0
До того как прочитал ваш комментарий про 1 час, подумал то же самое про Django :)
Конечно, так торопиться не стоит, но по-моему это гораздо более приятная штука, чем ZF.
Рельсы тоже хороши, но тут уже вопрос личных предпочтений. Вообще не стоит ограничиваться языком программирования, многие разработчики на Django и RoR прежде не писали на питоне и руби, но это не проблема, можно освоить достаточно быстро в процессе.
Конечно, так торопиться не стоит, но по-моему это гораздо более приятная штука, чем ZF.
Рельсы тоже хороши, но тут уже вопрос личных предпочтений. Вообще не стоит ограничиваться языком программирования, многие разработчики на Django и RoR прежде не писали на питоне и руби, но это не проблема, можно освоить достаточно быстро в процессе.
+2
я не специалист в джанго, не специалист в RoR, если в Django всё настолько же просто, связно, понятно и логично как в RoR, то я снимаю шляпу :) смотрю на эту статью по ZF и понимаю — что ZF более открыто позволяет делать сложные вещи, но для простых вещей приходится делать лишнюю работу.
0
У меня тоже сложилось такое впечатление.
0
собственно статью накатал, в сумме кодинга получилось даже меньше чем на час, больше времени убило написание самой статьи :)
+1
сцылку в студию!
0
а заглянуть в тутошний мой «blog» никак? :) xiwera.habrahabr.ru/blog/
0
Очень хочется увидеть подробный туториал «авторизация+регистрация+посты+лента+древовидные комменты».
Если такой где-то есть в интернетах (а я уверен, он есть) не ставьте мне минусик, а киньте ссылку, пожалуйста.
Если такой где-то есть в интернетах (а я уверен, он есть) не ставьте мне минусик, а киньте ссылку, пожалуйста.
+1
кто-нибудь знает, как запихать диспетчера
в 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
0
А кто-то может внятно объяснить, зачем во всем ZF насильно пишутся require 'blablabla.php', всодя на нет все возможности автолоада, упаковки ядра в один файл и тд и тп?
0
потому что не всем по душе Zend_Loader
а упаковать ядро в один фаил это не мешает, надо только вычистить их, м? ;)
а упаковать ядро в один фаил это не мешает, надо только вычистить их, м? ;)
+1
А можно сорцы вашего приложения выложить куда-нибудь для скачивания? Хотелось поближе посмотреть…
+1
сорцы чего? :) «скелета»? хм, давайте тогда попробую их подготовить и в следующую «главу» закину
+2
zendframework.ru/articles/tutorial-building-basic-site-on-zend-framework-1-5 поиск по слову «Заключение»
0
UFO just landed and posted this here
я, кстати, первым делом однажды прикрутил к ZF смарти
потом уже осознал, что смарти — бессмыслица :) Zend_View отлично справляется сам по себе
потом уже осознал, что смарти — бессмыслица :) Zend_View отлично справляется сам по себе
+3
UFO just landed and posted this here
почитайте Смирнова: spectator.ru/technology/php/easy_templates — он, в общем, во многом сформировал такое мое мнение :)
ну да ладно, не хочу холиваров. я же не занимаюсь антипиаром смарти, чтобы доказывать, что он не нужен — мне за это не платит никто 8)))
ну да ладно, не хочу холиваров. я же не занимаюсь антипиаром смарти, чтобы доказывать, что он не нужен — мне за это не платит никто 8)))
+4
UFO just landed and posted this here
А php-шаблоны — не компилируемые? Аксселераторы байт-кода не в счет?
Я не спорю, мне правда интересно.
Я не спорю, мне правда интересно.
0
UFO just landed and posted this here
Мне казалось, автор коммента выше говорил о компилируемости в контексте скорости, а не удобства для верстальщиков-неучей.
Видимо, мне повезло — все верстальщики, с которыми я работаю, не настолько ленивы, чтобы не быть в состоянии выучить 5-10 простых конструкций на php, выполняющих функции, совершенно аналогичные приведенным вами.
Видимо, мне повезло — все верстальщики, с которыми я работаю, не настолько ленивы, чтобы не быть в состоянии выучить 5-10 простых конструкций на php, выполняющих функции, совершенно аналогичные приведенным вами.
0
Вы бы изучили возможности ZF поглубже, особенно Zend_Layout и view helpers — очень может быть, что возвращаться к Smarty пропадет всякое желание.
Кстати, в тех компаниях, где доводилось работать мне, верстальщики никогда не верстали непосредственно шаблоны — они верстали «мёртвые» HTML-ки, которые девелоперы потом «оживляли» при помощи того шаблонизатора, с которым им комфортнее работать.
Кстати, в тех компаниях, где доводилось работать мне, верстальщики никогда не верстали непосредственно шаблоны — они верстали «мёртвые» HTML-ки, которые девелоперы потом «оживляли» при помощи того шаблонизатора, с которым им комфортнее работать.
0
Ура. Дождались.
Про всю чушь уже написали мензурки-коробки и прочие части.
Наконец и про ZF!
Про всю чушь уже написали мензурки-коробки и прочие части.
Наконец и про ZF!
0
Спасибо за обзор ZF, как раз на днях решил, что стоит переделать свою небольшую CMS под него, теперь разбираться, думаю, будет чуть проще. Конструктивно: понравилось описание контроллера, согласен с мыслью что «в Видах должен быть весь-весь HTML», релизация тут уж как кому нравится, а вот модель я думаю можно сделать поинтереснее, для отражения составных иерархический сущностей, хотя в большинстве случаев такого варианта будет достаточно. К стати, должно все работать быстро, так как архитектура фреймворка простая, компоненты маловзаимозависимы, что хочеш, то и используй как больше нравится, помоему шикарно. Что-то я сильно сомневаюсь, в том что те у кого «тормозит» смогут показать мне свою более-мение внятную php альтернативу ZF.
0
мне показалось, что то что написано в статье новичку ЗФ непонять никак, а те кто поймут, уже всё это знают. Будьте немного помягче с читателем. А так я бы с удовольствием почитал продолжение, только мне кажется не стоит писать про Auth блоги и тд. потому что на хабре уже была такая статья и даже не одна. в самом начале с тех пор ничего не изменилось вроде сильно в этих вопросах.
Я бы с удовольствием почитал о рациональном использовании ЗФ, потому что чувствую во многих моментах себя быдлокодером (
Я бы с удовольствием почитал о рациональном использовании ЗФ, потому что чувствую во многих моментах себя быдлокодером (
+1
Кстати, я совершенно случайно пару дней назад искал реализованный каркас, чтобы почерпнуть новые мысли по эффективной разработке на базе ZF. Тут некоторые спрашивали исходники. Ну и пока автор статьи подготавливает их, особо нетерпеливым предлагается «поковырять» довольно свежее opensource решение, естественно на базе ZF: Digitalus CMS.
Порадовало, что в отличии от, например, тяжеловесного Magento, в вышеназванном приложении всё довольно просто и лаконично, без диких цепочек наследований и туманной реализации EAV. Рекомендую обратить внимание на pageBuilder. В общем нетерпеливым продуктивного изучения, а от автора ждём скорого продолжения :)
Порадовало, что в отличии от, например, тяжеловесного Magento, в вышеназванном приложении всё довольно просто и лаконично, без диких цепочек наследований и туманной реализации EAV. Рекомендую обратить внимание на pageBuilder. В общем нетерпеливым продуктивного изучения, а от автора ждём скорого продолжения :)
0
О подробностях БД-части модели хотелось бы отдельную статью. С использованием Zend_Db и разных хитрых типов связей таблиц.
+1
Поддерживаю комментарий, или в ZF довольно слабая (по беглому изучению документации + небольшой опыт использования) работа с моделью, или одно из двух )) Хотелось бы увидеть связи таблиц.
0
жду продолжения.
0
Статья хорошая, спасибо вам.
Немного критики, если позволите :)
Вместо хелперов типа "<?=$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').
+2
Привет, va1en0k! Мы рады, что ты вернулся :)
+2
Несмоторя на то что дочитал до конца (ну это правдо из за того что есть большое желание хорошо въехать в ZF), всякие выражения и названия классов к стиле «упячки», очень отбивали желание продолжать делать это (дочитывать до конца), и хотелось все закрыть и заминусовать… Но несмотря на это, спасибо за статью, и жду следующею, надеюсь без этих выражений…
+3
UFO just landed and posted this here
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'));
Если нужны объяснения — спрашивайте :)
0
стиль повестоваавания поста понра!
продолжайте в том же духе — спасибо (:
продолжайте в том же духе — спасибо (:
+2
Сразу видно влияние Лепры на автора :)
+4
1. перегружать Zend_Action_Controller и Zend_Front_Controller зачастую не нужно. Зенд предлагает для упомянутых задач использовать плагины.
2. Отказываться от Zend_Form не обязательно. Вы не учитываете что помимо генерации верстки это еще и весьма удобный механизм компоновки валидаторов, фильтров, метаданных относящихся к форме. Zend_Form вообще не заставляет вас выводить форму. Лично мне работать с формой как с объектом бывает весьма удобно. Хотя при сложных дизайнерских формах конечно проще будет ее верстку написать руками. Подробнее свою позицию изложил тут.
2. Отказываться от Zend_Form не обязательно. Вы не учитываете что помимо генерации верстки это еще и весьма удобный механизм компоновки валидаторов, фильтров, метаданных относящихся к форме. Zend_Form вообще не заставляет вас выводить форму. Лично мне работать с формой как с объектом бывает весьма удобно. Хотя при сложных дизайнерских формах конечно проще будет ее верстку написать руками. Подробнее свою позицию изложил тут.
0
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 и что-то там нужное мне не работало (или я просто не разобрался, возможно, так)
0
Выше я написал что генерацию верстки можно не делать. Но это не значит что нужно полностью выбросить Zend_Form, в любом случае придется писать какой то свой механизм обработки ошибок к примеру.
А чем пример тяжеловат, ну допустим метку можно вывести еще руками.
а name, value, maxlength это явно не забота верстальщика. И хорошо если эти параметры можно настраивать из одного места.
Если очень хочется можно упростить даже до такого
Проще этого не будет даже если вы будете делать полностью руками.
А чем пример тяжеловат, ну допустим метку можно вывести еще руками.
а name, value, maxlength это явно не забота верстальщика. И хорошо если эти параметры можно настраивать из одного места.
Если очень хочется можно упростить даже до такого
<iinput type="text" name="email" value="<?php echo $this->formRegister->name->getValue(); ?>" maxlength="20" />
Проще этого не будет даже если вы будете делать полностью руками.
0
Так я вот подумали изменил свою точку зрения насчёт того, что статьи типа «написание блогового движка» не нужны. Мне кажется что всё что я читал ранее было написано немного недобросовестно. Всего по чуть чуть и в итоге ничего серьёзного. Вот если кто-то возьмётся написать такую статью, где будет всё грамотно и полно описано, так чтобы придраться не было возможности, то цены такой статье не будет, хотя возможно договоримся)) На пример одного модуля или контроллера рассказать о ЗФ так, чтобы дальше любой другой модуль не вызывал никаких трудностей и при этом чтобы была уверенность, что Зенд используется наиболее эффективно. По-моему это вполне реально написать и многим поможет
0
Вряд ли этот туториал претендует на звание «придраться нет возможности»
В целом считаю в любом объемном труде будет авторский стиль, который другим может не подходить.
В целом считаю в любом объемном труде будет авторский стиль, который другим может не подходить.
0
В отличие от многих авторов подобных туториалов, Padraic Brady реально участвует в разработке ZF, и уж кому, как не ему знать, как эффективно и идеологически правильно использовать данный фреймворк.
0
Я его весьма подробно прорабатывал в свое время. Он хорош, но не идеален, и не совсем для полных новичков. Padraic Brady один из большой команды, со своим мнением, хотя здесь framework.zend.com/community/contributors, о нем почему-то забыли. К примеру в некоторых моментах его подход отличается от подхода Matthew Weier O'Phinney, который является разработчиком ZF еще в большей мере.
0
А я чего-то не понял. Продолжение-то ждать? Или рыдать и колоться самому? :)
0
Sign up to leave a comment.
Zend Framework первой свежести, ч1: зендируем MVC