Как стать автором
Обновить

Комментарии 37

>Последним штрихом до выхода остаётся доделка новой версии билиотеки хранения сессий (Session), из которой уберут хранение сессий на клиенте в cookies (раньше это было по-дефолту)

А причина? Это довольно удобно, в большинстве случаев.
Куки не резиновые.
Ну так и хранить в сессии много не стоит. Обычно. 4кб на одну куку х десяток кук >= 40кб. Разве этого мало?)
Иногда да.
Проблем с куками много:
1) хранятся на клиенте — клиент может изменять. Решение — включить шифрование, а это доп проц и размер куки, что для хранения сессии довольно накладно
2) лимит по размеру, как уже сказали
3) ну и куку можно послать только перед началом вывода, дальше уже всё, нельзя. А вот записать в бд или на диск можно когда угодно.
1) Шифрование, насколько помню, в CI для кук было всегда. Не так уж и накладно, но раздувало размер куки ещё больше.
3) ob_* могут спасти ситуацию.
1) Подпись куки решает эту проблему.
2) 40кб под сессию и мало? Ну ок. Хотя я даже представить не могу, что должно хранится в такой сессии.
3) И? Как это связано с CI? Буферизация вывода избавляет от этой проблемы во всех фреймворках.

Честно — какие-то притянутые доводы. Которые могут потянуть на отказ от дефолтного использования кук для сессий, но точно не тянут на полный отказ.
40 кб в куках? Гонять 40кб каждый запрос? Да вы знаете толк в извращениях.
Которые превратятся максимум в 1кб после сжатия? Не серьезно.
Да и не говорил я, что надо всё хранить в куках/сессии. У меня как-то более пары-тройки сотни байт не набегало никогда, это вон другим не хватает ;).
Мне не понятно только как это может быть удобнее? Если сессия хранится на сервере, у нас разгружается канал от лишних данных которые так или иначе каждый запрос будут бегать туда сюда, мы можем вынести хранение сессий в хранилище побыстрее (реддис тот же), много разного можно делать. А куки это стремно.
Смотря с чем сравнивать. В случае с редис — да, возможно последний будет удобнее. В случае с файлами — куки значительно удобнее и быстрее.
Про разгрузку канала писал выше — это уже не актуально, если куки содержат несколько сотен байт. Да, если в куках десятки килобайт, это может стать критичным, но только в условиях совсем плохой связи.

Напомню: у меня вопрос был почему вообще убрали данный способ, вместо назначения другого дефолтным.
НЛО прилетело и опубликовало эту надпись здесь
Одна из причин смерти: github.com/EllisLab/CodeIgniter/blob/develop/composer.json против, например лары: github.com/laravel/framework/blob/4.2/composer.json
Один человек или сообщество фреймворка не проделают тоже количество работы, что могут проделать миллионы человек с разных уголков планеты. Например в симфони есть великолепно написанные классы и нормальное разделение кода, почему не использовать их?

Это одна из причин, почему CI мёртв, а за ним в могилу полным ходом идёт Yii (надеюсь разработчики последнего одумаются и перестанут строить велосипеды, т.к. подобный подход морально устарел). Прошё прощения за резкость высказывания.

Есть ещё несколько причин:
— Высокая связанность компонентов (то же самое и в Yii)
— Форматирование кода морально устаревшее (PSR, ты где? Открыл первый попавшийся файлик: github.com/EllisLab/CodeIgniter/blob/develop/system/core/Log.php), но это не особо важно.

Это те причины, которые лично меня (sic!) заставляют отказаться от этой системы при разработке более-менее серьёзных проектов, в пользу более мощных, более распределённых и грамотно организованных, вроде Laravel, Symfony или на крайний случай Zend.
Собрать монстрика из кучи чужого кода с разным API для каждого модуля можно и без composer (в CI просто нет столько кода и такого функционала, который тянется в laravel), не правда ли? А тот базовый функционал который есть легко расширяем прямо из своего приложения без надобности лезть в чужой код, унифицирован и предельно прост (как раз из-за высокой связности, что позволяет переиспользовать код и свести к минимум дублирование функционала в разных модулях и уменьшению времени выполнения). Аргумент что тысяча людей напишут 100 компонент лучше, чем 10 человек один фреймворк очень эфимерный и в реальности не может быть сравнён.

