Pull to refresh

Comments 234

За что минусуем? Сказать просто лень или же просто троллим?
Минусование не троллинг, ответить то некому) И флейма не выйдет.
Ну скажем так на На фимфони я не писал и не сталкивался с ним, мне нравится CodeIgniter. Но все что ты написалв посте да же реализация локализации мне не по душе. Да и если честно ты обзор то и не сделал, это так капля в море возможностей фреймыврка, поэтому и рассуждать то не о чем, а нужна документация опять же CI тут на высоте.
Во первых, очень трудно читать все то, что вы написали. Слишком огромное количество ошибок в тектсе.

Если Вам не нравится реализация того или иного, в том или ином — это не значит, что она (реализация) не имеет место быть.

Обзор я тоже не делал, читайте внимательнее заголовок. А обсуждать… хм, видимо обсуждать тут нечего только Вам, т.к. в данном топике идут довольно таки оживленные дискуссии и беседы.

Каков итог? Вы — тролль.
Итог в обратном, а опечатки признаю, но смысл понятен и с ними. Второй абзац в твоем комменте вообще не понял, ты о чем? И в отличие от тебя я никого не минусую, так что троль тут не я.
При случае взгляни на CakePHP.
У кейка не только неплохая документация, но и мощное сообщество, гугл-группы, irc-канал и дофига блогов.
А умеет все то же, что и симфони, если не больше (с симфони, к сожалению, не знаком близко)
А он разве есть для PHP5?
А это настолько важно?
Ну, это только субъективное мнение. Объективно, если фреймворк расширяемый и не тесно связанный — нет почти никакой разницы, PHP4 у него внутри или PHP5.
Хотите объективизма? Запросто. Даже если фреймворк не выносит никакого функционала в глобально видимые функции, то он в любом случае использует объекты, а эти объекты вполне объективно заставят изменить уровень сообщений об ошибках, т.к. используют другое ключевое слово для определения полей. В случае же новичков на проекте я (таки субъективно) предпочитаю держать этот уровень не ниже E_ALL.
Ну, и у меня E_ALL. Но как-бы CodeIgniter. А у него совместимость с PHP4.
Ну вот видите. И вообще, в чём глобальный смысл в конце 2008-го года обеспечивать поддержку PHP4, когда не за горами уже PHP6? Нет, я, конечно, до сих пор сталкиваюсь с базой старого кода на PHP4, бывает, но это код начала столетия.
На хостингах бывает установлен PHP4 и нет PHP5. Совсем недавно воевал по этому поводу. У местного(регионального) хостера — только PHP4. Что делать прикажете? К другому хостеру переезжать — не получится, с местных сайтов трафик бесплатен для местных пользователей.
Ну как я могу Вам что-то приказать? Я бы стал узнавать, отчего так, и нельзя ли ситуацию изменить к общей выгоде.
UFO landed and left these words here
У них оно «Всё успешно работает и менять устоявшиеся настройки и ПО мы не собираемся, прежде всего из-за возможности „сломать“ сайты других клиентов». Короче, полная фигня…
Да не совсем фигня, их резоны я прекрасно понимаю. Но отчего, извините, не повесить PHP5 на другое расширение обрабатываемых файлов? На 'php5', к примеру? Так ничего не сломается.

С другой стороны, такие админы их устраивают. Они даже за деньги не хотят менять конфигурацию даже на одном виртуальном хосте? Ну тогда тут кто-то уже предложил решение: выкупить у них в монопольное пользование один из серверов.
А иногда на «хостинге» нет PHP. Значит, ты будешь всех к HTML склонять?)
Чукча не читатель, чукча писатель…

Альтернатив хостингу с PHP4 в том регионе о котором я писал — нет. Провайдер-монополист не ставит себе на коллокэйшен сервера. Заказчику вообще всё равно относительно версий PHP — он знает лишь только то, что за счёт нетарифицируемого трафика народу больше в магазине покупает. Сразу после переноса магазина этому хостеру месячный оборот вырос на ~40%. Вот идите и убеждайте его, что ему не нужен этот хостинг…
И у этого провайдера даже VDS/DS нету? о_О
Магазин продуктовый.
А за что минусуете-то?
Для меня смысла нет, но бывают клиенты, которым ну очень надо.
Новый проект ну сто процентов на PHP4? Знаете, меня смущает Ваша готовность браться за проекты, которые уже в ближайшем будущем будет «ну очень» сложно поддерживать. Найдут очередную уязвимость в этом трупе — Вы самолично будете её устранять?
Так почему новый? Бывает, надо и трупы шевелить…
Так для чего старый переводить на новую версию фреймворка? Это же синонимично его полной переделке, следовательно, написанию реализации с нуля (с использованием наработанных знаний и, видимо, существующего кода)? Чаще всего фреймворк от версии к версии всего лишь расширяет функциональность.
Иногда нет времени переписывать часть на PHP4, но надо написать новый, допустим, модуль. На PHP5.
> Иногда нет времени переписывать часть на PHP4
Какую часть?..

