Comments 56
1. не плохобы выложить какой-нибудь демо проект, что бы проше было понять как работать с фремворком.
2. и еше бы хотелось не разделять по разным директориям папку с фремворком и сайтом тк не у всех свой vps или выделенный хостинг.
даже если не vds или выделенный сервер/хостинг, разделение это не проблема. у меня стоит обычный виртуальный хостинг и cakephp спокойной работает с разными папками.
Где можно посмотреть на пример кода простейшего сайта на этом фреймвоке?
$this->context->lookup('User:SearchEngineModel')->setGenre($condition['genre'])->setYears($condition['year1'], $condition['year2'])->setWords($condition['words'])->setRating($condition['rating'])->setPageNumber($pageNumber);

у меня начинает развиваться боязнь длинных строчек кода, не влезающих в один скролл на расширении 1440x900 :)
А у меня нелюбовь к написанию столбиков кода.

$model->setXXX();
$model->setYYY();
$model->setZZZ(); :)

Имхо, повтор $model N раз совершенно излишен, а такие длинные строчки можно превращать в лесенку. :)
Лучше не в лесенку, а в столбик, в котором $model будет только один раз в начале.
Вроде ZF не навязывает ничего, только удобные компоненты. А как будет выглядеть конечное приложение - дело разработчика.
А вот CakePHP, наоборот, навязывает, зато время разворачивания приложения до готового вида - минимально.
Когда я в последний раз общался с Zend, для показа пользовательской странички по URL /user/news/index надо было создать файл User/News/Controller.php и метод назвать indexAction(), а класс должен был называться User_News_Controller.php :) И, что самое занятное, несколько контроллеров были абсолютно неотличимы по именам. Имхо, это насилие над личностью и привнесение неудобств. :) Возможно, оно каким-то образом решается, я не знаю. Ещё довольно нехорошее впечатление на меня в своё время произвела статья, в которой предлагалось использовать reflection для вызова методов с параметрами. Это что касается Zend.
зенд можно использовать отдельно от его mvc системы - как библиотеку классов
UFO landed and left these words here
> Здорово, всегда приятно услышать про новый framework на PHP.
Мне, извините, не очень. У нас вообще как-то так повелось, что едва ли не каждый писал по своему велосипеду, это неправильно и нехорошо. Symfony очень хорош, на мой взгляд, но в загруженных проектах он лично мне не показался достаточно быстрым. Это чистой воды личное мнение. Ну, как с Propel: хорошая архитектура, неплохая реализация, но тяжело-о...
UFO landed and left these words here
Вижу только один момент, по которому могу не согласиться: он не разрастётся. Нет предпосылок.
Обычное дело. Любой программный продукт, если он живой, со временем начинает обрастать улучшениями,и дополнениями, плагинами, изменениями, патчами, версиями... Этот вряд ли будет исключением.
Если конечно ис
До выхода PHP 6 разве что пакеты. Ядро больше года обкатывалось и на данный момент делает ровно то, что надо. :)
Но, на мой взгляд, основное достоинство этого фреймворка в том, что помимо своих прямых задач он не пытается решать какие-либо ещё. Он не навязывает ни способов обработки запросов пользователя, ни методов работы с СУБД, ни средств работы с ACL; то есть не пытается тягаться с куда более известными и проверенными прикладными библиотеками.
"Вы будете смеятся" ©, но "этого". Вы сказали, что он решает ряд задач и "не пытается решать какие-либо ещё". Хотял бы взглянуть на этот ряд.
Ну ссылка на краткое описание (в т.ч. ряда "этого";-)) есть в тексте поста. Абзац про "ряд задач" оттуда. У меня складывается ощущение, что Вы начали задавать вопросы и требовать доказательств до просмотра ссылок.
Я ознакомился с внушительным материалом, поверьте. Почитал даже ваши "холивары", чтобы иметь представление о вашем подходе. Простите, что начал задавать вопросы; печально, что вас это раздражает. Разрешите откланяться.
> Я ознакомился с внушительным материалом, поверьте.
Верю. Поверьте, я тоже.

> Почитал даже ваши "холивары", чтобы иметь представление о вашем подходе.
У-у-у. Печально.

Вопрос про "ряд задач" был сформулирован так, что у меня сложилось ощущение необходимости переносить все данные с сайта в ответ Вам.
Полностью поддерживаю высказывание. Предлагаю даже называть новые frameworkи YAFами (Yet Another Framework), до тех пор пока не будет доказано, чем именно они выгодно отличаются от конкурентов с мощной поддержкой от создателей и коммьюнити.
Но-овые? :) Забавно.

