Комментарии 80
Дождались =)
Когда интересно уберут полную совместимость с php4
А зачем?
Чтобы использовать все прелести ООП в php5, что вызовет большую лаконичность и прирост скорости.
Думаю не даром ZF отказался от его поддержки.
Ну сравните скорость ZF и CI ;)
И сравнивать нечего, Ci намного быстрее.
Не сказал бы. В ZF, на мой взгляд, код в разы более оптимизирован. Единственное, что в нем может тормозить работу — сами ограничения ООП в php5, ибо он на 100% — ООП фреймворк.
CI — самый быстрый фреймворк :)
В ZF есть очень тормозные компоненты, например я в одном проекте пытался использовать Zend_Locale, чтобы выводить даты в формате типа «Пятница, 24 октября 2008». Так вот, добавление этой фичи, затормозило и так не самый простой и быстрый проект в 10 (десять!) раз, потом почитал мануал и нашел, что там можно включить кэширование промежуточных результатов, т. к. там данные читаются из огромной xml, кэширование дало суммарный прирост где-то в 3 раза, но это было все равно в 3 раза медленней, чем без форматирования дат. Причем на странице было не так много дат для форматирования. Что там так тормозило для меня до сих пор загадка.
Если грамотно собрать ядро зенда — 700Кб 1файлом вместо 8Мб(1600 файлов) + локаль. Да ещё все это под еАкселератором без архивации и все хранить в памяти. Сделать приличный кэш(кэширут он всем чем угодно и вобще все что угодно, за рееедким исключением), то вопрос спорный кто быстрее. )
Не спорю, что скорость приложения в конечном итого зависит от библиотек. НО! почему тогда все пишут ООП код, зная, что он медленнее?! Писали бы все по станике на goto: )))) было бы быстрее. Зачем вобще придумали ZF Cake CI?!
Тут есть ещё несколько показателей, кроме скорости таких как: скорость разработки, время замены модулей (к примеру, поменять способ кэширования) (длительная разработка, доработка — ваши затраты). Поддержка IDE — это удобстро и скорость разработки (отсутствие их ваши затраты). Плюс ещё некоторые моменты, позволяющие комфортно разрабатывать ПО.
На весах скорость работы и скорость разработки, комфорт разработки (цена подукта).
Не спорю, что скорость приложения в конечном итого зависит от библиотек. НО! почему тогда все пишут ООП код, зная, что он медленнее?! Писали бы все по станике на goto: )))) было бы быстрее. Зачем вобще придумали ZF Cake CI?!
Тут есть ещё несколько показателей, кроме скорости таких как: скорость разработки, время замены модулей (к примеру, поменять способ кэширования) (длительная разработка, доработка — ваши затраты). Поддержка IDE — это удобстро и скорость разработки (отсутствие их ваши затраты). Плюс ещё некоторые моменты, позволяющие комфортно разрабатывать ПО.
На весах скорость работы и скорость разработки, комфорт разработки (цена подукта).
А можно подробно осветить вопрос как так правильно его собрать, а CI можно так собрать?
Используем get_included_files получаем все подключаемые библиотеки, затем с помошью уберутилиты от homm собираем файлик. Если используем локаль или Фиглет капчу, то их файлы кладем рядом с собранным ядором. Прирост скорости в 3-10 раз. :)
CI собирать не особо требуется…
однако если хочется облегчить проект, то после завершения работ можно удалить неподключенные либы и хелперы
Нет, пишем мы на PHP5 и при этом не испытываем дискомформа от того, что ядро совместимо с PHP4.
Допрошу немножко ешё. Интересно узнать каково писать на CI.
А как же нормальные оопшные интерфейсы? )
Вот такая ситуация: вы пишете какой-то проект и пришло время ставить на хост, а хостер изменил политику и отказался от мемкэша, например в пользу XCache. Это для CI критично? Сколько заимет времени замена кэшера? )
А как же нормальные оопшные интерфейсы? )
Вот такая ситуация: вы пишете какой-то проект и пришло время ставить на хост, а хостер изменил политику и отказался от мемкэша, например в пользу XCache. Это для CI критично? Сколько заимет времени замена кэшера? )
Если используя мемкеш\акселератор вы все еще хоститесь на шареде… ну я не знаю даже как прокомментировать…
Не все так плохо, как вам кажется :) Не обязательно это шара. Могут быть такие проблемы и на внутреннем сервере компании. И не обязательно с кэшем, кэш я привел для примера.
Одна типичных ситуаций из: гендир заключил договор скакой-то компанией и компания гендира будет использовать ОП по контракту (СУБД итд).
Соответственно они отказались от ПО конкурирующей компании. А мы писали под старое ПО, предполагая, что оно вечно и есть везде. (Писали под MySQL а надо будет переделать под Oracle, с СУБД не так все критично из-за ORM ActiveRecord) Да нам оплатят расходы на переделку.., но, что лучше перебить стотыщ строк кода или изменить 5 строк в конфе?! )
Одна типичных ситуаций из: гендир заключил договор скакой-то компанией и компания гендира будет использовать ОП по контракту (СУБД итд).
Соответственно они отказались от ПО конкурирующей компании. А мы писали под старое ПО, предполагая, что оно вечно и есть везде. (Писали под MySQL а надо будет переделать под Oracle, с СУБД не так все критично из-за ORM ActiveRecord) Да нам оплатят расходы на переделку.., но, что лучше перебить стотыщ строк кода или изменить 5 строк в конфе?! )
достаточно сменить mysqli на на oracle :) thats all.
Вы просто не пробовали… на самом деле не that's all…
Если писать под СУБД Oracle используя слой абстракции, то лучше продолжаьт писать под MySQL…
1. Пошлю такого хостера куда подальше.
2. Замена кэширования не займёт. Он у меня лично от ZF :)
2. Замена кэширования не займёт. Он у меня лично от ZF :)
в CodeIgniter очень хорошее разграничение между php4 и php5. А сделали они по максимуму т. к. включили и php4 и php5. Всем ведь не угодить, имхо лишнее 100Кб не жалко.
Не пробовали Kohana?
Пробовали. Не понравилось тем, что нет нормальной документации и код менее оттестирован в общем.
по мне так и для ci дока не супер(слишком мало примеров использования), а в Kohana достаточно понятный код и устройство, хотя да, сыроватый(в плане логики), но достаточно стабильный чтобы использовать.
Для CI отличная дока. Сажаешь новичка, говоришь «фигачь!». Через пару часов что-то уже будет написано. С Kohana такой трюк не пройдёт…
… пока дело не дойдет написать что то большее чем hello world))
Ну, далее — это уже знание PHP и от фреймворка, если он не мешает, не зависит. За пару часов новичок в CI, писавший до этого, допустим, на чистом PHP сможет наваять, например, какую-никакую систему комментов.
если дальше знание php то зачем тогда вообще фреймворк?… его задача как раз сократить и упростить необходимый php код, если из фреймворки использовать только контролеры то проще написать небольшой скрипт для этого с нуля. А насчет доки для коханы, она хуже чем от игнитора только тем что в ней нет азов для понимания как работает mvc, а из неточностей один раз наткнулся та то что нет функии в одном хелпере, ее из доки забыли убрать(не смертельно же?).
Его первоочередная задача — не сократить код, а организовать разработчика. Знаете, как сложно скоординировать команду из 10—20 человек, не написав при этом точной документации по собственной наработке?
Документация на Kohana далеко позади самого фреймворка. Я за ней слежу.
Документация на Kohana далеко позади самого фреймворка. Я за ней слежу.
А еще там при использовании ORM, название таблицы для модели склоняется соответственно английскому языку.
Писавший на чистом PHР, даже знающий ООПрограммирование за 2 часа не напишет.
Проверяли? :) Если только копипастом из мануала.
Проверяли? :) Если только копипастом из мануала.
Да, проверял. В системе комментариев ничего сложного, если не заниматься деталями:
Схема в БД, формочка, вывод и запись.
Схема в БД, формочка, вывод и запись.
никто и не спорит что на словах все просто(как оказывается в последствии так же и на практике). Вот только я писал на ci после зенда(зная общую идеалогию mvc) и пользы от доки кроме как справочника(читать как списка) функций я не получил никакой.
А чем отличается от ZF? СтОит пробовать?
Если комфортно на ZF — нет. Не стоит.
Отличается внешней простотой. Меньшей гибкостью. Суперпонятной документацией.
Отличается внешней простотой. Меньшей гибкостью. Суперпонятной документацией.
так скоростью не отличается? CI — шустрый…
или у меня одного ZF грузится долго? или это как-то лечится?
или у меня одного ZF грузится долго? или это как-то лечится?
отличается. CI — самый быстрый фреймворк. а в ЯА лечится рефакторингом кода ZF:)
Первоначальная инициализация ZF более-менее лечится слитием используемых файлов в один, отказом от автозагрузки классов. Также, немного лечится PHP 5.3 и выше.
Но до уровня скорости инициализации CI не доходит…
А вот скорость приложения уже зависит только от вас.
Но до уровня скорости инициализации CI не доходит…
А вот скорость приложения уже зависит только от вас.
можно поподробней про «слитие используемых файлов в один», интересно как такое реализуется…
Выше ссылку дали.
> Если комфортно на ZF — нет. Не стоит.
ну зачем вы так? Вы ж не знаете человека… возможно, на ci ему будет еще комфортнее
ну зачем вы так? Вы ж не знаете человека… возможно, на ci ему будет еще комфортнее
Интересно быстро ли документацию на русский переведут? Как раз планировали один проект на этом фреймфорке делать.
супер. многое, что приходилось допиливать, теперь в коде фреймворка. i'm happy!
да! вчера обновился! С проектами написанными на предыдущей версии — проблем нет — все работает!
Ура! *тихонько радуется*
Пользуясь случаем, спрошу:
Как хабрапользователи CodeIgniter'а реализуют вывод и валидацию форм, если данные в форму надо при отображении подставлять из базы, а потом уже измененное валидировать?
Не очень очевидно как это делать по-нормальному, пока использую присваивание $this->validation->fieldname = $object_from_bd->fieldname, соотв-но в форме выводится сначала то что было в базе, а потом то, что передано POST'ом. С новым классом (в 1.7) вообще вывод данных в форму делается хелпером… Документацию пока подробно не просмотрел, беглый просмотр результатов не дал. Как это сделать максимально не-коряво?))
Как хабрапользователи 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.
<?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
Пока я понял в чем дело, пришлось попотеть…
$db['default']['pconnect'] = FALSE;
Я не заметил, на локалке все сделал, готовый проэкт залил на сервер — через 10 минут сервер лег с 45000 коннекшинов со статусом sleep
Пока я понял в чем дело, пришлось попотеть…
А хранение сессий в сессиях так и не сделали… :(
И авторизацию давно бы пора в состав включить.
И уж хотя бы if во встроенном парсере бы не помешал.
Но все равно хорошо, что развивается. Люблю я его, а все нужное можно и плагинами добить.
И авторизацию давно бы пора в состав включить.
И уж хотя бы if во встроенном парсере бы не помешал.
Но все равно хорошо, что развивается. Люблю я его, а все нужное можно и плагинами добить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CodeIgniter 1.7.0