Комментарии 16
Есть собственные виджеты из коробки, аналогичные Yii?
Отличный фреймворк, который во 2й версии перешел на camel-case. Теперь будущее не настолько цветущее, к тому же Dan Horrigan куда-то пропал
Меня, как лентяя со стажем, больше всего интересует вот что: есть ли какое-то подобие CRUD? «На борту», или, возможно модуль типа grocerycrud для CI?
Грубо говоря, сколько времени требуется, чтобы с нуля набросать админку для, скажем, новостей?
Грубо говоря, сколько времени требуется, чтобы с нуля набросать админку для, скажем, новостей?
Вы можете взять тот же grocerycrud или любое другое готовое решение и интегрировать его в Fuel. Если вам нужно сделать с нуля что то своё, то Fuel будет неплохим инструментом для этого.
ну. В общем-то, это называется «нет, такой штуки не существует»:-)
А это что тогда? Model_Crud Methods
а это уже интереснее. Спасибо, почитаю
Еще рекоендую почитать про ORM
Сам пользуюсь Fuelphp фреймворк почти год. В самом начале не было достаточно полной документации, что по началу очень раздражало, сейчас таких проблем нет. Все достаточно понятно объяснено. Примеры готовых работ можно найти на github. Подтверждаю форум достаточно активный, что не может радовать.
Главное правильно объяснить свои мысли. Помогут — в плоть до готового кода.
По поводу генераторов кода, админки и тому подобных вещей которые идут в некоторых фреймворках «из коробки», тут дела обстоят чуть по другому, из за того что сам фреймворк молод, он ещё не имеет всего что надо, но есть очень не мало готовых решений они идут как package, который очень легко подключить.
Есть готовые решения по интеграции некоторых платежей.
Очень удобно подключать кэширование. APC, memcached, redis.
Хотя этим уже никого не удивишь.
Во общем каждому свой «молоток», я выбрал этот и не жалею. Думаю имеет смысл приглядеться к этому фреймворку.
Главное правильно объяснить свои мысли. Помогут — в плоть до готового кода.
По поводу генераторов кода, админки и тому подобных вещей которые идут в некоторых фреймворках «из коробки», тут дела обстоят чуть по другому, из за того что сам фреймворк молод, он ещё не имеет всего что надо, но есть очень не мало готовых решений они идут как package, который очень легко подключить.
Есть готовые решения по интеграции некоторых платежей.
Очень удобно подключать кэширование. APC, memcached, redis.
Хотя этим уже никого не удивишь.
Во общем каждому свой «молоток», я выбрал этот и не жалею. Думаю имеет смысл приглядеться к этому фреймворку.
Спасибо за информацию о обновлении. В 1.0 версии фреймворк был слишком сырым, как и его документация.
А вообще, радует что он сделан по образу подобию Ruby on Rails. Очень много идей явно взято оттуда, что, на мой взгляд, весьма не плохо и выходит действительно удобно.
Так она ещё в 1.0 была: github.com/fuel/auth или его просто включили в стандартную поставку?
А вообще, радует что он сделан по образу подобию Ruby on Rails. Очень много идей явно взято оттуда, что, на мой взгляд, весьма не плохо и выходит действительно удобно.
— Появилась аутентификация пользователей, групповое разделение привилегий и ACL(Access Control List или ACL — список контроля доступа).
Так она ещё в 1.0 была: github.com/fuel/auth или его просто включили в стандартную поставку?
Наблюда еще начальных этапов, один из разработчиков Phil Surgeon в общем-то брал идеи из RoR, но почему-то всё в PHP приходит так уродливо.
Почему раз уж вдохновлялись RoR не взяли именование классов правильно, например те же контроллеры глупо начинать с Controller приставки, потом в дереве классов дико неудобно искать. Намного удобнее было бы иметь UsersController чем Controller_Users. Так же именование методов, зачем эта приставка action_index, просто и понятнее иметь index, приставка ни к чему, лишнее.
Одно приятно, что пользуются андерскор именованием методов, хотя говорят во 2ой версии переходят на кэмел-кэйс, тоже не понятно зачем, в php подражание Zend, Java, .Net технологиям и смешать это с RoR. Не понимаю, но уже думаю 2-ой версией пользоваться не буду.
Где namespace? Заявлена поддержка 5.3, а нэйспэйса нет, то есть есть иногда в своих packages, но контроллеры и модели всё так же вывалены наружу, ничего сложного было сделать думаю:
class UsersController extends Fuel\BaseController{}
В общем-то сколько смотрел, не вижу в нём ни идеологии, ни хорошей сплоченности и формализованного кода, набрали всё, что было у других, замешали и получили ужасный коктейль.
Laravel в сравнении с FuelPHP выглядит проще, приятнее, продуманнее и современнее!
Почему раз уж вдохновлялись RoR не взяли именование классов правильно, например те же контроллеры глупо начинать с Controller приставки, потом в дереве классов дико неудобно искать. Намного удобнее было бы иметь UsersController чем Controller_Users. Так же именование методов, зачем эта приставка action_index, просто и понятнее иметь index, приставка ни к чему, лишнее.
Одно приятно, что пользуются андерскор именованием методов, хотя говорят во 2ой версии переходят на кэмел-кэйс, тоже не понятно зачем, в php подражание Zend, Java, .Net технологиям и смешать это с RoR. Не понимаю, но уже думаю 2-ой версией пользоваться не буду.
Где namespace? Заявлена поддержка 5.3, а нэйспэйса нет, то есть есть иногда в своих packages, но контроллеры и модели всё так же вывалены наружу, ничего сложного было сделать думаю:
class UsersController extends Fuel\BaseController{}
В общем-то сколько смотрел, не вижу в нём ни идеологии, ни хорошей сплоченности и формализованного кода, набрали всё, что было у других, замешали и получили ужасный коктейль.
Laravel в сравнении с FuelPHP выглядит проще, приятнее, продуманнее и современнее!
Как вы относитесь к коду проектов на Yii?
Интересно ваше мнение.
Приставка action, боюсь предположить, необходима чтобы в поле видимости случайно не попали внутренние методы (естесственно, приватные методы не дадут этого сделать), но возможена такая ситуация, когда необходимо иметь публичный метод, который гарантировано не виден по адресу. Сгеренировать ситуацию сходу не смогу…
Интересно ваше мнение.
Приставка action, боюсь предположить, необходима чтобы в поле видимости случайно не попали внутренние методы (естесственно, приватные методы не дадут этого сделать), но возможена такая ситуация, когда необходимо иметь публичный метод, который гарантировано не виден по адресу. Сгеренировать ситуацию сходу не смогу…
У Yii точно такие же проблемы, нет namespace, очень много статичных вызовов, опять же было желание сделать ряд вещей по подобию RoR (помнят еще желание символы ввести через :paramName). Yii превосходит конечно Fuel такими вещами как gii, behavior и еще ряд вещей, как уже большое комьюнити, но документация такая же плохая как и была (тут в пример можно ставить CodeIgniter и Laravel по их документации можно за пару часов понять фрэймворк).
Про action приставку я понимаю, что двигало их сделать, не понимаю только зачем это приставка например или не суфикс опять же index_action было бы лучше в списке видеть.
Ну и ума не приложу кому может в Контроллере понадобиться публичный метод и чтобы его не было видно по адресу, мы же не собираемся вызывать контроллер еще откуда-то (например из другого контроллера или класса библиотеки). Но это мелочи, в общем-то в Laravel тоже есть приставка action_* но тут еще есть один нюанс как приставки post_* и get_* для REST тут как-то списать эту многословность можно на это, в других случаях я бы сказал, что это лишнее будет.
Про action приставку я понимаю, что двигало их сделать, не понимаю только зачем это приставка например или не суфикс опять же index_action было бы лучше в списке видеть.
Ну и ума не приложу кому может в Контроллере понадобиться публичный метод и чтобы его не было видно по адресу, мы же не собираемся вызывать контроллер еще откуда-то (например из другого контроллера или класса библиотеки). Но это мелочи, в общем-то в Laravel тоже есть приставка action_* но тут еще есть один нюанс как приставки post_* и get_* для REST тут как-то списать эту многословность можно на это, в других случаях я бы сказал, что это лишнее будет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
FuelPHP год после 1.0