> но надо написать новый, допустим, модуль. На PHP5.
А зачем плодить зоопарк?
Существующую часть. Зоопарк можно конечно и не плодить :)
Что касается других разниц, то есть минимум ещё одна, вполне объективная. В движке имеется куча изменений, которые стоит учитывать. В частности, я страшно не люблю прямых деклараций возврата или передачи по ссылке.
Да, он и 4 и 5 поддерживает.
Рекомендую сразу ставить 1.2 RC3 (скоро уже будет релиз), там очень много крутых фич, которые в stable (1.1) отсутствуют.

RC3 уже достаточно стабилен и малоглючен.
У меня не те задачи, мои полностью покрываются собственным микроядром на событиях и интерфейсах. Однако за рекомендацию спасибо.
Будьте добры, покажите свое микроядро, ну или расскажите об идеях лежащих в основе.
Есть, он полностью поддерживает PHP 5, просто исходный код совместим с PHP4. Я например все свои классы в нем в PHP5 стиле оформляю и доволен.
Неплохая документация? В 1.2 она стала настолько лучше 1.1?
Кому как.

Сейчас есть book.cakephp.org, чтения которого в совокупности с выполнением blog tutorial дня за два делает из тебя крутого кейкера :)

Конечно, остается много специфичных вопросов (например, как построить запрос с использованием функций БД), но ответ на них за пять секунд находится в гугле или на IRC.

Кстати, обращайтесь, если что, я довольно неплохо кейк знаю.
Ну, я тоже в 1.1 неплохо разбирался :) За предложение спасибо.
А еще лучше прочитать книгу Девида Голдинга о кейке, очень советую.
У CakePHP неплохая документация? Тогда у Symfony она великолепна :-) Что-что, а документация всегда была слабой стороной кейка.
Хмм, как говорил один мой знакомый салат, «Пойду гляну, что там за праздник».
Ну, нормальная вроде. Все, что надо — есть, даже пара-тройка туториалов.
Не сказал бы, что у кейка сейчас сильно хуже. Развиваются, документируются.
А у него есть нечто наподобие Admin Generator? (scaffolding)
Скаффолдинг есть, вроде нормальный даже, и есть генератор необходимого барахла на основе данных из БД (генерит контроллеры, вьюшки и модели, чтобы самому можно было потом править). Но, если честно, я не пользовался никогда.
Мне кажется, Zend делает все остальные php-фреймворки с большим отрывом. Он изначально ориентирован на PHP 5. Поэтому функционально-объектной солянки в нем нет, а это огромное преимущество перед другими.
Да, поддержка php4 добавляет гадости в код. В кейк-2 есть планы от нее отказаться. Мечты, мечты…
Она добавляет гадости, в основном, в код фреймворка, в который лезть хотеться не должно.

Кстати, в Cake 1.1 я туда лез очень часто. Особенно когда начал разбираться с ORM.
Это спорный вопрос. Мне кажется, лучше знать как что работает.
Знать и лезть по любому поводу — разные вещи.
А что значит лезть по любому поводу? Конечно, ни в коем случае нельзя править уже написанный официальный код(я не могу придумать, когда такое необходимо), но когда, например, нужно наследовать существующий абстрактнай класс, то, не зная, как устроен этот самый класс ничего толкового не получится. Это только один вариант из многих возможных.
Ну вот, например, надо нам использовать некий класс… лезем в документацию. Делаем как там — не работает. Что мы делаем? Лезем в код смотреть как там и что.

При хорошей документации в код лезть, если не хочется, не придётся.
Иногда проще открыть тот самый класс чем икать его в доке и искать нужный абзац(а т. к. человек по натуре ленивый, читать все ему будет лень).
Это хорошо, если класс с прстой логикой. А если нет?
Потребность лезть в код, чтобы понять нюансы поведения фреймворка — это вердикт фреймворку.

Имхо, разумеется.
и при этом вы говорите что используете свое микроядро? наверное там вы знаете каждую строчку и если что то не так знаете где искать ошибку?
Вообще не понимаю, где здесь противоречие. В чём оно видится Вам?
Согласен. В случае с JS могу сказать, что я не лазаю в код jQuery, т.к. есть дока и все что в ней написано работает так, как написано. Кроме разве что обязательной простановки display:block при использовании метода animate и иже с ним, это не задокументировано. Но в код я опять же не лез.

Поэтому если для понимания механизмов приходится ползти в движок — это хреновый движок. Вам же не мешает пользоваться автомобилем незнание его устройства ;) и вообще, как писал Д. Котеров в своей древней книге РНР4 — «Если класс позволяет пользоваться собой без необходимости понимать, как он работает — этот класс хорош.»
Ну вот у меня проблема времени на написание документации стоит очень остро, поэтому ограничиваюсь «говорящими» именами и API-документацией. Но это временно. :-)
Про ядро и речь, для пользователя, к счастью, это прозрачно.

В 1.2 я тоже частенько бегаю глянуть код. Они все-таки развиваются достаточно быстро, дописывают всяких фич, и документаторы просто не успевают. Например, я до сих пор не уверен, что документирован сверхполезный атрибут хелпера $form->select — 'multiple' => 'checkbox'. Ну и еще там всякое.

А еще последние кейки умеют делать JOIN таблиц из разных БД :)
Исключительно на программном уровне.
Ну вот… а говорите документация хорошая… значит всё так и осталось, как было в 1.1.
По базовым вещам — хорошая.
По допфункционалу или фичам в разработке — да, блоги, гугл и IRC.
В общем как-то не испытывал недостатка в чтиве никогда.