Но в целом хорошая точка зрения. Мне очень нравится. Я, правда, не воспринимаю другие как "конкурентов", но ведь у нас стереотип, что фреймворк — это несколько тонн кода, гора документации, непредсказуемые поломки и комьюнити, взявшееся неясно откуда за год-полтора до анонса разработки.
Я не говорил о конкуренции. Стереотипов нет. Как нет и хорошего фреймворка. Есть просто неплохие. Есть набор неплохих. ЕОФ (Еще Один Фреймворк) - это заявка на пополнение списка неплохих фреймворков. Для любого разработчика, чтобы определить, стоит ли его помещать в такой список, необходимо определиться с двумя вещами: а) Достоинства и недостатки в сравнении с другими из списка неплохих фреймворков б) Спецефичность данного; идеальные условия использования. Чтобы определиться с этими а и б (говорить буду только за себя): я пробегаю документацию, api, примеры использования (как туториалы и хелловорды, так и список живых проектов, интесивно фреймворк использующие) и так далее. Но, самое главное, я по коммьюнити определяю качество и предметное поле грабель, ограничений, бутылочных горлышек и так далее; и не менее важно - скорость помощи в таких коммьюнити, т.е. буду ли я ковырять все сам (при отсутствии, например, документации и иных сопроводиловок) или смогу прочесть про наступленные грабли или быстро получить помощь. От этого зависит многое.

Представьте себе, что вы вышли на рынок с новым автомобилем. Чтобы найти себе сторонников, необходимо, по-моему, хотя бы описать ТТХ и, естественно, отличия от иных средств передвижения. Я это так себе представляю.
> Я не говорил о конкуренции.
"чем именно они выгодно отличаются от конкурентов" — а о чём Вы говорили?
Если я поправлю на "аналоги" или "чем именно Frontier отличается от других фреймворков из списка неплохих, вы ответите на вопрос"?
С другой стороны. Я действительно считаю, что сюда пришёл делиться с другими разработчиками, на конструктивные вопросы отвечаю и т.п. Но не стоит думать, что я "вышел на рынок" "продавать автомобиль", что смотрю на другие фреймворки как на "конкурентов", ну и всё такое.
Отдельный класс на каждый view, отдельный класс на форму...видимо у нас разные понятия о "тяжелости" ;)
На каждый вью? Ну... Да. Если мы решаем мастерским произволом, что любой вью предоставляет конкретные данные в конкретном виде, то класссов у нас будет по числу представлений. Если же мы берём на вооружение push-view-model, то классов у нас будет значительно меньше, хотя логика по наполнению данными будет размазана между контроллером и видом.
У нас представление это контейнер для данных и идентификатор шаблона. А шаблонизатор (или один из методов applicationController'а) отрисовывает контент по этим данным, применяя логику представления из шаблона, на основе данных от view.
Ну, я и говорю: pull model. Про рендер вью, которым занимается контроллер, не понял.
pull или push здесь значение не имеет. Я имею ввиду, что у нас нет вообще в приложениях классов, типа NewsView, они заменяются классом для конкретного шаблонизатора (например, MacroView) и шаблоном.

ЗЫ: pull вообще можно пропускать к самой модели (сервису, фабрике), минуя контроллер.
В одном из проектов у меня был SmartyView. И шаблоны. Потом показалось неудобно, сделал иначе. На freedom'е это классы, которые наследуются от DomView, вынимают данные и отображаются, и спокойно могут быть использованы как в совокупности, так и по отдельности (для AJAX, например). Не вижу особой и принципиальной разницы. А тяжеловесность для меня — это количество кода, которое надо написать, ну и скорость, с которой это работает.
А тяжеловесность для меня — это количество кода, которое надо написать, ну и скорость, с которой это работает

Вот это меня и удивило - кода получается многовато...
Классов — много. Кода — мало. Но это только потому, что лично мне в данный момент времени так кажется проще и удобнее.
Судя по целям, это хорошая задумка. Единственный недостаток: без нормального руководства польза Frontier и этого поста для посторонних равна нулю. Я почитал документацию к API, но не понял из неё ровным счётом ничего.

В своих проектах я использую набор классов, представляющих из себя то же самое: гибкий MVC-каркас. Я навешиваю на этот каркас в качестве модели, по необходимости, Doctrine, SimpleMySQL или чистый API. Шаблоны делаются на xsl, но пару раз приходилось использовать смарти и чистый PHP.

Мне не нужны плагины (их роль часто играют шаблоны и базовые классы в доктрине) и не нужны генераторы, по скольку, админка делается, обычно, с использованием аякса по давно отработанным шаблонам.

Я так думаю, подобных MVC-"пустышек" тысячи: у каждого разработчика - своя, так почему бы не собрать лучшее из них в одну или несколько библиотек?

Если в Froniter есть интересные идеи - я приянял бы их на вооружение и поделился бы своими, если они есть у меня. Без документации, я не понимаю даже отличие архитектуры Frontier от архитектуры того же Zend'а.
:-) У меня это не совсем "гибкий MVC-каркас". Или ты описание фишек не читал? Насчёт тысяч, кстати, сильно сомневаюсь: очень многие так или иначе завязываются на конкретику с самого начала.

В целом, думаю, имеет смысл пообщаться в приватах или по аське/джабберу.
Кстати, если уж ты это дело посмотрел, то, может, выскажешь мнение для присутствующих здесь? :)
Да, выскажу. Однако, нужно в этом основательно разобраться. Подход интересный, но, как я сказал, не совсем обычный и не совсем стандартный для языка PHP.

То есть, он сложен для понимания, а выбирают, обычно, не то что хорошо, а то что просто. В общем, обдумаю и напишу.
В самом начале поста досадная и смешная двойная очепятка "троды плудов" :)
Only those users with full accounts are able to leave comments. Log in, please.