Комментарии 56
1. не плохобы выложить какой-нибудь демо проект, что бы проше было понять как работать с фремворком.
2. и еше бы хотелось не разделять по разным директориям папку с фремворком и сайтом тк не у всех свой vps или выделенный хостинг.
2. и еше бы хотелось не разделять по разным директориям папку с фремворком и сайтом тк не у всех свой vps или выделенный хостинг.
0
Где можно посмотреть на пример кода простейшего сайта на этом фреймвоке?
+1
Hello world с комментариями на русском подойдёт?
0
Чуть-чуть посложнее, если можно :)
0
Ну, тогда вот:
http://nav.academ.org/freedom/app/engine…
И, собственно, сайтик в работе http://nav.academ.org/freedom/
http://nav.academ.org/freedom/app/engine…
И, собственно, сайтик в работе http://nav.academ.org/freedom/
0
$this->context->lookup('User:SearchEngineModel')->setGenre($condition['genre'])->setYears($condition['year1'], $condition['year2'])->setWords($condition['words'])->setRating($condition['rating'])->setPageNumber($pageNumber);
у меня начинает развиваться боязнь длинных строчек кода, не влезающих в один скролл на расширении 1440x900 :)
у меня начинает развиваться боязнь длинных строчек кода, не влезающих в один скролл на расширении 1440x900 :)
+4
Вроде ZF не навязывает ничего, только удобные компоненты. А как будет выглядеть конечное приложение - дело разработчика.
А вот CakePHP, наоборот, навязывает, зато время разворачивания приложения до готового вида - минимально.
А вот CakePHP, наоборот, навязывает, зато время разворачивания приложения до готового вида - минимально.
0
Когда я в последний раз общался с Zend, для показа пользовательской странички по URL /user/news/index надо было создать файл User/News/Controller.php и метод назвать indexAction(), а класс должен был называться User_News_Controller.php :) И, что самое занятное, несколько контроллеров были абсолютно неотличимы по именам. Имхо, это насилие над личностью и привнесение неудобств. :) Возможно, оно каким-то образом решается, я не знаю. Ещё довольно нехорошее впечатление на меня в своё время произвела статья, в которой предлагалось использовать reflection для вызова методов с параметрами. Это что касается Zend.
0
НЛО прилетело и опубликовало эту надпись здесь
> Здорово, всегда приятно услышать про новый framework на PHP.
Мне, извините, не очень. У нас вообще как-то так повелось, что едва ли не каждый писал по своему велосипеду, это неправильно и нехорошо. Symfony очень хорош, на мой взгляд, но в загруженных проектах он лично мне не показался достаточно быстрым. Это чистой воды личное мнение. Ну, как с Propel: хорошая архитектура, неплохая реализация, но тяжело-о...
Мне, извините, не очень. У нас вообще как-то так повелось, что едва ли не каждый писал по своему велосипеду, это неправильно и нехорошо. Symfony очень хорош, на мой взгляд, но в загруженных проектах он лично мне не показался достаточно быстрым. Это чистой воды личное мнение. Ну, как с Propel: хорошая архитектура, неплохая реализация, но тяжело-о...
0
НЛО прилетело и опубликовало эту надпись здесь
Вижу только один момент, по которому могу не согласиться: он не разрастётся. Нет предпосылок.
-1
Не верю! (с) :)
0
:-) Какие ваши аргументы, гражданин начальник?
0
Обычное дело. Любой программный продукт, если он живой, со временем начинает обрастать улучшениями,и дополнениями, плагинами, изменениями, патчами, версиями... Этот вряд ли будет исключением.
Если конечно ис
Если конечно ис
0
Но, на мой взгляд, основное достоинство этого фреймворка в том, что помимо своих прямых задач он не пытается решать какие-либо ещё. Он не навязывает ни способов обработки запросов пользователя, ни методов работы с СУБД, ни средств работы с ACL; то есть не пытается тягаться с куда более известными и проверенными прикладными библиотеками.
0
Назовите, пожалуйста, "прямые задачи" фрэймворка.
0
Какого?
0
"Вы будете смеятся" ©, но "этого". Вы сказали, что он решает ряд задач и "не пытается решать какие-либо ещё". Хотял бы взглянуть на этот ряд.
0
Ну ссылка на краткое описание (в т.ч. ряда "этого";-)) есть в тексте поста. Абзац про "ряд задач" оттуда. У меня складывается ощущение, что Вы начали задавать вопросы и требовать доказательств до просмотра ссылок.
0
Я ознакомился с внушительным материалом, поверьте. Почитал даже ваши "холивары", чтобы иметь представление о вашем подходе. Простите, что начал задавать вопросы; печально, что вас это раздражает. Разрешите откланяться.
-2
> Я ознакомился с внушительным материалом, поверьте.
Верю. Поверьте, я тоже.
> Почитал даже ваши "холивары", чтобы иметь представление о вашем подходе.
У-у-у. Печально.
Вопрос про "ряд задач" был сформулирован так, что у меня сложилось ощущение необходимости переносить все данные с сайта в ответ Вам.
Верю. Поверьте, я тоже.
> Почитал даже ваши "холивары", чтобы иметь представление о вашем подходе.
У-у-у. Печально.
Вопрос про "ряд задач" был сформулирован так, что у меня сложилось ощущение необходимости переносить все данные с сайта в ответ Вам.
-1
Полностью поддерживаю высказывание. Предлагаю даже называть новые frameworkи YAFами (Yet Another Framework), до тех пор пока не будет доказано, чем именно они выгодно отличаются от конкурентов с мощной поддержкой от создателей и коммьюнити.
0
Но-овые? :) Забавно.
Но в целом хорошая точка зрения. Мне очень нравится. Я, правда, не воспринимаю другие как "конкурентов", но ведь у нас стереотип, что фреймворк это несколько тонн кода, гора документации, непредсказуемые поломки и комьюнити, взявшееся неясно откуда за год-полтора до анонса разработки.
Но в целом хорошая точка зрения. Мне очень нравится. Я, правда, не воспринимаю другие как "конкурентов", но ведь у нас стереотип, что фреймворк это несколько тонн кода, гора документации, непредсказуемые поломки и комьюнити, взявшееся неясно откуда за год-полтора до анонса разработки.
0
Я не говорил о конкуренции. Стереотипов нет. Как нет и хорошего фреймворка. Есть просто неплохие. Есть набор неплохих. ЕОФ (Еще Один Фреймворк) - это заявка на пополнение списка неплохих фреймворков. Для любого разработчика, чтобы определить, стоит ли его помещать в такой список, необходимо определиться с двумя вещами: а) Достоинства и недостатки в сравнении с другими из списка неплохих фреймворков б) Спецефичность данного; идеальные условия использования. Чтобы определиться с этими а и б (говорить буду только за себя): я пробегаю документацию, api, примеры использования (как туториалы и хелловорды, так и список живых проектов, интесивно фреймворк использующие) и так далее. Но, самое главное, я по коммьюнити определяю качество и предметное поле грабель, ограничений, бутылочных горлышек и так далее; и не менее важно - скорость помощи в таких коммьюнити, т.е. буду ли я ковырять все сам (при отсутствии, например, документации и иных сопроводиловок) или смогу прочесть про наступленные грабли или быстро получить помощь. От этого зависит многое.
Представьте себе, что вы вышли на рынок с новым автомобилем. Чтобы найти себе сторонников, необходимо, по-моему, хотя бы описать ТТХ и, естественно, отличия от иных средств передвижения. Я это так себе представляю.
Представьте себе, что вы вышли на рынок с новым автомобилем. Чтобы найти себе сторонников, необходимо, по-моему, хотя бы описать ТТХ и, естественно, отличия от иных средств передвижения. Я это так себе представляю.
0
> Я не говорил о конкуренции.
"чем именно они выгодно отличаются от конкурентов" а о чём Вы говорили?
"чем именно они выгодно отличаются от конкурентов" а о чём Вы говорили?
0
Если я поправлю на "аналоги" или "чем именно Frontier отличается от других фреймворков из списка неплохих, вы ответите на вопрос"?
0
Да нету у него аналогов. Зачем я его и делал.
0
С другой стороны. Я действительно считаю, что сюда пришёл делиться с другими разработчиками, на конструктивные вопросы отвечаю и т.п. Но не стоит думать, что я "вышел на рынок" "продавать автомобиль", что смотрю на другие фреймворки как на "конкурентов", ну и всё такое.
0
Отдельный класс на каждый view, отдельный класс на форму...видимо у нас разные понятия о "тяжелости" ;)
0
На каждый вью? Ну... Да. Если мы решаем мастерским произволом, что любой вью предоставляет конкретные данные в конкретном виде, то класссов у нас будет по числу представлений. Если же мы берём на вооружение push-view-model, то классов у нас будет значительно меньше, хотя логика по наполнению данными будет размазана между контроллером и видом.
0
У нас представление это контейнер для данных и идентификатор шаблона. А шаблонизатор (или один из методов applicationController'а) отрисовывает контент по этим данным, применяя логику представления из шаблона, на основе данных от view.
0
Ну, я и говорю: pull model. Про рендер вью, которым занимается контроллер, не понял.
0
pull или push здесь значение не имеет. Я имею ввиду, что у нас нет вообще в приложениях классов, типа NewsView, они заменяются классом для конкретного шаблонизатора (например, MacroView) и шаблоном.
ЗЫ: pull вообще можно пропускать к самой модели (сервису, фабрике), минуя контроллер.
ЗЫ: pull вообще можно пропускать к самой модели (сервису, фабрике), минуя контроллер.
0
В одном из проектов у меня был SmartyView. И шаблоны. Потом показалось неудобно, сделал иначе. На freedom'е это классы, которые наследуются от DomView, вынимают данные и отображаются, и спокойно могут быть использованы как в совокупности, так и по отдельности (для AJAX, например). Не вижу особой и принципиальной разницы. А тяжеловесность для меня это количество кода, которое надо написать, ну и скорость, с которой это работает.
0
Судя по целям, это хорошая задумка. Единственный недостаток: без нормального руководства польза Frontier и этого поста для посторонних равна нулю. Я почитал документацию к API, но не понял из неё ровным счётом ничего.
В своих проектах я использую набор классов, представляющих из себя то же самое: гибкий MVC-каркас. Я навешиваю на этот каркас в качестве модели, по необходимости, Doctrine, SimpleMySQL или чистый API. Шаблоны делаются на xsl, но пару раз приходилось использовать смарти и чистый PHP.
Мне не нужны плагины (их роль часто играют шаблоны и базовые классы в доктрине) и не нужны генераторы, по скольку, админка делается, обычно, с использованием аякса по давно отработанным шаблонам.
Я так думаю, подобных MVC-"пустышек" тысячи: у каждого разработчика - своя, так почему бы не собрать лучшее из них в одну или несколько библиотек?
Если в Froniter есть интересные идеи - я приянял бы их на вооружение и поделился бы своими, если они есть у меня. Без документации, я не понимаю даже отличие архитектуры Frontier от архитектуры того же Zend'а.
В своих проектах я использую набор классов, представляющих из себя то же самое: гибкий MVC-каркас. Я навешиваю на этот каркас в качестве модели, по необходимости, Doctrine, SimpleMySQL или чистый API. Шаблоны делаются на xsl, но пару раз приходилось использовать смарти и чистый PHP.
Мне не нужны плагины (их роль часто играют шаблоны и базовые классы в доктрине) и не нужны генераторы, по скольку, админка делается, обычно, с использованием аякса по давно отработанным шаблонам.
Я так думаю, подобных MVC-"пустышек" тысячи: у каждого разработчика - своя, так почему бы не собрать лучшее из них в одну или несколько библиотек?
Если в Froniter есть интересные идеи - я приянял бы их на вооружение и поделился бы своими, если они есть у меня. Без документации, я не понимаю даже отличие архитектуры Frontier от архитектуры того же Zend'а.
0
:-) У меня это не совсем "гибкий MVC-каркас". Или ты описание фишек не читал? Насчёт тысяч, кстати, сильно сомневаюсь: очень многие так или иначе завязываются на конкретику с самого начала.
В целом, думаю, имеет смысл пообщаться в приватах или по аське/джабберу.
В целом, думаю, имеет смысл пообщаться в приватах или по аське/джабберу.
0
Кстати, если уж ты это дело посмотрел, то, может, выскажешь мнение для присутствующих здесь? :)
0
В самом начале поста досадная и смешная двойная очепятка "троды плудов" :)
0
ресурсы легли все
народ интересуется =;)
народ интересуется =;)
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
frontier — фреймворк для php 5.1