Одно дело — если вы для себя программируете. Другое — если надо быстро посадить на проект 10 новичков, не знакомых с фреймворком.
то есть лучше их посадить на говнофреймворк, который они выучат за неделю, чем на нормальный, но который учить месяц??
Почему сразу говно- и нормальный? Разве нет достаточно хороших фреймворков с отличной документацией?
для контраста =) «хороший фреймворк с отличной документацией» — это видимо CodeIgniter, у которого нет ассоциаций и валидации моделей (к примеру)??
Слово «достаточно» вы намеренно выкинули? ;)
вот тут то и хочется читабильный код, а php5 этому способствует.
То есть код данного фреймворка не накладывает ограничения на уровень сообщений об ошибках? Вы шутите.
Назовите мне хотя бы один фреймворк на PHP (версия не важна), ориентированный на функциональное программирование.
Я сказал, что все фреймворки кроме Зенда ориентированы на функциональное программирование? Вы уверены, что внимательно прочитали мой комментарий? Может быть, вы хотите меня в чем-то подловить? Скорее всего, в незнании php. Вам это удалось
Нет, Вы сказали, что «функционально-объектной солянки в нем нет». Мне стало интересно, где есть (хотя бы) функционально-объектная солянка.
Последний кейк который я видел — cakephp 1.1. Как раз то, о чем я говорил. С вашего позволения релиз кандидат скачивать не буду, хотя вряд ли что-то там серьезно изменилось в лучшую сторону.
Недавно пришлось еще столкнуться с друпалом — то же самое. Хотя неясно, конечно, что это: CMS или CMF.
а зенд фреймворк какой последний качали, версии 0.3?? да хотя и зачем, что там могло измениться.
а мне кажется что symfony тоже изначально ориентирован на php5. Ориентация на версию не так важна. Важно сердце (ядро). Сама семантика фреймворка.

IMHO: Zend Framework и Symfony немножко разные в том плане, что Zend более компонентый тогда как Symfony лучше юзать полноценно полностью (хотя сейчас они уже развивают не только как целостная структура mvc но и как компонентный фреймворк), считаю справедливым сказать что Symfony && Zend могут прекрасно взаимодополнять друг друга, это не исключающие вещи))) в Symfony даже спец брадж для Zend framework
Используй Source Code Highlighter.
А по теме, мне кажется, что ты рано начал сравнивать, два дня, это хоть и опыт, но маленький =]
Вообще да. За пару дней от привычек, оставшихся от другого фреймворка не избавиться.
Я не совсем сравнивал, а описывал свои ощущения =)
А вы точно используете последнюю стабильную версию Symfony? Просто формы там сделаны гораздо удобнее чем в 1.0. По образу и подобию Django делали. В Zend есть аналог — Zend Form

А документация на самом деле отличная.Ну или покажите примеры фреймворков с лучшей документацией. Мне на ум ничего кроме CodeIgniter не приходит.
У меня 1.1.0, а формы строил по той же документации, что на сайте.

Что касается лучшей документированности, то опять же — Zend Framework.
> Во первых, сразу хотелось бы отметить, что документация у этого фреймворка скудная
Зато symfony славится своим сильным комьюнити.
> Как вы смогли догадатся при переключении культуры пользователя (проще говоря при смена языка) symfony парсит xml'ный файлик general.ru.xml на наличие перевода для каждой фразы.
> В целом мне нравится такой подход… тем более когда процессорные xml парсеры не за горами. Все это работает действительно быстро (при относительно не большом количестве статичного текста, больше я пока не пробовал).
Вы неправы. Симфония работает с xml только на этапе первой инициализации, после этого локализация кладется в сериализованный массив. Скорость работы, как сами понимаете, от этого только возрастает.
> Опробовал я и «их» хелпер для построение форм.
Не используйте старую версию. Уже с 1.1 в симфонии поддерживается чудная работа с формами.
Посмотрите хотя бы последнюю новость на сайте.
Можно прямую ссылку на документацию по построению форм новыми методами?
UFO landed and left these words here
вот я тоже раньше так думал, но когда приходилось писать большие по размеру формы на ZF — этот код очень уж громоздко смотрелся в купе со всеми необходимыми валидаторами и проч. опциями. В итоге понял, что простые текствовые поля формы лучше выносить в «простой» файл)
Гораздо удобнее писать ini файл для этого, чем писать 20 строк вот такого вот:
$this->addField(array(«name»=>«lalal»,«type»=>«textbox»,«require»=>true))
UFO landed and left these words here
нет, только вот в таком случае более рутинные вещи будут описаны в ini-файле(названия полей, фильтры, базовые валидаторы), а кастомные валидаторы, дефолтные значения, опции для selextbox — в php файле.

Как правило, готовые INI-файлы редактируются крайне редко. Большая часть работы возлагается на работу с PHP кодом формы.

+ INI файлы более удобны и наглядны для описания форм. Весь необходимый функционал расширяется за счёт PHP кода.

