stanis30 мар 2008 в 23:08

frontier — фреймворк для php 5.1

1 мин

889

PHP *

+19

Комментарии 56

informa 31 мар 2008 в 01:20

1. не плохобы выложить какой-нибудь демо проект, что бы проше было понять как работать с фремворком.
2. и еше бы хотелось не разделять по разным директориям папку с фремворком и сайтом тк не у всех свой vps или выделенный хостинг.

stanis 31 мар 2008 в 01:21

1. Это будет в ближайшее время.
2. Хм. А зачем разделять?

quard 31 мар 2008 в 07:41

даже если не vds или выделенный сервер/хостинг, разделение это не проблема. у меня стоит обычный виртуальный хостинг и cakephp спокойной работает с разными папками.

stanis 31 мар 2008 в 11:42

Откуда вообще вопрос про папки и сервера? :)

gzigzigzi 31 мар 2008 в 01:22

Где можно посмотреть на пример кода простейшего сайта на этом фреймвоке?

stanis 31 мар 2008 в 01:23

Hello world с комментариями на русском подойдёт?

absolvo 31 мар 2008 в 02:22

Чуть-чуть посложнее, если можно :)

stanis 31 мар 2008 в 02:39

Ну, тогда вот:

http://nav.academ.org/freedom/app/engine…

И, собственно, сайтик в работе http://nav.academ.org/freedom/

crizis 31 мар 2008 в 08:54

$this->context->lookup('User:SearchEngineModel')->setGenre($condition['genre'])->setYears($condition['year1'], $condition['year2'])->setWords($condition['words'])->setRating($condition['rating'])->setPageNumber($pageNumber);

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

stanis 31 мар 2008 в 11:24

А у меня нелюбовь к написанию столбиков кода.

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

Имхо, повтор $model N раз совершенно излишен, а такие длинные строчки можно превращать в лесенку. :)

besisland 1 апр 2008 в 02:12

Лучше не в лесенку, а в столбик, в котором $model будет только один раз в начале.

stanis 1 апр 2008 в 08:06

Да хоть в ёлочку. Это уже от code guidelines зависит.

avenu 31 мар 2008 в 11:26

Вроде ZF не навязывает ничего, только удобные компоненты. А как будет выглядеть конечное приложение - дело разработчика.
А вот CakePHP, наоборот, навязывает, зато время разворачивания приложения до готового вида - минимально.

stanis 31 мар 2008 в 11:37

Когда я в последний раз общался с Zend, для показа пользовательской странички по URL /user/news/index надо было создать файл User/News/Controller.php и метод назвать indexAction(), а класс должен был называться User_News_Controller.php :) И, что самое занятное, несколько контроллеров были абсолютно неотличимы по именам. Имхо, это насилие над личностью и привнесение неудобств. :) Возможно, оно каким-то образом решается, я не знаю. Ещё довольно нехорошее впечатление на меня в своё время произвела статья, в которой предлагалось использовать reflection для вызова методов с параметрами. Это что касается Zend.

mrsombre 1 апр 2008 в 03:17

зенд можно использовать отдельно от его mvc системы - как библиотеку классов

stanis 1 апр 2008 в 08:16

Можно. А есть ещё классный фреймворк — PEAR.

НЛО прилетело и опубликовало эту надпись здесь

stanis 31 мар 2008 в 11:41

> Здорово, всегда приятно услышать про новый framework на PHP.
Мне, извините, не очень. У нас вообще как-то так повелось, что едва ли не каждый писал по своему велосипеду, это неправильно и нехорошо. Symfony очень хорош, на мой взгляд, но в загруженных проектах он лично мне не показался достаточно быстрым. Это чистой воды личное мнение. Ну, как с Propel: хорошая архитектура, неплохая реализация, но тяжело-о...

НЛО прилетело и опубликовало эту надпись здесь

stanis 31 мар 2008 в 12:13

Вижу только один момент, по которому могу не согласиться: он не разрастётся. Нет предпосылок.

beshbarmak 31 мар 2008 в 19:11

Не верю! (с) :)

stanis 31 мар 2008 в 19:19

:-) Какие ваши аргументы, гражданин начальник?

beshbarmak 31 мар 2008 в 20:15

Обычное дело. Любой программный продукт, если он живой, со временем начинает обрастать улучшениями,и дополнениями, плагинами, изменениями, патчами, версиями... Этот вряд ли будет исключением.
Если конечно ис

stanis 31 мар 2008 в 20:23

До выхода PHP 6 разве что пакеты. Ядро больше года обкатывалось и на данный момент делает ровно то, что надо. :)

stanis 31 мар 2008 в 15:33

Но, на мой взгляд, основное достоинство этого фреймворка в том, что помимо своих прямых задач он не пытается решать какие-либо ещё. Он не навязывает ни способов обработки запросов пользователя, ни методов работы с СУБД, ни средств работы с ACL; то есть не пытается тягаться с куда более известными и проверенными прикладными библиотеками.

ktulhu 31 мар 2008 в 20:07

Назовите, пожалуйста, "прямые задачи" фрэймворка.

stanis 31 мар 2008 в 20:11

Какого?

ktulhu 31 мар 2008 в 21:28

"Вы будете смеятся" ©, но "этого". Вы сказали, что он решает ряд задач и "не пытается решать какие-либо ещё". Хотял бы взглянуть на этот ряд.

