Pull to refresh

Comments 28

UFO just landed and posted this here
Дай бог не последняя.
Не так давно тоже заинтересовался Symfony2, бегло пробежался по документации и все-равно полез гуглить «symfony2 как начать». Как сегодня уже писали: «очень высокий уровень вхождения». Годная статья получилась. Спасибо!
Жаль, что не затронули валидацию и работу с формами (включая интеграцию валидации, форм и доктрины) — с ними преимущества симфони2 куда заметнее. Да, и зря не упомянули, что Doctrine2 реализует не только (и, пожалуй, не столько) DataMapper, но и UnitOfWork и Reposotory. Прямая работа с мэппингом обычно заканчивается объявлением связей сущностей с БД, ни чтения, ни записи напрямую не вызывается — получаем данные из репозитория, а о их персистентности заботится EntityManager, у которого под капотом UnitOfWork. Кроме описания связи мы по сути вообще не знаем где у нас хранятся сущности.
Со всем этим за один вечер не разберешься, как только появится еще свободное время обязательно продолжу, так все что вы перечислили мне тоже интересно узнать.
Извините, не понял, что за один вечер.
Имеется ввиду — нужно время
Имел в виду, что я не понял что в статье описаны результаты одного вечера :)
интересно сделать динамическую валидацию, мы пока не смогли сделать ее. ограничения кода валидации…
В смысле динамическую? Я пока не разобрался с проблемой уникальных значений в БД при параллельных запросах.
например, есть некий конструктор админки, как у нас :), основанный на yml файлах. т.е. типовой функционал можно определить через 1 файл yml + бандл (контроллер наследуется от контроллера-конструктора(хоть в symfony не советуют так делать :) ))
так вот, отображение списка, динамических полей, форм добавления и редактирования — все задается в одном файле. и валидация. т.е. это то к чему мы стремимся. сейчас же для форм приходится вручную поля прописывать из-за того что валидатор создает объект для заполнения полей, а потом проверяет сам класс на наличие свойств через property_exist, в итоге динамическая валидация не получается
если честно в обзоре кроме аннотаций, нету никаких особенностей, а их в сф2 значительно больше
Это и не был обзор особенностей симфони, а просто история про то как как начать работать симфони.
Не надо все делать аннотациями. Все делается и через yaml.
Entity тоже вручную не надо создавать.
Лучше сформировать из sql yml файлы mapping'a, а потом сгенерировать Entity…
Entity можно самим править, при перегенерации ваш код генератор не трогает.
да, про аннотации я писал что их можно заменить на более удобный способ описания.
мне интереснее генерировать sql из yml)), а вообще с генератороми еще толком не разбирался — как генерить миграции, фикстуры и т.д. а вот что генератор не затирает то, что ты руками написал, это конечно удобная крутотень.
А мне аннотации для многого показались удобными. Для маппинга точно. Для роутинга — для простых приложений/бандлов/контроллеров должны быть удобнее, для сложных, наверное, всё же YAML (более читабельно в больших количествах). А ещё можно на PHP и XML — даже не знаю, что хуже :)

А вот насчёт SQL -> код или код -> SQL холиварить можно долго. Я за второй вариант :)
— для оптимизации базы
— при множестве таблиц, не завязанных каждая на свой бандл, а более обширной системы… лучше с sql — в yml, имхо. мы так уже месяца 4 работаем. практика показала свои плюсы.
— к тому же, аннотации менялись за это время, а yml нет :)
— Под оптимизацией вы имеете в виду использование особенностей конкретного движка РСУБД? Не мой случай. Я думаю как скрыть особенности SQL и NoSQL хранилищ.
— Ну, если система на PHP создаётся как ещё один фронтенд к существующей базе, то альтернатив просто нет (хотя можно ручками писать :) ), но вот если два бандла работают с одной таблицей, то, по-моему, лучше импортировать модель из одного в другой, чем её дублировать — или не вижу каких-то подводных камней?
— хороший аргумент :)
база да, существующая. пример сложности в бд — в одной таблице одного типа товаров — более 5 миллионов… а есть еще другие нюансы…
импортировать модель… мы все в один сложили. очень удобно
Насчиет пункта 1
symfony.com/doc/2.0/cookbook/debugging.html
все-таки dev используется не только для разработки но и отладки приложений(время выполнения, запросы. ну вы и так знаете), по-этому, я думаю, $kernel->loadClassCache(); по дефолту и включен, чтобы не обманывать статистику генерации.
Жаль, что не затронуты вопросы деплоя…
А что не так с деплоем? Можно обычным php-way слить каталог с приложением и ручками схему БД поправить, можно миграции заюзать, можно capistrano настроить, чтоб он всё сам делал.
Ну, вот например.

Во время разработки я решаю, что надо посмотреть, как выглядит сайт «вне девелоперского окружения» и пытаюсь открыть не localhost/Symfony/web/app_dev.php/blog, но localhost/Symfony/web/app.php/blog

/*Конкретного ругательства Symfony я уже не помню, но*/ фреймворк ругался, что не может что-то найти.

Хотелось бы, чтоб это и было освещено. На сайте документации этого я не нашел; как и в этой статье, которая очень походит на перевод первой части книги, представленной на сайте symfony 2.
/*Конкретного ругательства Symfony я уже не помню, но*/ фреймворк ругался, что не может что-то найти.

Ну я выкладывал на удаленный сервер в продакшен окружении типа такого блога — проблем не встретил. Что в голову сразу приходит — соединение с БД настроили, схему создали?
Вот более-менее актуальный перевод официальной документации symfony.com.ua
Можно добавить ещё, что тем, кто хочет начать работать с Symfony2 более легко, не обязательно использовать сразу весь фреймворк.
Можно использовать компоненты, как отдельные самодостаточные части.
Либо есть какой-то старый проект, который не использует фреймворка.
Сразу весь проект переделывать с нуля бывает нецелесообразно, но в нём можно
начать использовать какие-то компоненты.
К примеру, для работы с формами и т.д.
Если в config.yml не прописать

mappings: ... DemosBlogBundle: ~

то команда
php app/console doctrine:generate:entities Demos/BlogBundle/Entity/Post
не сработает.
Поправьте пожалуйста.
Sign up to leave a comment.

Articles