Не стоит искать панацею, универсальных способов не существует — нужно использовать это там, где это действительно удобно и необходимо.
UFO landed and left these words here
Вот это как на уровень менее наглядно))
при всём при этот тут нету вполне стандартных валидаторов, «pattern» это далеко не все, что нужно.
Вот где например валидатор на существование такого логина?

Как насчёт вот таких вещей?

$this->country->setMultiOptions($countrys);
$this->state->setMultiOptions($states);

$this->gender->setMultiOptions($genders);

$this->age_range->setMultiOptions($ageRanges);

$this->upassword->addValidator(new Validate_PasswordsMatch);

$this->email->addValidator(new Validate_AlreadyExistsEmailEdit)
->addValidator(new Validate_EmailConfirmation);

$this->paypal->addValidator(new Validate_PaypalConfirmation);

Когда все это добавиться — будет крайне неудобно что-то редактировать.
UFO landed and left these words here
нет, не в админке) я и вовсе не юзаю генератор форм(через декоратор) в скриптах вида, только простые view helpers:
<?=$this->formSelect($this->form->country->getName(), $this->form->country->getValue(), $this->form->country->getAttribs(), $this->form->country->getMultiOptions());?>
Вот такой код выдаст selextbox со списком стран
UFO landed and left these words here
ну, как видишь, у каждого своя методика. Кому-то это удобно, а кому-то нет
Хм, пытаетесь развить холивар? ;)
Вот встречный вопрос: зачем придумали PHP, есть же C++? Нельзя что ли написать:
#include
#include

int main(){
cout
я не понял, где в видите описание форм на yaml
На yaml пишется схема бд.
На yaml можно будет описывать формы в 1.2
Огромное спасибо, почитаю. Завтра.
По поводу локлизации, в последних версиях ZF ведь похожая система испольуется
Вообще-то уже gettext чудно использует данный подход.
UFO landed and left these words here
symfomy и через gettext локализовать может.
это да. только локаль в gettext задается на процесс, а не на поток. разработчики пхп говорят, что это все виновата текущая реализация самого gettext, а они не при чем и починить не могут. а разработчики gettext говорят, что пока glibc не исправят так все и останется.
так что gettext есть, а пользоваться им нельзя.
Скудная документация? оО
Целая книга, раздел c API, группы гугла — вам мало?

Кстати, на работе страница с api кейка постоянно открыта.
Да, для форм есть новый раздел документации.
Наверное, имелось ввиду, что Symfony не весь покрыт документацией, как, например, CodeIgniter.
Хотя в случае Symfony это непросто…
UFO landed and left these words here
Копируют не рельсы, а скорее Django ;) С бооольшими поправками на PHP.
UFO landed and left these words here
UFO landed and left these words here
Можно и генерализовать: «Всё сосёт!»
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
которые упорно пытаются скопировать рельсы
Имхо, из рельс взяли только идею «минимум рутины». На текущий момент symfony таки идёт собственным путём.

Вы правда считаете, что люди из symfony core team с 5+летним опытом разработки (не только на РНР) больше ни на что не способны, кроме как копипастить решения из рельсов?
UFO landed and left these words here
корявые копии решений из рельс
Вы бы их перечислили, что ли — а то голословно как-то выглядит ваш комментарий. Ссылки там, названия — хоть что-нибудь.
UFO landed and left these words here
Разработчики Rails успели запатентовать хелперы? Их, ЕМНИП, вообще все кому не лень используют. Кроме того, начиная с версии 1.1 (4 месяца как), в symfony появился Forms framework, благодаря которому этот код будет выглядеть примерно так:
<form action="<?php echo url_for($moduleName.'/'.$actionName.'?step=third')?>" method="POST">
  <label for="city"><?php echo __('Select city')?>:</label>
  <?php echo $form['city']?>
  <?php echo __('Can't find your city? Type it\'s name')?>
  <?php echo $form['alternate_city']?>
  <input type="submit" />
</form>
А в особо примитивных случаях его можно сократить до
<form action="<?php echo url_for($moduleName.'/'.$actionName.'?step=third')?>" method="POST">
  <?php echo $form;?>
  <input type="submit" />
</form>
Rails давно так умеют?
Вы бы посмотрели, как это бы смотрелось в CakePHP :)
Посмотрел.
Я правильно понимаю, что $form->create('Recipe') скаффолдит Recipe? И весь тюнинг формы — в шаблоне и только в нём?
Я уже не помню, но, кроме построения формы, есть и валидация, и система вывода сообщений об ошибках
Сама форма должна строится по параметрам модели.
И да — это всё, что, по-вашему, скопипащено из рельс? Или можете привести еще примеров?
стаж разработки мало о чем говорит
Скажите об этом Zed'у Shaw.
Улыбаемся и машем, парни. Улыбаемся и машем. (с) м/ф Мадагаскар
полностью солидарен.
А есть у symfony какие-то преимущества перед Zend Framework? :)
Конечно. Там очень тесная, но довольно гибкая интеграция между компонентами.
Добавим малость конкретики: «там» — это где? Означает ли тесная интеграция tight coupling?
Там — это Symfony. И нет, это не tight coupling.
Тогда не могли бы Вы расшифровать фразу «тесная, но довольно гибкая интеграция между компонентами»?

А, да. Попытаюсь внести ясность: я не против ни CakePHP, ни Symfony, ни CodeIgniter. Хотя мне больше всех при поверхностном знакомстве нравится Симфони. Однако ни в одну из них я глобально не лазил. То есть я не веду святую войну, а просто пользуюсь случаем пообщаться со знающим человеком.
Ну, например, в генераторе форм, насколько знаю, можно использовать данные схемы БД. При этом схема модет задаваться как для Doctrine, так и для Propel.
:-[ ] То есть там знания о хранилище данных тянутся вверх вплоть до view? Хм…
Нет, они не тянутся. Тянется интерфейс для их получения. И на этом основаны, насколько помню, генераторы форм.

Вообще симфонисты лучше меня расскажут. Я так… любитель.
нене, компоненты фреймворка напротив очень даже decoupled.
Мне еще рано судить, но пока не найдены =)
Оно действительно является каркасом (framework), а не набором классов/библиотек а-ля PEAR.
ИМХО симфа собрала со всех популярных фреймворков все самое лучше.
Тот кто по настоящему ее распробовал, никогда не вернется ни на что другое.
Один только саб-фреймворк форм чего стоит!
Потом, все ее компоненты можно использовать отдельно — легко разбирается, легко собирается.
Всякие кейки, игнитеры, зенды — жалкие поделки, по сравнению с этим шедевром.
Ну, так резко не стоит ;)

У всего своя ниша. Symfony надо именно распробовать. Не у всех хватает на это времени и терпения.
«Скажите, разве вам с первого раза понравились устрицы, чай, портер, трюфели, все то, к чему вы после пристрастились?..»
UFO landed and left these words here
UFO landed and left these words here
минусовать за совет? =) Очень умно.
аргументировали бы хоть как-нибудь.
Ну Вас, наверное, минусуют за то, что заявления такого рода как в Вашем комменте сродни «ИЕ сосет у ОгнеЛиса!», т. е. холивар в худшем своем виде — без аргументов.

Такой аргумент Вас устроит?
Ох, где же я в своем заявление плохо отозвался о симфони? Всего лишь показал, что не зендом и симфони мир ограничивается и возможно стоит для полноты картины взглянуть и на другой фреймворк.
Не взглянуть, а использовать. Без аргументов. Выглядело хамски, вот и минусуют. Вас что-то не устраивает?
Призыв использовать что-то другое — это хамство? Однако. Жаль, что взрослые вроде люди так болезненно реагируют на безобидный комментарий и воспринимают его как хамство.
Что касается аргументов, то я не думаю, что если я сейчас приведу аргументы в пользу CI, то минусаторы неожиданно одумаются и вступят в разговор.
Тянусь я за солью в ресторане. Мужик из-за соседнего столика: «Ты что! Перчи, а не соли!»

Однако.
Значит _возможно_ он знает, почему лучше это блюдо поперчить, а не посолить. Тем более, что автор топика собственно блюдо то и не распробовал ещё, ага ;)

Я бы может мужика и проигнорировал бы, но в интернете посмотрел какая приправа лучше подходит и почему. А вдруг окажется, что он прав был)
А возможно, я знаю лучше. Непрошенных советчиков иной раз и посылают в известном направлении.
Лол.

Это как бы осуждение топика и непрошенных советчиков тут нет. И автор это подтверждает: «Хотелось услышать размышления всех PHP программистов.»

Смею заметить, что изначальный коммент был написан не для вас и не для остальных пользователей, а для автора, т.е. то что вы возможно знаете лучше не имеет никакого значения.
Вот чессло, не заметил я никаких размышлений в Вашем комменте. Для автора существует личка, но Вы сами публично вылезли с CI, никто не заставлял. И сами возмущаетесь реакции публики на своё сообщение, которое, оказывается, и не про нашу честь вовсе.

Что касается «осуждения»: ну что Вы! Я давно не видел настолько благожелательных бесед здесь. Только вот Вы картину чуть испортили.
Ну что же, простите за испорченную картину.
Он не совсем для симфонистов =). Я хотел, что бы его прочитали, те люди которые к симфони вообще никакого отношения не имеют.

Сначала я определил именно туда, но понял, что толку будет мало. Хотелось услышать размышления всех PHP программистов.
Согласен с ISVir, т. к. комментарии к топику явно вывели его за пределы блога по Симфони.
пользую codeigniter & smarty.
хелперы для построения форм не использую.
Присоединяюсь к мнениям о том, что в Симфони прекрасная документация и прекрасный суб-фреймворк для форм. Это так.

Но больше всего меня удивило ваше недовольство системой интернационализации. xml-ка эта генерируется (и обновляется) вовсе не вручную, а скриптом из командной строки. Симфони сама собирает все подлежащие переводу строки и формирует из них файл (или добавляет непереведенные строки в существующий). Разработчику остается, фактически, помечать куски текста для перевода в шаблонах. А переводчик может работать с xml-файлом с помощью любого визуального XLIFF-редактора, коих по интернету валяется десятки.

Лично меня i18n и l10n в симфони приводят в совершенный экстаз :)
Вы не верно прочитали. Как раз таки система локализации мне о-очень понравилась.
Извините, прочитал «мне понравилась» как «не понравилась».
В кейке так же.
На виртуальном хостинге mtw.ru, которым пользуется один из моих клиентов, тормозит жутко. Прямо сейчас переписываю на CodeIgniter. От самого Symfony впечатления в целом хорошие, но в российских реалиях использовать его сложновато, особенно при традиционной ненависти советских хостеров к технологии SSH. На форуме одного из таких хостеров админ в ответ на многочисленные просьбы предоставить его админ заявил, что будет проверять сайты проявивших желание получить шелл-доступ клиентов хостинга на наличие вредоносных скриптов, так как только хакерам с их эксплоитами он и нужен.
Российские хостеры в большинстве своем хостить просто не умеют, при грамотной реализации симфа вообще не тормозит, акселератор ставить надо и все.
У меня помню такая же проблема была.
Хостер — «самый популярный и реномированный хостер» Германии, ага. Пришлось отказаться от проекта.
не пойму о чем пост :( реально сжованная информация. тут попробовал, тут попробовал, не понравилось…
считаю у симфонии просто выше порог вхождения, ибо даже чтобы песочницу из архива развернуть (на юниксе по крайней мере 100%) нужно в cli поработать (fix-perms, cc там всякие). в виндусе чтоб php в path был вписан и т.п. да и чтобы запуститься нужно до третьей(!) главы дочитать, увы дочитывают не все и не всегда (сам такой сначала день потрахаюсь, потом час чтения документации и о чудо оно работает!)
документирован он достаточно хорошо, именно настолько насколько необходимо для того чтобы понять чего в симфонии есть, а чего нет, а вот для того чтобы знать как оно там работает необходимо посмотреть исходники. тут лучше один раз увидить чем сто раз услышать, поверьте экономит время в будующем. исходники к слову у симфонии просты и незатейливы, читать их одно удовольствие, да и есть там чего подчерпнуть.
касаемо форм. зачем же вы, если только изучаете симфонию, этот анархизм берете? я про формхелперы? с 1.1 идет целый фреймворк, там вам и виджеты и схема валидации, и и18н. а в 1.2 даже вложенные формы появились
симфония хорошая, попробуйте и она вам обязательна понравиться, сам уже год как активно использую, все нравиться. вот жду как 1.2 зарелизят
Я не сказал, что симфони мне не понравилась в целом.

Во вторых и дома и на работе линукс. И я опробовал «fix-perms, cc там всякие». И мое знакомство с симфони на этом не кончается. Это первые впечатления. Если они Вам не интерестны никто не заставляет Вас их читать. Топик набрал достаточное количество голосов, что бы доказать, то что он интересен людям.
ну почему ж не интересно? я вообще редко пишу. значит интересно…
я рад за вас и за линукс во всем мире, нехотел вас обидеть и уж поверьте не имеел конкретно вас в виду, про порог вхождения собственное наблюдейние за людьми на работе.
поводу набрал голосов, да тут уж все забыли о чем топик, тема то холиварная. одни кричат Zend, вторые CodeIgniter, третие вообще рельсы вспомнили…
с нетерпеньем ждем вторых и третих впечатлений.
у самого все проекты пока на первой версии так что с удовольствием почитал бы впечатления от использования субфреймворка для форм, попытку написать виджет и т.п.
Я четвертый и вспомнил кейк =)
Да, про формы интересно было бы почитать, на работе жаль только с кейком мучиться приходится =(
В Zend_From примерно такая — же колбаса выходит.
очепятка. Zend_Form конечно же.
Нет, абсолютно не такая =), дабы не разводить споров просто почитайте документацию к Зенд_Формам.
увольняйся, пока не поздно :-P

Я закончил четыре проекта на симфони, и зарекся что-либо на этом фреймворке делать.
Какашка ;)
Может быть в версии 3.9 будет что-то стоящее. Пока — потраченные впустую пол года моей жизни.

Учите сразу Rails. Симфони от туда дерётся.
Да, как бы фирма только пробует его впервые. Я же будет делать выводы и докладывать о них начальству. А лишний опыт мне самому не помешает.
появиться куча проблем с
— локализацией: та версия, которую я использовал «не умела» ходить по папочке «cache» и по pear'у для парсенья php-файлов на наличие "__('text')". На сколько я знаю она и щас не все парсит
— установкой. Пришлось долго плясать, чтобы командлайновые команды работали на разных системах и настройках PHP.
— поддержкой. по непонятным мне причинам вываливаются php эксепшены «не могу заинклюдить файл из папки 'cache'. На тот момент у мну руки уже опустились и я не стал разбираться в причинах, просто когда такое случается чищу ручками папку 'cahce'
— с вечными циклами. да-да. с ними самыми. Где-то в дебрях либы. Причину, конечно же нашли. Это когда дочерний объект (в понимании model) вызывает save родителя.
— проблемой структуры каталогов. приходиться изменять стандартную схему каталогов для систем работающих под plesk'ом (например). Ведь бекапиться только папка 'public_html'. Приходится совать все туда.

В общем ( | )
(это смайл такой, если кто не догадался)

Если вы еще полны желания делать что-либо на sf, могу пожелать вам только поменьше терпения — больше времени сэкономите :-P
Не успел еще столкнуться ни с чем вышеперечисленным =) да и сервера у нас свои (опять я же и админ) =)

Но в любом случае, спасибо за предупреждение.
надо руки просто выпрямлять и документацию читать внимательно. все проблемы решимы
руки нада вправлять Фабиену с его командой ;)

пишите на голом PHP. Там все проблемы решимы

я своими прямыми руками работаю на Симфони не один месяц, и все больше и больше убеждаюсь в «прямоте» рук Фабьена и его команды :)
ну не получается у меня найти нерешимых проблем в этом фреймворке! :D
Пожалуй написать такое, это ох какие прямые руки надо иметь.
это получается что он ради каждой фразы лезет в xml файлик, парсит его и выдает? помоему это не лучший вариант, парсинг xml конечно будет _скоро_ в процессоры встроен, но пока его нет, и пока, на сколько мне известно, xml парсится не лучшим образом и скоростью…
да и работа с формами помоему у зенда удобна очень :)
выше уже писали — за каждой фразой не лезет, а серилизует и кеширует.
Прошу прощения, а что такое «некозистость»? :)
Локализация ужасна. Ведь под PHP тоже есть модуль gettext — это стандарт уже. Да и сложно представить сайт который при кадой загрузке страницы парсит XML файл чтобы достать локализованные строки. Парсинг XML достаточно медленный процесс. А для более менее большого сайта этот XML файл будет довольно большим.

Как может пользоваться популярностью фреймворк который якобы имеет лейбл MVC, а код HTML и PHP в одном файле? Это реально противоречит модели MVC.

Не нашел с ходу информации о поддерживаемой версии PHP, но выше в комментариях написали что только PHP4. На дворе 2008 год, PHP6 на подходе а мы сидим на PHP4. Это значит что никаких исключений, никаких классов (хоть и в 5ке ООП тоже довольно примитивна).

В общем то для домашней странички с пару посетителями в день возможно кому то и сгодится… не больше того.
сообщение ниже — вам :)
Ах да… www.symfony-project.org/book/1_1/03-Running-Symfony
5-ку требует… Вопрос по 4 версии снят.

А в комментах выше действительно был про это разговор из которого я понял что он на 5-ке не работает.
Он был изаначально создан только под php5, про php4 там и речи не было))
Как может пользоваться популярностью фреймворк который якобы имеет лейбл MVC, а код HTML и PHP в одном файле? Это реально противоречит модели MVC.

в каком месте противоречит? Лично я тоже согласен с тем, что php — лучший шаблонизатора. И потому не надо нам всяких смарти сувать
Жалко. «blockquote» съелся
да, я тоже согласен что PHP это лучший шаблонизатор, но тогда непонятно почему на шаблонизаторе пишут полностью сайты :) а темболее из шаблонизитора делают фреймворки которые… общем запутаная цепочка.
Зачем вы передергиваете? Вы прекрасно понимаете, о чем я писал «php — лучший шаблонизатор». Какие именно есть у вас претензии к Symfony и ее реализации MVC? Специально для таких кто не любит «код HTML и PHP в одном файле», есть плагины типа www.symfony-project.org/plugins/sfSmartyViewPlugin. А уж если вы не про View говорили, то тот кто пишет HTML прямо в контроллере или модели — сам себе злобный Буратино.
кстати, редкостное извращение. из-за него код action'а распухал пропорционально количеству вложенных объектов, передаваемых в шаблон.
А вот мне кажется, что шаблонизатор лучше у Django. =)
Всё вышесказанное Вами выглядит, как «Я Пастернака не читал, но осуждаю…»

В комментах выше очень много сказано по теме, и у меня ощущение, что Вы троллите.

> Как может пользоваться популярностью фреймворк который якобы имеет лейбл MVC, а код HTML и PHP в одном файле? Это реально противоречит модели MVC.

Да, я тоже в ужасе. Как могут пользоваться популярностью технологии ASP.NET и Tapestry? Вообще, кто бы что понимал!

Ну, раз так, то откройте уж нам глаза: чем должны пользоваться нормальные люди, которые пишут проекты с сотней уников в день?
выше в комментариях написали что только PHP4

Вы что-то недопоняли :)
жаль в symfony не используется smarty like шаблоны
как мы удобно было
поправил yml с формой, поправил шаблон
{form action=«post» module=«module»}
{form_input_tag name=«login»}
{form_submit_tag value=«GO!!!»}
{/form}
Меня устраивает текущий синтаксис.

<?=$form; ?>