stanis 31 мар 2008 в 21:40

Ну ссылка на краткое описание (в т.ч. ряда "этого";-)) есть в тексте поста. Абзац про "ряд задач" оттуда. У меня складывается ощущение, что Вы начали задавать вопросы и требовать доказательств до просмотра ссылок.

ktulhu 31 мар 2008 в 22:57

Я ознакомился с внушительным материалом, поверьте. Почитал даже ваши "холивары", чтобы иметь представление о вашем подходе. Простите, что начал задавать вопросы; печально, что вас это раздражает. Разрешите откланяться.

stanis 31 мар 2008 в 23:01

> Я ознакомился с внушительным материалом, поверьте.
Верю. Поверьте, я тоже.

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

Вопрос про "ряд задач" был сформулирован так, что у меня сложилось ощущение необходимости переносить все данные с сайта в ответ Вам.

ktulhu 31 мар 2008 в 20:02

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

stanis 31 мар 2008 в 20:10

Но-овые? :) Забавно.

Но в целом хорошая точка зрения. Мне очень нравится. Я, правда, не воспринимаю другие как "конкурентов", но ведь у нас стереотип, что фреймворк — это несколько тонн кода, гора документации, непредсказуемые поломки и комьюнити, взявшееся неясно откуда за год-полтора до анонса разработки.

ktulhu 31 мар 2008 в 21:26

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

Представьте себе, что вы вышли на рынок с новым автомобилем. Чтобы найти себе сторонников, необходимо, по-моему, хотя бы описать ТТХ и, естественно, отличия от иных средств передвижения. Я это так себе представляю.

stanis 31 мар 2008 в 21:37

> Я не говорил о конкуренции.
"чем именно они выгодно отличаются от конкурентов" — а о чём Вы говорили?

ktulhu 31 мар 2008 в 22:52

Если я поправлю на "аналоги" или "чем именно Frontier отличается от других фреймворков из списка неплохих, вы ответите на вопрос"?

stanis 31 мар 2008 в 23:02

Да нету у него аналогов. Зачем я его и делал.

stanis 1 апр 2008 в 00:12

С другой стороны. Я действительно считаю, что сюда пришёл делиться с другими разработчиками, на конструктивные вопросы отвечаю и т.п. Но не стоит думать, что я "вышел на рынок" "продавать автомобиль", что смотрю на другие фреймворки как на "конкурентов", ну и всё такое.

korchasa 31 мар 2008 в 11:28

Отдельный класс на каждый view, отдельный класс на форму...видимо у нас разные понятия о "тяжелости" ;)

stanis 31 мар 2008 в 11:39

На каждый вью? Ну... Да. Если мы решаем мастерским произволом, что любой вью предоставляет конкретные данные в конкретном виде, то класссов у нас будет по числу представлений. Если же мы берём на вооружение push-view-model, то классов у нас будет значительно меньше, хотя логика по наполнению данными будет размазана между контроллером и видом.

korchasa 31 мар 2008 в 11:55

У нас представление это контейнер для данных и идентификатор шаблона. А шаблонизатор (или один из методов applicationController'а) отрисовывает контент по этим данным, применяя логику представления из шаблона, на основе данных от view.

stanis 31 мар 2008 в 11:59

Ну, я и говорю: pull model. Про рендер вью, которым занимается контроллер, не понял.

korchasa 31 мар 2008 в 12:07

pull или push здесь значение не имеет. Я имею ввиду, что у нас нет вообще в приложениях классов, типа NewsView, они заменяются классом для конкретного шаблонизатора (например, MacroView) и шаблоном.

ЗЫ: pull вообще можно пропускать к самой модели (сервису, фабрике), минуя контроллер.

stanis 31 мар 2008 в 12:11

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

korchasa 31 мар 2008 в 12:24

А тяжеловесность для меня — это количество кода, которое надо написать, ну и скорость, с которой это работает

Вот это меня и удивило - кода получается многовато...

stanis 31 мар 2008 в 12:28

Классов — много. Кода — мало. Но это только потому, что лично мне в данный момент времени так кажется проще и удобнее.

gzigzigzi 31 мар 2008 в 17:48

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

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

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

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

Если в Froniter есть интересные идеи - я приянял бы их на вооружение и поделился бы своими, если они есть у меня. Без документации, я не понимаю даже отличие архитектуры Frontier от архитектуры того же Zend'а.

stanis 31 мар 2008 в 18:25

:-) У меня это не совсем "гибкий MVC-каркас". Или ты описание фишек не читал? Насчёт тысяч, кстати, сильно сомневаюсь: очень многие так или иначе завязываются на конкретику с самого начала.

В целом, думаю, имеет смысл пообщаться в приватах или по аське/джабберу.

stanis 1 апр 2008 в 00:40

Кстати, если уж ты это дело посмотрел, то, может, выскажешь мнение для присутствующих здесь? :)

gzigzigzi 1 апр 2008 в 01:11

Да, выскажу. Однако, нужно в этом основательно разобраться. Подход интересный, но, как я сказал, не совсем обычный и не совсем стандартный для языка PHP.

То есть, он сложен для понимания, а выбирают, обычно, не то что хорошо, а то что просто. В общем, обдумаю и напишу.