Да, «чтение», а вернее «прочитано» — это у меня вместо удаления, то есть если ссылку прочитали, то она больше не нужна в списке и поэтому удаляется.
Хотя наверное это запутывает :)
На счет языка описания моделей так теперь дается выбор: нравится Yaml пожалуйста, хотите использовать Xml — нет проблем, ну а если не хотите плодить конфиги, то можно сразу в классе самой модели все описать.
На счет *Table классов решение может кому-то покажется странным, но решение интересное надо просто в нем разобраться. Теперь не будет плодиться по несколько классов на одну модель, достаточно одного класса. При этом можно создать свой кастомный класс репозитория, который в общем будет выполнять ту же роль, что делали классы *Table, к тому же вы можете свой кастомный класс репозитория, который будет использоваться для нескольких моделей.
В общем если интересно, то очень рекомендую почитать документацию на Doctrine 2, это интересно.
> я столкнулся с проектами, где нельзя допускать ни одного логического бага
У нас ни на одном проекте нельзя допускать логических багов, любой баг нам может обойтись в копеечку (это очень большие копеечки), так как мы даем гарантию. Тесты, несколько уровней перед появлением в production, дают нам гарантию спокойствия, но даже в этой ситуации мы очень высоко ценим возможность быстро исправлять баги.
Если стала видимой закрытая категория, то скорее всего функционал попал в production не проверенным, тут фреймворк не причем, если честно.
> отвечу на вопросы:
Спасибо, но это были не вопросы, это были критерии, которым с ваших слов соответствуют ваши инструменты, о них то я (думаю и многие другие) и хотел бы услышать и более чем уверен что «любой говнокод-спагетти» вы не используете, так зачем приводить его в пример.
Тем более, что с утверждением что «любой говнокод-спагетти» является столь же гибким — я категорически не согласен, но спор на эту тему мне совсем не интересен.
> Ты, как и мы. программируешь на агиле
Нет, я программирую на PHP и Python в основном :) (это шутка).
> надеясь, что твой коллега, фреймворк и т.д. не подведут, это СТРАШНО
Это совсем не страшно. Про это можно написать целый пост, но думаю до меня это делали сотни людей.
Во многом фреймворк сильно выручает, когда несколько проектов разрабатывают на одном проверенном фреймворке я могу быть уверен, что программисту не придется неделю разбираться в проекте, я знаю, что подключая к работе менее опытного программиста фреймворк и принятые правила будут помогать ему не сбиться с пути и не нагородить огород изобретая свои велосипеды.
А если я не доверяю коллеге — то я с ним не работаю, если я не доверяю инструменту — то я его не использую.
> хороший код, это такой. который не меняет архитектуры со временем
Хороший код — код который делает именно то что надо и при этом легко читается и готов к изменениям. Но этим пожалуй не ограничивается, можно еще привести кучу параметров.
> Важно стабильное качество, а не красота архитектуры.
Для меня важно стабильное качество, красота архитектуры и общая успешность проекта. И на мой взгляд это не взаимоисключающие моменты.
При этом я согласен с тем, что архитектура может меняться, если это даст преимущества стоящие этих изменений.
Вы смеетесь что-ли? Нет, правда, может покажете инструмент или продукт в которых не всплывают баги? Правда, просто интересно очень.
Конечно же отсутствие багов — это просто супер как хорошо, но способность их быстро устранять — это очень ценно!
> Что это за архитектура, которую нужно переписывать из-за новинок языка
Вас удивляет, что многие проекты переписывали для перехода с php4 на php5? Вас удивляет когда разработчики используют новые возможности появившиеся в языке программирования? Вас удивляет, что проект развивается? Вы реально считаете, что лучший показатель, когда проект не изменяется и это говорит об идеальной архитектуре выбранной изначально?
Наверное у нас очень разный опыт.
> Я не вижу сферу применения Symfony, для визиток она тяжеловата
Знаете как оно иногда бывает, вы начинаете проект, простенький, он очень небольшой. Но потом у заказчика появляются новые идеи и что самое главное деньги на их реализацию и проект вырастает уже до средних размеров. Так вот Symfony дает возможность начать простенький проект отключив ненужный функционал, но и при его развитии у вас не возникнет проблем, так как в основе лежит гибкость предоставляемая фреймворком, которая позволит подключить недостающий функционал, либо заменить какие-то его части.
> для серьёзных проектов много багов
Я использую Symfony еще с версии 0.6, вот когда можно было говорить о приводящем в замешательство кол-ве багов, но сейчас уже исходя из опыта я могу сказать — Symfony зрелый, стабильный и очень достойный инструмент в том числе и для серьезных проектов.
> мы находимся в посте о RequestHandler
Поверьте, лично я помню :) и как раз на примере RequestHandler можно рассмотреть как можно использовать Symfony, если не для сайтов-визиток, так как обычно для этого есть готовые типовые решения, которые кстати могут быть также разработаны на Symfony, ну а хотя бы для очень простеньких проектов и при этом Symfony не будет как вы сказали «тяжеловата».
> но я считаю, что она слишком избыточна ради универсальности
Что ж возможно для вас архитектура Symfony избыточна, каждый имеет право на собственное мнение.
Было бы интересно узнать о вашем подходе к разработке об инструментах, которые вы используете и которые я так понимаю:
1) не менее гибки
2) менее избыточны
3) проще
4) позволяют писать меньше кода
5) более надежны для серьезных проектов
Уверен многие будут вам благодарны если вы напишете пост с рассказом о используемых вами инструментах.
Да что ж вы все про сложность Symfony то рассказываете. Не сложный он вовсе, не пугайте людей. У нас разработчики с ним осваиваются очень быстро и остаются довольны.
> ИМХО, Symfony для тех кто дорос до потолка php
Ну что вы, я видел как с ним лихо осваиваются весьма еще середнячки и при этом остаются довольны и расширяют собственные познания и учатся на хороших примерах.
>>в условиях толстого фреймворка php проиграет python
Знаете, я разрабатываю как на PHP + Symfony, так и на Python + Django и мне лично Python нравится больше, чем PHP, но это мое сугубо личное мнение и я не хотел бы здесь разводить холивары по поводу сравнения кто кому и где проиграет. Symfony — отличный фрейворк, очень хороший и гибкий инструмент и во-многих случаях оценивая по многим критериям я выбираю для проектов PHP + Symfony.
Сопоставляя
> очень давно работаю с доктриной
и
> и точно на ней не стал бы делать проект даже с 6-нулями
Ну вот правда в этой ситуации я могу вам только посочувствовать. Очень не хорошо, когда работа, которую делаешь настолько неприятна.
> тоже капитальное переписывание symfony, показывает неустойчивость позиций автора
Вы просто не в курсе, но делаете выводы, жаль. Это не совсем просто капитальное переписывание, в данном случае это развитие и развитие в сторону большей гибкости, развитие с учетом прошлого опыта и пожеланий, развитие с учетом серьезных изменений в языке программирования на котором написан фреймворк.
> доверите деньги годами отточенным компонентом java или свежепереписанному Symfony
Symfony доверяют такие гиганты как Yahoo, Dailymotion и др.
> К сожалению, из-за отсутствия стабильного флагмана приходится всё писать самим, на агиле, надеясь что пронесёт или тесты выручат.
Мы уже долгое время разрабатываем в том числе и на Symfony и не надеемся на «пронесёт» и при этом спим спокойно :)
А вот этап «приходится всё писать самим» к счастью остался далеко в прошлом и знаете это позволяет разрабатывать быстрее и стабильнее и не тратить время и силы на изобретение не нужных велосипедов.
> Гибкость это возможность добавления функционала или его изменения, когда от простого к сложному.
По-моему Symfony вполне соответствует этому определению.
> Вот данный компонент точно избыточный.
Какой конкретно?
> тоесть вы предлагаете сразу создавать кучу избыточного функционала, а затем дать возможность его отключать.
Конечно же нет. Symfony — full-stack фреймворк, который предоставляет весь необходимый функционал для разработки веб приложений охватывая все его аспекты. Но в некоторых случаях некоторая функциональность не нужна, либо есть желание заменить какую либо функциональность тем к чему больше привык, что больше подходит и т.д. Symfony предоставляет эти возможности.
> Путь Symfony 2 тупиковый, он тяжёл для начинающих, а для профессионалов проще написать под проект.
Время рассудит. Если этот путь тупиковый, то проект Symfony как фреймворка загнется, если нет, то он будет набирать обороты и кол-во пользователей будет расти. Пока судя по всему Symfony не подает признаков вымирания.
> У меня уже давно есть монстр с ORM и программированием на конфигах, это удобно, но я понимаю, что можно упростить, но оставить почти тот же функционал и гибкость.
Это замечательно. Возможно когда Symfony наконец дойдет до тупика вы поделитесь своим творением с общественностью и все будут в выигрыше.
Мне тоже очень нравится Python вообще и Django в частности.
Однако я не соглашусь, Symfony не поворачивал от простоты и скорости разработки, они просто повернули в сторону гибкости, а точнее продолжили путь. Многие ругают full-stack фреймворки за недостаточную гибкость, за невозможность отключить тяжелую артиллерию для простых проектов, за невозможность заменить какую-либо часть фреймворка своей любимой и супер удобной библиотекой, Symfony дает возможность это сделать.
Можно начать простой проект отключив все ненужное и если проект решит разрастить до более крупных размеров, то это не вызовет проблем, так как он сделан все на том же привычном фреймворке и надо будет лишь подключить необходимые части дающие требуемое расширение функционала.
А в плане удобства, простоты и скорости разработки я не увидел ухудшений.
Судя по всему вы используете в разработке Django? Что ж это хороший выбор, Django — отличный фреймворк.
Да, согласен. К сожалению на хабре нет инструментов для подсветки кода, либо я их не нашел.
Постараюсь в дальнейшем предусмотреть это и предварительно отформатировать текст где-нибудь в другом месте.
Хотя наверное это запутывает :)
На счет *Table классов решение может кому-то покажется странным, но решение интересное надо просто в нем разобраться. Теперь не будет плодиться по несколько классов на одну модель, достаточно одного класса. При этом можно создать свой кастомный класс репозитория, который в общем будет выполнять ту же роль, что делали классы *Table, к тому же вы можете свой кастомный класс репозитория, который будет использоваться для нескольких моделей.
В общем если интересно, то очень рекомендую почитать документацию на Doctrine 2, это интересно.
У нас ни на одном проекте нельзя допускать логических багов, любой баг нам может обойтись в копеечку (это очень большие копеечки), так как мы даем гарантию. Тесты, несколько уровней перед появлением в production, дают нам гарантию спокойствия, но даже в этой ситуации мы очень высоко ценим возможность быстро исправлять баги.
Если стала видимой закрытая категория, то скорее всего функционал попал в production не проверенным, тут фреймворк не причем, если честно.
> отвечу на вопросы:
Спасибо, но это были не вопросы, это были критерии, которым с ваших слов соответствуют ваши инструменты, о них то я (думаю и многие другие) и хотел бы услышать и более чем уверен что «любой говнокод-спагетти» вы не используете, так зачем приводить его в пример.
Тем более, что с утверждением что «любой говнокод-спагетти» является столь же гибким — я категорически не согласен, но спор на эту тему мне совсем не интересен.
> Ты, как и мы. программируешь на агиле
Нет, я программирую на PHP и Python в основном :) (это шутка).
> надеясь, что твой коллега, фреймворк и т.д. не подведут, это СТРАШНО
Это совсем не страшно. Про это можно написать целый пост, но думаю до меня это делали сотни людей.
Во многом фреймворк сильно выручает, когда несколько проектов разрабатывают на одном проверенном фреймворке я могу быть уверен, что программисту не придется неделю разбираться в проекте, я знаю, что подключая к работе менее опытного программиста фреймворк и принятые правила будут помогать ему не сбиться с пути и не нагородить огород изобретая свои велосипеды.
А если я не доверяю коллеге — то я с ним не работаю, если я не доверяю инструменту — то я его не использую.
> хороший код, это такой. который не меняет архитектуры со временем
Хороший код — код который делает именно то что надо и при этом легко читается и готов к изменениям. Но этим пожалуй не ограничивается, можно еще привести кучу параметров.
> Важно стабильное качество, а не красота архитектуры.
Для меня важно стабильное качество, красота архитектуры и общая успешность проекта. И на мой взгляд это не взаимоисключающие моменты.
При этом я согласен с тем, что архитектура может меняться, если это даст преимущества стоящие этих изменений.
Вы смеетесь что-ли? Нет, правда, может покажете инструмент или продукт в которых не всплывают баги? Правда, просто интересно очень.
Конечно же отсутствие багов — это просто супер как хорошо, но способность их быстро устранять — это очень ценно!
> Что это за архитектура, которую нужно переписывать из-за новинок языка
Вас удивляет, что многие проекты переписывали для перехода с php4 на php5? Вас удивляет когда разработчики используют новые возможности появившиеся в языке программирования? Вас удивляет, что проект развивается? Вы реально считаете, что лучший показатель, когда проект не изменяется и это говорит об идеальной архитектуре выбранной изначально?
Наверное у нас очень разный опыт.
> Я не вижу сферу применения Symfony, для визиток она тяжеловата
Знаете как оно иногда бывает, вы начинаете проект, простенький, он очень небольшой. Но потом у заказчика появляются новые идеи и что самое главное деньги на их реализацию и проект вырастает уже до средних размеров. Так вот Symfony дает возможность начать простенький проект отключив ненужный функционал, но и при его развитии у вас не возникнет проблем, так как в основе лежит гибкость предоставляемая фреймворком, которая позволит подключить недостающий функционал, либо заменить какие-то его части.
> для серьёзных проектов много багов
Я использую Symfony еще с версии 0.6, вот когда можно было говорить о приводящем в замешательство кол-ве багов, но сейчас уже исходя из опыта я могу сказать — Symfony зрелый, стабильный и очень достойный инструмент в том числе и для серьезных проектов.
> мы находимся в посте о RequestHandler
Поверьте, лично я помню :) и как раз на примере RequestHandler можно рассмотреть как можно использовать Symfony, если не для сайтов-визиток, так как обычно для этого есть готовые типовые решения, которые кстати могут быть также разработаны на Symfony, ну а хотя бы для очень простеньких проектов и при этом Symfony не будет как вы сказали «тяжеловата».
> но я считаю, что она слишком избыточна ради универсальности
Что ж возможно для вас архитектура Symfony избыточна, каждый имеет право на собственное мнение.
Было бы интересно узнать о вашем подходе к разработке об инструментах, которые вы используете и которые я так понимаю:
1) не менее гибки
2) менее избыточны
3) проще
4) позволяют писать меньше кода
5) более надежны для серьезных проектов
Уверен многие будут вам благодарны если вы напишете пост с рассказом о используемых вами инструментах.
В любом случае спасибо за ваше мнение.
> ИМХО, Symfony для тех кто дорос до потолка php
Ну что вы, я видел как с ним лихо осваиваются весьма еще середнячки и при этом остаются довольны и расширяют собственные познания и учатся на хороших примерах.
>>в условиях толстого фреймворка php проиграет python
Знаете, я разрабатываю как на PHP + Symfony, так и на Python + Django и мне лично Python нравится больше, чем PHP, но это мое сугубо личное мнение и я не хотел бы здесь разводить холивары по поводу сравнения кто кому и где проиграет. Symfony — отличный фрейворк, очень хороший и гибкий инструмент и во-многих случаях оценивая по многим критериям я выбираю для проектов PHP + Symfony.
> очень давно работаю с доктриной
и
> и точно на ней не стал бы делать проект даже с 6-нулями
Ну вот правда в этой ситуации я могу вам только посочувствовать. Очень не хорошо, когда работа, которую делаешь настолько неприятна.
> тоже капитальное переписывание symfony, показывает неустойчивость позиций автора
Вы просто не в курсе, но делаете выводы, жаль. Это не совсем просто капитальное переписывание, в данном случае это развитие и развитие в сторону большей гибкости, развитие с учетом прошлого опыта и пожеланий, развитие с учетом серьезных изменений в языке программирования на котором написан фреймворк.
> доверите деньги годами отточенным компонентом java или свежепереписанному Symfony
Symfony доверяют такие гиганты как Yahoo, Dailymotion и др.
> К сожалению, из-за отсутствия стабильного флагмана приходится всё писать самим, на агиле, надеясь что пронесёт или тесты выручат.
Мы уже долгое время разрабатываем в том числе и на Symfony и не надеемся на «пронесёт» и при этом спим спокойно :)
А вот этап «приходится всё писать самим» к счастью остался далеко в прошлом и знаете это позволяет разрабатывать быстрее и стабильнее и не тратить время и силы на изобретение не нужных велосипедов.
> Гибкость это возможность добавления функционала или его изменения, когда от простого к сложному.
По-моему Symfony вполне соответствует этому определению.
> Вот данный компонент точно избыточный.
Какой конкретно?
Конечно же нет. Symfony — full-stack фреймворк, который предоставляет весь необходимый функционал для разработки веб приложений охватывая все его аспекты. Но в некоторых случаях некоторая функциональность не нужна, либо есть желание заменить какую либо функциональность тем к чему больше привык, что больше подходит и т.д. Symfony предоставляет эти возможности.
> Путь Symfony 2 тупиковый, он тяжёл для начинающих, а для профессионалов проще написать под проект.
Время рассудит. Если этот путь тупиковый, то проект Symfony как фреймворка загнется, если нет, то он будет набирать обороты и кол-во пользователей будет расти. Пока судя по всему Symfony не подает признаков вымирания.
> У меня уже давно есть монстр с ORM и программированием на конфигах, это удобно, но я понимаю, что можно упростить, но оставить почти тот же функционал и гибкость.
Это замечательно. Возможно когда Symfony наконец дойдет до тупика вы поделитесь своим творением с общественностью и все будут в выигрыше.
Однако я не соглашусь, Symfony не поворачивал от простоты и скорости разработки, они просто повернули в сторону гибкости, а точнее продолжили путь. Многие ругают full-stack фреймворки за недостаточную гибкость, за невозможность отключить тяжелую артиллерию для простых проектов, за невозможность заменить какую-либо часть фреймворка своей любимой и супер удобной библиотекой, Symfony дает возможность это сделать.
Можно начать простой проект отключив все ненужное и если проект решит разрастить до более крупных размеров, то это не вызовет проблем, так как он сделан все на том же привычном фреймворке и надо будет лишь подключить необходимые части дающие требуемое расширение функционала.
А в плане удобства, простоты и скорости разработки я не увидел ухудшений.
Судя по всему вы используете в разработке Django? Что ж это хороший выбор, Django — отличный фреймворк.
Кстати, у меня в Chromium не заработало, а в FF нормально.
Постараюсь в дальнейшем предусмотреть это и предварительно отформатировать текст где-нибудь в другом месте.