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

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

Когда интересно уберут полную совместимость с php4
А зачем?
Чтобы использовать все прелести ООП в php5, что вызовет большую лаконичность и прирост скорости.
Кстати, все прелести и так можете использовать. Никто не запрещает.
Kohana ваш выбор.
Ага, только кохана достаточно слабо распосранина, и решение какой-то внештатной проблемы переростает в кучку гемора.
Думаю не даром ZF отказался от его поддержки.
Ну сравните скорость ZF и CI ;)
И сравнивать нечего, Ci намного быстрее.
Не сказал бы. В ZF, на мой взгляд, код в разы более оптимизирован. Единственное, что в нем может тормозить работу — сами ограничения ООП в php5, ибо он на 100% — ООП фреймворк.
CI — самый быстрый фреймворк :)
У CI самый небольшой накладной расход из популярных PHP-фреймворков. А вот сказать, что приложение на нём быстрее, чем на Zend Framework будет нельзя. Тут уж как напишете…
не, ну это естественно. говнокод он на чем угодно говнокод
В ZF есть очень тормозные компоненты, например я в одном проекте пытался использовать Zend_Locale, чтобы выводить даты в формате типа «Пятница, 24 октября 2008». Так вот, добавление этой фичи, затормозило и так не самый простой и быстрый проект в 10 (десять!) раз, потом почитал мануал и нашел, что там можно включить кэширование промежуточных результатов, т. к. там данные читаются из огромной xml, кэширование дало суммарный прирост где-то в 3 раза, но это было все равно в 3 раза медленней, чем без форматирования дат. Причем на странице было не так много дат для форматирования. Что там так тормозило для меня до сих пор загадка.
Если грамотно собрать ядро зенда — 700Кб 1файлом вместо 8Мб(1600 файлов) + локаль. Да ещё все это под еАкселератором без архивации и все хранить в памяти. Сделать приличный кэш(кэширут он всем чем угодно и вобще все что угодно, за рееедким исключением), то вопрос спорный кто быстрее. )
Не спорю, что скорость приложения в конечном итого зависит от библиотек. НО! почему тогда все пишут ООП код, зная, что он медленнее?! Писали бы все по станике на goto: )))) было бы быстрее. Зачем вобще придумали ZF Cake CI?!

Тут есть ещё несколько показателей, кроме скорости таких как: скорость разработки, время замены модулей (к примеру, поменять способ кэширования) (длительная разработка, доработка — ваши затраты). Поддержка IDE — это удобстро и скорость разработки (отсутствие их ваши затраты). Плюс ещё некоторые моменты, позволяющие комфортно разрабатывать ПО.

На весах скорость работы и скорость разработки, комфорт разработки (цена подукта).
А можно подробно осветить вопрос как так правильно его собрать, а CI можно так собрать?
Используем get_included_files получаем все подключаемые библиотеки, затем с помошью уберутилиты от homm собираем файлик. Если используем локаль или Фиглет капчу, то их файлы кладем рядом с собранным ядором. Прирост скорости в 3-10 раз. :)
спасибо
CI собирать не особо требуется…
однако если хочется облегчить проект, то после завершения работ можно удалить неподключенные либы и хелперы
Вы все ещё пишете на PHP4? :)
Support GoPHP5.org