ASP like… не приветствую.
как хорошо что sf не юзает smarty…
причём здесь smarty, имеется ввиду шаблонизатор с удобным синтаксисом, который бы позволил инкопсулировать вид. они же вынесли формы в yml. сравни мой код и то, что приходится гародить. и это без учёта пресловутого
Ну во-первых: i18n — это «internationalization», а не «internationlisation» — как у вас написано
Во-вторых: Документации по Symfony предостаточно. Согласен — на английском. Но большинству программеров это безралично.
В-третьих: После Zend Framework — Symfony — это как «луч света в темном царстве». Среди PHP фреймворков считается как самы производительный. Быстрее него CodeIgneter — ничего про него не скажу, потому что не работал с ним. Другие тесты: 1, 2
самый полезный комментарий из всех
Насколько мне известно, одна из центровых задач для Zend Framework 2.0 — это повышение производительности, так что, думаю, эта проблема будет решена. Да и не думаю, что производительность системы нужна гораздо чаще, чем производительность человеческого труда.
Здесь вы сами себя обманули (насчет производительности) — представьте себе человека работающего с продуктом написанном на системе, производительность которой «вы не думаете, что нужна чаще, чем...».
Какова будет производительность этого человека? ;)
Я не совсем точно выразился. Имелось в виду, что во многих случаях производительности Zend Framework вполне достаточно. В других случаях можно использовать кэширование. Случаи, когда этого оказывается недостаточно — довольно редки (зависит от масштаба, бюджета на железо и популярности проекта). А бенчмарки обычно вызывают у меня улыбку, особенно когда они используются как ориентир для выбора технологии.
Кроме, конечно же, редких случаев, когда необходима максимальная производительность во что бы то ни стало.
И в догонку — не в производительности дело, когда речь идет о Zend Framework… Работа со слоями в Zende до недавнего времени — это было что-то… Если нужно было вставить некий модуль, который в шаблоне будет выводить данные на некоторые страницы — приходилось очень крутиться (
В симфонии на этот счет все гораздо удобнее. Кроме того для симфонии куча готовых модулей, как то — галереи, блоги, форумы, cms и т.д. и т.п.
Согласен с утверждением, что установка симфонии достаточно запутанна, но — это только сначала. С опытом — установка проходит в считанные минуты с учетом создании структуры бд. Всё продуманно, всё логично…
Symfony — целостный фреймворк, Zend Framework — пока нет. Symfony — уже взрослый, ZF — подающий большие надежды вундеркинд. Я бы так сказал.
А мне казалось, что Symfony — самый тормозной.
Кстати, по ссылке сравниваются только два (!) php фреймоврка — CodeIgniter и Symfony, по ссылке на тест 1 — таблица характеристик, а не тесты, по ссылке на тест 2 — вообще нет теста.
Если вы утверждаете, что Symfony медленее только CodeIgniter'a — приведите тесты с наиболее популярными фреймворками.
Симфони очень быстро развивается, релизы не заставляют долго ждать, это гут.

Объектно ориентирован, если что то не устраивает — пишем свой метод, который переопределяет какой то метод родительского класса, тоже гут.

Структу

Бня! Нажал CTRL+ENTER :(

Структуру каталогов поменять совсем не сложно.

На хостинг выложить тоже не проблема, не надо SHELL, «замораживаете» проект и выгружаете.

За все хостинги не скажу, на.м(не пеар!) проекты работают быстро.

С проблемами с кэшем не встречался.
Если только начинаете работать с фреймворком — лучше сразу ориентироваться на последние версии. Последней стабильной версией на данный момент является 1.1, и Form Helper в ней уже является deprecated. На смену пришел symfony form framework, многим похожий на Zend_Form.
Я ее и использовал. Но в документации был лишь один раздел «Forms» в котором было все описано так, как я сделал.
Если Вы смотрели документацию именно для версии 1.1, то в самом начале раздела Forms Вы могли прочитать
This chapter describes the way forms were implemented in symfony 1.0. For compatibility reason and because of the admin generator feature still uses this system, this information is also valuable for symfony 1.1. However, if you start a new project with symfony 1.1, you also want to read the «symfony Forms in Action» book for more information on the new form framework.
Вы правы, я мог заметить и заметил. Но опять же не нашел такого раздела в документации.
рекомендую хабрачитателям ознакомится еще c структурой инклудов движков популярных фреймворков:

Symfony 1.1


Zend Framework 1.5.2


CakePHP


CodeIgniter


выводов, конечно, серьезных из этих схем не сделаеш, но по ним можно судить о сложности файловой структуры фреймворка.

комментарии типа "Зенд жжот" прошу не размножать :-D
Очень интерестная, и полезная информация. Спасибо.
Очень, очень будет интересно послушать Ваш коммент, когда вы «распробуете»(как тут выше писали) Symfony. Особенно потому что вы много работали с Zend Framework. Напишите, не поленитесь, пожалуйста. Сам интересуюсь Zend'ом, но тут пишут что Symfony лучше. Поэтому убедительно прошу — отпишитесь.
Напишу немного от себя (никакого холивара, только то, что использую сам). Symfony не использую, потому что использую ZF.

Итак — локализация. В ZF очень (я бы даже сказал ОЧЕНЬ) крутая и гибкая система локализации и интернационализации. Поверьте, это действительно так. Автор привел пример реализации с XML. У Zend_Translate аж 9 адаптеров. Выбирай на вкус framework.zend.com/manual/ru/zend.translate.adapter.html. Плюс, можно легко написать свой.

Form Helper — тут вообще все просто. Нет никакой «неказистости шаблонов». Zend_Form — очень мощный механизм создания форм. Не нравится встроенный декоратор? — можно легко написать свой. Мне например не нравятся декораторы в принципе, так как это не вполне соответствует парадигме MVC. Поэтому я просто формирую массив и отдаю Smarty (ну или кому что нравится). При этом сохраняются все возможности валидатора.

Автор, ничего личного, но я думаю, что не стоит писать статью о фреймворке, который Вы знаете, цитирую: «очень плохо». Узнайте получше, тогда уж и пишите.
Only those users with full accounts are able to leave comments. Log in, please.