Comments 31
Вставьте вместо CodeIgniter cakePHP и это будет про меня. Я бы еще добавил пункт — это приучает к coding standarts (ну в рамках фреймвокра то точно), а это тоже не хилый плюс.
+3
>что codeigniter облегчает жизнь только тем программистам, которые на хорошем уровне знают сам php!
Имхо если чел. чуть-чуть понимает что такое ООП разобраться в ci проблем нет. Но если он не понимает что такое ООП то и программистом его назвать сложно. Все-таки 2008 год на дворе.
Имхо если чел. чуть-чуть понимает что такое ООП разобраться в ci проблем нет. Но если он не понимает что такое ООП то и программистом его назвать сложно. Все-таки 2008 год на дворе.
0
Конечно понятие ООП безусловно нужно, но и сам голый PHP хорошо знать обязательно.
А вообще основное приемущество фраемворков, лично для меня, не нужно заморачиваться над мелочами, которые делал раньше из проекта в проект. Остаётся больше времени на проектирование логики приложения, что куда более интересно, чем «тупой» кодинг.
А вообще основное приемущество фраемворков, лично для меня, не нужно заморачиваться над мелочами, которые делал раньше из проекта в проект. Остаётся больше времени на проектирование логики приложения, что куда более интересно, чем «тупой» кодинг.
+1
Да уж… Надо обязательно сперва самостоятельно изобретать свой велосипед, чтобы потом по достоинству оценить фреймворки.
Пошел разглядывать CI, пора уже делать шаг на следующую ступеньку.
PS. Капнул чутка благодарности за толчок в нужную сторону.
Пошел разглядывать CI, пора уже делать шаг на следующую ступеньку.
PS. Капнул чутка благодарности за толчок в нужную сторону.
+2
Правильные мысли, тоже собираюсь переходить на CI и Zend Framework.
Хотя сказать по правде, в силу специфики размеров проектов, с которыми работаю, как правило фреймворк не применим в большинстве случаем и для каждого проекта создаётся костяк на базе идейной структуры, обеспечивающей работу с сессиями, загрузку модулей, ЧПУ и некоторые самые базовые вещи. Всё остальное module specific или пишутся классы для работы с конкретными вещами (как правило, они reusable)
Хотя сказать по правде, в силу специфики размеров проектов, с которыми работаю, как правило фреймворк не применим в большинстве случаем и для каждого проекта создаётся костяк на базе идейной структуры, обеспечивающей работу с сессиями, загрузку модулей, ЧПУ и некоторые самые базовые вещи. Всё остальное module specific или пишутся классы для работы с конкретными вещами (как правило, они reusable)
0
code-igniter.ru/user_guide/libraries/table.html
Это, простите, здец…
$tmpl = array ( 'table_open' => '<table border="0" cellpadding="4" cellspacing="0">', 'heading_row_start' => '<tr>', 'heading_row_end' => '</tr>', 'heading_cell_start' => '<th>', 'heading_cell_end' => '</th>', 'row_start' => '<tr>', 'row_end' => '</tr>', 'cell_start' => '<td>', 'cell_end' => '</td>', 'row_alt_start' => '<tr>', 'row_alt_end' => '</tr>', 'cell_alt_start' => '<td>', 'cell_alt_end' => '</td>', 'table_close' => '</table>' ); $this->table->set_template($tmpl);
Это, простите, здец…
+7
Это не здец, а шаблон таблицы, и по хорошему его либо вообще трогать ненадо, либо измеить один раз, то что нужно. Вы пытаетеся найти недостатки, забивая на достоинства.
0
я не вижу в таком подходе к шаблонизации ни одного достоинства.
сплошные недостатки.
сплошные недостатки.
+6
Если вы читали введение к фреймворку — там написано, что шаблонизатор присутствует, но он СОВСЕМ НЕОБЯЗАТЕЛЕН.
Как говорится, не нравятся стринги — не носи их :)
Как говорится, не нравятся стринги — не носи их :)
0
CI не навязывает шаблонизаторы. Не нравится этот, возьмите любой другой.
Или радикально прикрутите XSLT. Это еще проще.
Или радикально прикрутите XSLT. Это еще проще.
0
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Если честно, шаблонизатор в ci действительно простейший, лично я пользую smarty.
-1
угу…
0
Использование фреймворков — это хороший шаг, который позволяется сосредоточиться на написании бизнес-логики вашего приложения, вместо реализации велосипедов. Но иногда вместе с этим приходят и проблемы: вы не до конца понимаете, как оно работает (в случае «жирных» фреймворков типа symfony), встречаются проблемы с производительностью.
В начале статьи вы немножко бредите, приводите совсем непонятную аналогию с Pascal и Delphi, а еще зачем-то примешали C и IDE Visual Studio…
В начале статьи вы немножко бредите, приводите совсем непонятную аналогию с Pascal и Delphi, а еще зачем-то примешали C и IDE Visual Studio…
0
у меня есть свой велосипед, и другие велосипеды я смотрю только ради их изучения и дальнейшей модернизации своего велосипеда…
на счет «Все твои проекты будут иметь одну и ту же структур у файлов, что отметает вопросы типа: «Блин, куда же я закинул конфиг для БД, пол года назад, когда писал этот гребанный скрипт?!»» и «Многие функции в нем реализованы грамотнее, чем ты бы реализовал их сам.» не согласен… пусть мои проекты — мелкие и вообще кака полная, но у них у всех схожая структура и при разборке в скриптах годичной давности проблем не возникает, а на счет функций, все мы люди и все иногда пишут хрень…
на счет «Все твои проекты будут иметь одну и ту же структур у файлов, что отметает вопросы типа: «Блин, куда же я закинул конфиг для БД, пол года назад, когда писал этот гребанный скрипт?!»» и «Многие функции в нем реализованы грамотнее, чем ты бы реализовал их сам.» не согласен… пусть мои проекты — мелкие и вообще кака полная, но у них у всех схожая структура и при разборке в скриптах годичной давности проблем не возникает, а на счет функций, все мы люди и все иногда пишут хрень…
+1
Сам юзаю CI, но подумываю о переходе на другой фреймворк по одной причине — CI до сих пор ходит под 4-м пхп. А так уже без CI чувствую себя неуютно. Я готов им пользоваться уже только за его ф-и работы с БД. Как-то так…
0
С CI часто уходят на kohana, которая работает только с php5.
Правда у нее очень большие проблемы с документацией(!) и обратной совместимостью со старыми версиями, т.е. обновиться весьма проблематично.
Правда у нее очень большие проблемы с документацией(!) и обратной совместимостью со старыми версиями, т.е. обновиться весьма проблематично.
0
А вы не обращали внимания на то, что там же две ветки кода?
Если на сервере установлена пятёрка, то задействуется одна ветка, в противном случае другая.
if (floor(phpversion()) < 5)
{
load_class('Loader', FALSE);
require(BASEPATH.'codeigniter/Base4'.EXT);
}
else
{
require(BASEPATH.'codeigniter/Base5'.EXT);
}
Ничто не мешает выкинуть Base4.php и самому писать только из расчёта на пятёрку.
Если на сервере установлена пятёрка, то задействуется одна ветка, в противном случае другая.
if (floor(phpversion()) < 5)
{
load_class('Loader', FALSE);
require(BASEPATH.'codeigniter/Base4'.EXT);
}
else
{
require(BASEPATH.'codeigniter/Base5'.EXT);
}
Ничто не мешает выкинуть Base4.php и самому писать только из расчёта на пятёрку.
0
Извините, но Visual Studio — это среда разработки и инструментальные средства, а Delphi — это среда разработки и язык программирования, но никак не framework. Так что сравнение не очень удачное…
Скорее нужно привести пример всякие библиотеки и компоненты, которые программисты на VS и Delphi используют.
Скорее нужно привести пример всякие библиотеки и компоненты, которые программисты на VS и Delphi используют.
0
Я взял от CI:
1) подхватывание контроллеров из ЧПУ + возможность ре-роутинга урлов,
2) обертку над БД (пишу чистый SQL, active record не использую)
3) классы для логирования и профилирования
С этими вещами еще не разбирался, но выглядят привлекательно:
4) примочки типа базового фильтрования на предмет xss, простой типограф, еще некоторые хелперы
5) классы для доступа к ftp и xml-rpc
6) классы для отправления email, работы с сессиями, работы с календарем
7) класс-листалка, класс-простенький манипулятор над изображениями
Возможно пункты из второго списка себя не оправдают, так как в интернете достаточно много других классов, написанных с теми же целями, которые вероятно покажут себя лучше.
С хелперами для построения форм или таблиц я вообще не собираюсь связываться — это точно здец, плюс у меня объекты будут сами мапиться в формы и обратно.
Класс валидации форм оказался для меня очень простеньким, буду делать свою реализацию.
Кеширование в CI немного не такое, какое мне нужно, тоже будем писать своё.
Чего мне не хватало и я написал это сам:
1) реализация паттернов Registry и IdentityMap
2) мне нужны data-mapper`ы, как раз над ними работаю
Врезать в CI свою функцию __autoload() не составило никакого труда, так же как и пользоваться своими классами, сложенными в отдельную папочку рядом с CI. Писать свои классы как CI-библиотеки или плагины нет никакого желания, пусть они будут от него независимыми.
Итог:
1) CI дал мне несколько удобных вещей, которые мне пришлось бы реализовывать самостоятельно. Вещи эти достаточно базовые и пере-затачивание их от проекта к проекту не требуется
2) необходимые вещи я спокойно добавил в CI, трудностей не возникло
3) в CI есть вещи, которые мне не нужны или не устраивают меня, или даже бесят, но они лежат себе в файликах и меня не колышат.
Вывод:
CI вам предоставляет свой инструментарий но не ограничивает вас в его расширении сторонними разработками. Пользуйтесь ровно тем, что вам надо, на остальное забейте.
1) подхватывание контроллеров из ЧПУ + возможность ре-роутинга урлов,
2) обертку над БД (пишу чистый SQL, active record не использую)
3) классы для логирования и профилирования
С этими вещами еще не разбирался, но выглядят привлекательно:
4) примочки типа базового фильтрования на предмет xss, простой типограф, еще некоторые хелперы
5) классы для доступа к ftp и xml-rpc
6) классы для отправления email, работы с сессиями, работы с календарем
7) класс-листалка, класс-простенький манипулятор над изображениями
Возможно пункты из второго списка себя не оправдают, так как в интернете достаточно много других классов, написанных с теми же целями, которые вероятно покажут себя лучше.
С хелперами для построения форм или таблиц я вообще не собираюсь связываться — это точно здец, плюс у меня объекты будут сами мапиться в формы и обратно.
Класс валидации форм оказался для меня очень простеньким, буду делать свою реализацию.
Кеширование в CI немного не такое, какое мне нужно, тоже будем писать своё.
Чего мне не хватало и я написал это сам:
1) реализация паттернов Registry и IdentityMap
2) мне нужны data-mapper`ы, как раз над ними работаю
Врезать в CI свою функцию __autoload() не составило никакого труда, так же как и пользоваться своими классами, сложенными в отдельную папочку рядом с CI. Писать свои классы как CI-библиотеки или плагины нет никакого желания, пусть они будут от него независимыми.
Итог:
1) CI дал мне несколько удобных вещей, которые мне пришлось бы реализовывать самостоятельно. Вещи эти достаточно базовые и пере-затачивание их от проекта к проекту не требуется
2) необходимые вещи я спокойно добавил в CI, трудностей не возникло
3) в CI есть вещи, которые мне не нужны или не устраивают меня, или даже бесят, но они лежат себе в файликах и меня не колышат.
Вывод:
CI вам предоставляет свой инструментарий но не ограничивает вас в его расширении сторонними разработками. Пользуйтесь ровно тем, что вам надо, на остальное забейте.
+2
Вот лично меня, поддержка усопшего PHP4 отталкивает очень сильно от «поджыгателя» не понимаю необходимости писать костыли, выворачивать код на изнанку, отказываться от паттернов и множества других необходимых для комфортной и удобной разработки средств PHP5, а также от множества функций появившихся в 5-ке, зачем?
Большинство хостингов либо уже давно имеет в списке PHP5 либо и все равно придется в ближайшее время его установить ибо с прекращением поддержки 4-ки, любая найденная критическая уязвимость, может стать дыркой для хостера.
По моему уж лучше Zend, да он требователен к версии PHP, но это с лихвой окупается его проработкой и гибкостью его архитектуры.
Большинство хостингов либо уже давно имеет в списке PHP5 либо и все равно придется в ближайшее время его установить ибо с прекращением поддержки 4-ки, любая найденная критическая уязвимость, может стать дыркой для хостера.
По моему уж лучше Zend, да он требователен к версии PHP, но это с лихвой окупается его проработкой и гибкостью его архитектуры.
0
Sign up to leave a comment.
Почему нужно использовать php-framework’и, на примере codeigniter