Поддержка старых версий убыточна.
Нет, пишем мы на PHP5 и при этом не испытываем дискомформа от того, что ядро совместимо с PHP4.
Допрошу немножко ешё. Интересно узнать каково писать на CI.
А как же нормальные оопшные интерфейсы? )
Вот такая ситуация: вы пишете какой-то проект и пришло время ставить на хост, а хостер изменил политику и отказался от мемкэша, например в пользу XCache. Это для CI критично? Сколько заимет времени замена кэшера? )
Если используя мемкеш\акселератор вы все еще хоститесь на шареде… ну я не знаю даже как прокомментировать…
Не все так плохо, как вам кажется :) Не обязательно это шара. Могут быть такие проблемы и на внутреннем сервере компании. И не обязательно с кэшем, кэш я привел для примера.
Одна типичных ситуаций из: гендир заключил договор скакой-то компанией и компания гендира будет использовать ОП по контракту (СУБД итд).
Соответственно они отказались от ПО конкурирующей компании. А мы писали под старое ПО, предполагая, что оно вечно и есть везде. (Писали под MySQL а надо будет переделать под Oracle, с СУБД не так все критично из-за ORM ActiveRecord) Да нам оплатят расходы на переделку.., но, что лучше перебить стотыщ строк кода или изменить 5 строк в конфе?! )
достаточно сменить mysqli на на oracle :) thats all.
Вы просто не пробовали… на самом деле не that's all…
Это Вы нге пробовали CI ;)
Я не просто так говорю. Из драйвера Oracle:

function db_set_charset($charset, $collation)
{
// @todo - add support if needed
return TRUE;
}
ну и? что так сложно написать одну строчку кода? там ведь ничего сложного нет. здесь любой НЕговнокодер разберется за пару минут. даже меньше :)
Я про то, что не достаточно «сменить mysqli на на oracle».
ааа :) эт верно.
Если писать под СУБД Oracle используя слой абстракции, то лучше продолжаьт писать под MySQL…
1. Пошлю такого хостера куда подальше.
2. Замена кэширования не займёт. Он у меня лично от ZF :)
а мемкеш и xcache разве одно и тоже кешируют?

memcached is a general-purpose distributed memory caching system (wiki)
XCache is a fast, stable PHP opcode cacher (xcache)
Нет, не одно.
в CodeIgniter очень хорошее разграничение между php4 и php5. А сделали они по максимуму т. к. включили и php4 и php5. Всем ведь не угодить, имхо лишнее 100Кб не жалко.
Кстати, да. Ядро там отдельное для PHP. Грузится отдельно.
Для PHP4.
Не пробовали Kohana?
К сожалению нет, будет время, обязательно поковыряю (:
Пробовали. Не понравилось тем, что нет нормальной документации и код менее оттестирован в общем.
по мне так и для ci дока не супер(слишком мало примеров использования), а в Kohana достаточно понятный код и устройство, хотя да, сыроватый(в плане логики), но достаточно стабильный чтобы использовать.
Для CI отличная дока. Сажаешь новичка, говоришь «фигачь!». Через пару часов что-то уже будет написано. С Kohana такой трюк не пройдёт…
… пока дело не дойдет написать что то большее чем hello world))
Ну, далее — это уже знание PHP и от фреймворка, если он не мешает, не зависит. За пару часов новичок в CI, писавший до этого, допустим, на чистом PHP сможет наваять, например, какую-никакую систему комментов.
если дальше знание php то зачем тогда вообще фреймворк?… его задача как раз сократить и упростить необходимый php код, если из фреймворки использовать только контролеры то проще написать небольшой скрипт для этого с нуля. А насчет доки для коханы, она хуже чем от игнитора только тем что в ней нет азов для понимания как работает mvc, а из неточностей один раз наткнулся та то что нет функии в одном хелпере, ее из доки забыли убрать(не смертельно же?).
Его первоочередная задача — не сократить код, а организовать разработчика. Знаете, как сложно скоординировать команду из 10—20 человек, не написав при этом точной документации по собственной наработке?

Документация на Kohana далеко позади самого фреймворка. Я за ней слежу.
У kohana в документации не написаны входящие параметры у многих функций, это минус.
Но у неё супераккуратный и понятный код. Это плюс.
А еще там при использовании ORM, название таблицы для модели склоняется соответственно английскому языку.
даже не знаю как вы это написали как плюс или минус, для меня лично это лишний раз напрягает мозг…
Ага, это напрягает, особенно в первый раз когда наталкиваешься.
Писавший на чистом PHР, даже знающий ООПрограммирование за 2 часа не напишет.
Проверяли? :) Если только копипастом из мануала.
Да, проверял. В системе комментариев ничего сложного, если не заниматься деталями:
Схема в БД, формочка, вывод и запись.
никто и не спорит что на словах все просто(как оказывается в последствии так же и на практике). Вот только я писал на ci после зенда(зная общую идеалогию mvc) и пользы от доки кроме как справочника(читать как списка) функций я не получил никакой.
Ну, после Zend-а не очень комфортно. Хочется то и дело влезть посмотеть что же там внутри. Если тупо делать по мануалу — получается довольно быстро.
А чем отличается от ZF? СтОит пробовать?
Если комфортно на ZF — нет. Не стоит.

Отличается внешней простотой. Меньшей гибкостью. Суперпонятной документацией.
так скоростью не отличается? CI — шустрый…
или у меня одного ZF грузится долго? или это как-то лечится?
отличается. CI — самый быстрый фреймворк. а в ЯА лечится рефакторингом кода ZF:)
Первоначальная инициализация ZF более-менее лечится слитием используемых файлов в один, отказом от автозагрузки классов. Также, немного лечится PHP 5.3 и выше.

Но до уровня скорости инициализации CI не доходит…

А вот скорость приложения уже зависит только от вас.
можно поподробней про «слитие используемых файлов в один», интересно как такое реализуется…
> Если комфортно на ZF — нет. Не стоит.

ну зачем вы так? Вы ж не знаете человека… возможно, на ci ему будет еще комфортнее
я бы сказал скорее так, если человек понял все прелести ооп(ZF) то переходить на CI ему будет сложно, в противном случае стоит попробовать CI.
Интересно быстро ли документацию на русский переведут? Как раз планировали один проект на этом фреймфорке делать.
code-igniter.ru/

«Все уже переведено до нас» :)
Спасибо, но не совсем та версия:

CodeIgniter, руководство пользователя к версии 1.6.1

о ней я знал.
не такие глобальные изменения чтобы заморачиваться на эту тему…
Антон уже занялся.
А зачем вам документация на русском?
Читать мне удобнее, хотя и могу читать на английском
супер. многое, что приходилось допиливать, теперь в коде фреймворка. i'm happy!
да! вчера обновился! С проектами написанными на предыдущей версии — проблем нет — все работает!
Пользуясь случаем, спрошу:
Как хабрапользователи CodeIgniter'а реализуют вывод и валидацию форм, если данные в форму надо при отображении подставлять из базы, а потом уже измененное валидировать?
Не очень очевидно как это делать по-нормальному, пока использую присваивание $this->validation->fieldname = $object_from_bd->fieldname, соотв-но в форме выводится сначала то что было в базе, а потом то, что передано POST'ом. С новым классом (в 1.7) вообще вывод данных в форму делается хелпером… Документацию пока подробно не просмотрел, беглый просмотр результатов не дал. Как это сделать максимально не-коряво?))
MY_Validation.php

<?php if (!defined('BASEPATH')) exit('No direct script access allowed');
class MY_Validation extends CI_Validation {
function My_Validation()
{
parent::CI_Validation();
}
function set_default_values($data, $value = null)
{
if (is_array($data) == TRUE)
{
foreach($data as $field => $value)
{
$this->$field = $value;
$_POST[$field] = $value;
}
}
else
{
$this->$data = $value;
$_POST[$data] = $value;
}
}
}
?>

Использую такой вариант, но не помню, где нашёл, кажется на форуме CI.
Просто совет обратить внимание на настройки

$db['default']['pconnect'] = FALSE;

Я не заметил, на локалке все сделал, готовый проэкт залил на сервер — через 10 минут сервер лег с 45000 коннекшинов со статусом sleep

Пока я понял в чем дело, пришлось попотеть…
А хранение сессий в сессиях так и не сделали… :(
И авторизацию давно бы пора в состав включить.
И уж хотя бы if во встроенном парсере бы не помешал.

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

Публикации

Истории