+ про связность уже сказал
+ почти PSR, только лучше: ci3docs.dannynunez.com/general/styleguide.html
Я не писал про монстра, я писал про перекладывание ответственности и использование уже готовых и оттестированных решений.
Я что-то неправильно прочитал, или вы действительно утверждаете, что высокая связность облегчает расширяемость?
По поводу CodeIgniter поддерживаю, а почему Zend
на крайний случай
?
Зенд действительно крутой и сделан как надо, но начиная новый проект, я лично отдал бы предпочтения симфони или ларе, а потом уже зенду.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Юзаю CI и по сей день для всех своих проектов. Доволен как слон)
Слон видимо не большой.
Ну и зря Вы так. Сам с CI начинал, но в итоге понял, что лучше потратить немного времени на изучение чего-то более свежего. В итоге выбрал Symfony 2 и знаете, я очень-очень рад. Он хоть и монстр, по сравнению с CI, но для чего-то небольшого можно выкинуть половину ненужный бандлов или собрать свой маленький фреймворк из Symfony-компонентов. В любом случае работать быстрее и приятнее, чем с CI.
Вы некрофил?
Вы предлагаете убивать рабочие проекты из-за того, что разработчики фреймворка перестали его поддерживать?
У меня, например, есть небольшой корпоративный сайт на Kohana и ещё один на CI. Мне пока качать Zend/Symfony и пилить с нуля?
Качать и в выходные часок другой проводить с кодом за чашечкой кофе — это более приятное занятие и позволит через некоторое время с новыми силами и мощностями запилить новый проект =)
А причем тут проекты на суппорте? Они как жили так и будут жить. Я к тому что сегодня использовать CI для новых проектов не практично. А по поводу «пилить с нуля» — рефакторинг лучше.
кто не считает зашкваром, конечно, писать на PHP

Фу, ну что за выражения такие?
У меня на CI работает где-то 5 проектов… 2 больших и 3 маленьких…
Где-то пол года назад решил попробовать Yii — и вы меня теперь ни за какие коврижки не перетащите обратно в CI.

Да, для маленьких проектов и CI подойдет, но вот для больших — Yii реально выигрывает в скорости разработки и последующей поддержки проекта. А в сязке с PHPStorm кодить одно удовольствие.

После Yii в код CI даже залазить не хочется…
Я раньше писал на кохане (не слишком много), чуток попробовал зенд (просто не сложилось), потом пересел на Yii и чувство восторга не покидало меня — тоже считал, что не перелезу никогда в жизни.

Потом решил посмотреть в сторону Laravel, уж очень много о ней говорили. Сейчас даже и думать не хочу о Yii, со всеми вытекающими. Предполагаю, что это как перелезть с CI на Yii — настолько там всё проще и удобнее делается, особенно в плане конфигов ;)
Аха) Сколько лет идут войны в комментах и кодигнайт вечно хоронят) Так же как ie и windows и автоваз, но они по прежнему живы :D Что мертво — умереть не может :)))
ИМХO — СodeIgniter уже не взлетит. За последнее время появилось ряд новых, более современных фреймворков.
Хотя в свое время CI был отличным инструментом для решения задач.
Говорите что хотите, но лично мне CI нравится до сих пор. У нас в студии есть проекты и на Yii, и на Symfony но быстрей всего и удобней (возможно в силу привычки) разрабатывать на CI, да и восторга от перехода на другой фреймворк я не получил :) Хотя еще раз повторюсь что это наверно мое сугубо личное восприятие.

P.S. Всем добра :)
Стоит признать, конечно, что имея наработки и набор своих костылей и велосипедов писать на CI становится веселее и быстрее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории