Pull to refresh

Comments 40

… это PHP-фреймворк, ориентированный на быструю и гибкую разработку. Наши приоритеты/ гибкость — качество кода — скорость разработки.
В общем, все то же, что и в других новых фреймворках? :) Можно хоть вкратце, в чем собственно преимущество перед другими (хотя бы самыми известными) FW? Почему нам все стоит взять и влиться в ряды лимбовчан.

PS. Генератор кода — беее :) Не труЪшно, ИМХО
Если вкратце, то гибкость. У нас нет private классов, нет вшитых констант, которые нельзя поменять. Ну и так далее.

Генератор для самых ленивых. Только первоначальные «заглушки». Я сам обеими двумя руками против перегенераций.
Преимущество я могу назвать преред Symfony 1.4.
Limb3 — намного более гибок и удобен.

Интерфейсы в лимбе (программные интерфейсы) просто вылизаны до блеска. Компоненты разделены так, что ничего не мешает работы. Гибкость на уровне — в любой момент можно расширить класс или заменить своим для получения нужного функционала.

{{MACRO}} — не шаблонизатор, а СКАЗКА! Есть удобные теги форм интегрирующиеся с контроллерами, есть теги пагинации списков и вывода списков. Есть теги перевода {{i18n }}This text will display in Russian{{/18n}}

Ну и просто отличный расширяемый ActiveRecord, который позволяет родной SQL, в отличии от Doctrine + DQL (знаю, что там тоже можно, но через Ж...)

З.Ы. Кодогенератор — если даже не трушно в чьем-то мире, то уж точно — очень удобно!
UFO just landed and posted this here
Ну наконец-то!

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

в любой момент можно расширить класс или заменить своим для получения нужного функционала.
check

Насколько я помню, они совсем недавно что-то писали про нормальный IoC, но сейчас в документации вижу все те же фабрики, что и раньше. А если мне надо подменить соединение к БД на лету?

symfony forms уже с версии 1.1 сами себя рисуют без хелперов

Тут у нас большие расхождения в методике разработки:
— у нас формы рисуют верстальщики, которым показали 2 с половиной тэга макро. Генерация не очень вписывается
— валидация в форме это ИМХО fail с их стороны. Как же RPC всякие и cli?

Не знаю как вас, но меня (ну то есть сначала заказчика, а потом уже меня) ни один «стандартный» пагинатор в итоге
никогда не устраивал. Как правило, наваять «свой собственный» component/helper оказывалось проще и дешевле, чем адаптировать чей-то суперуниверсальный_пагинатор_4000.

Ну собственно поэтому у нас такого и нет. Мы тоже делаем пейждер под проект. Просто у нас для этого есть средства.

И да — а чем тэги списков лучше старого доброго foreach?

По большому счету ничем. Просто легче читается и меньше писать.

кстати, я не заметил в Limb AR my precious templates/behaviors/whatever? Неужели их там нет?

Нет, не было в них необходимости.
UFO just landed and posted this here
На лету, ЕМНИП, в 1.4 заменить класс запроса будет сложно, да. Хотя мне обычно удавалось без этого обходиться.

Мне не удалось, пришлось использовать runkit, благо в той компании это считается нормальным.
ммм… для репликации, например? Doctrine справляется с этим самостоятельно. Почти. Достаточно перехватить события preInsert/preUpdate и preSelect

Для чего угодно. Например, у нас на большинстве проектов есть ручка, которая по куке обворачивает соединение в аудит-враппер, чтобы смотреть статистику с трейсами и временем. Ну и так далее.

…echo $form['foo'], $form['foo']->render/renderLabel/renderId/renderName и повесили эти шаблоны на горячие клавиши или ещё на что-нибудь.

Они работают ДО программиста, у них никаких $form нет ;)
Самый популярный случай, когда надо подменить «звездный» объект это unit-тесты.
UFO just landed and posted this here
Я осторожно отношусь к мокам. Они дублируют поведение, и приходится не забывать их поддерживать в актуальном состоянии. У нас бы я просто делал lmbToolkit::instance()->setRequest(<сконфигурированный запрос>) и не парился. Возможно это и не «тру» unit-тесты, но в жизни такой подход оказался надежнее.
UFO just landed and posted this here
UFO just landed and posted this here
зная, как работает местный autoload, можно было обойтись без runkit — классы из проекта перекрывают собой одноимённые классы ядра фреймворка.

Это было в тестах. Как ты писал выше, логично было использовать mock, с подменой при инициализации.
Да и event dispatcher никуда не девался.

Он позволяет подменять данные?
ну а на лету подменять зачем? если можно (грубо говоря) сконфигурировать соединение с debug: true.

А куда девать определение того, что debug = true?
а, ну мы тоже так работаем. Только наши верстальщики ещё и не разучивают тэги шаблонизатора.

Зато они разучивают формы, если надо что-то поправить в верстке, уже после программистов ;)
UFO just landed and posted this here
Разве конфигурация не декларативная? Как мне этот флаг поставить по куке?

Там обычный html код? А как они расставляют сообщения об ошибках, и наполняют формы данными? Парсят html?
UFO just landed and posted this here
UFO just landed and posted this here
Я не про это. Валидация должна быть частью модели, т.к. модели создаются не только из веба.
UFO just landed and posted this here
Ага. А вот тогда пример — есть у меня форма связи с техподдержкой. Данные из неё отправляются напрямую в, скажем, почту или lighthouseapp.com какой-нибудь. Ну то есть не хранятся на сервере. Используя Limb, нужно будет создавать соответствующий класс модели, так?

Не обязательно, валидацию можно производить где угодно. Хотя в этом случае, я модель бы все равно сделал. Не важно, что она не сохраняется в базу, это не показатель.
К слову, валидация в модели присутствует.

Ну да, нашел. Правда меня настораживает автоматическая генерация по декларативному описанию, но это мои загоны.
я думал что фреймворку медленно приходит ханец — ан нет :)
года так с 2007 читаю ваш код с большим удовольствием, пополняю себя так сказать новыми идеями :)

а как у вас с производительностью?
А как ее считать? Если бы кто-нибудь сделал тестовый набор функционала, которым можно тестировать. Для MACRO, я такую штуку делал — korchasa.ru/index.php/2008/02/%D1%82%D0%B5%D1%81%D1%82%D1%8B-php-%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD%D0%B8%D0%B7%D0%B0%D1%82%D0%BE%D1%80%D0%BE%D0%B2/. Может когда-нибудь и дойдут руки сделать и для фреймворков.
С производительностью отлично. Почитайте форум — там где-то есть тема, куда складывают сайты на лимбе.
Ну не так уж отлично. Понятно, что из-за гибкости у нас есть множество ручек, где можно подкрутить или схлопнуть абстракции. Но из-за этой же самой гибкости мы имеем много call'ов. Да и памяти жрем прилично. С другой стороны есть, как минимум, 3 большие многосерверные штуковины, которые крутятся на Limb'е, и это всех радуют.
Ну я пока проблем с перфомансом не встречал.
И думаю что производительность будет не хуже, чем у популярных фреймворков.

Ну потому и говоря, что не отлично. Отлично будет когда допишем lmbARProxy и роутер на FSM, без регэкспов.
Вот уже более чем пол года наблюдаю за вынужденным багхантом товарища maxidler на просторах Symfony и Doctrine.
Некоторые баги просто обескураживали, хотя некоторые вещи в симфони сделаны очень недурственно и удобно. Самому тоже довелось изрядно попотеть на Symfony и Doctrine и отловить пару мерзких насекомых. Не скажу что полностью разочарован, но для будущих проектов точно их использовать не буду.

Если все же придется писать проект на пыхе то однозначно либо LIMB либо Symfony 2 (все-таки дам еще раз щанс… вдруг свершится чудо).
По мне так в Symfony2 тоже не все решения абсолютно правильны правильны.
Скажу так, ZF — это больше набор инструментов для создания нужных компонентов, нежели готовые пакеты, как в том же Limb или Yii. Мне по душе последний.
Тут каждый выбирает сам.
А почему вы в тексте иногда используете слэш вместо двоеточия?
Эта традиция уходит своими корнями к нашим предкам. Дело в том, что ножом на бересте? вырезать две точки сложнее, чем провести линию.

А если серьезно, то хабр колбасит от двоеточий в урлах. И пришлось прогнать замену: -> /
Да неужто свершилось?
Я уж думал не доживу :)
Кстати, репозиторий переехал на github.com или все еще на гуглокоде?
спасибо, учился unit-тестированию на вашем коде!
Чудесный подарок, спасибо!

… Использую LIMB c 2008 года. Фреймворк прогрессирует по сей день, что не может не радовать.
Когда я искал себе фреймоврк для работы и послушивал ту же Симфонию, то Limb приятно удивил русским языком. Да, да, русским. Тогда говорить с разработчиками на (р)одном языке было критично важно.

Что касается остального, то дальнейший мой рост как PHP программиста во многом состоялся благодаря Limb, ибо было и есть у кого поучиться.

В общем никаких технических подробностей — одни сентименты, мужская скупая слеза так сказать ))
Sign up to leave a comment.

Articles

Change theme settings