реально такая нумерация нужна была для IE6-7 и частично 8, когда IE выдает JS ошибку и ты пытаешься понять — в каком файле и какая строчка, а для FF это действительно не проблема — консоль Firebug'a дает достаточно информации
а как насчет того, чтобы объявить как deprecated все реализации строк, кроме одной и выдавать ошибки компиляции при использовании старой реализации? ;)
Сам всегда писал скрипты обновления ручками и также отказывался от откатов. При этом старался запланировать обновление структуры так, чтобы не требовалось обновления кода или оно было минимальным, тогда при выкатке кода — код можно откатить обратно или в случае экстренной правки не требуется думать о том — есть ли поле или нет.
я использую MC, чтобы побегать по каталогам проекта, осознать его структуру в тех случаях, когда копировать его к себе долго и все надеюсь, что сделают использование кнопок PageUp/PageDown по умолчанию, переход по ALT+буква, выделение файлов, т.е. более похожим на фар
Если взять любой ORM для PHP или NET, то по сравнению с Rails проблемы следующие:
* Код компактно не получится написать
* Сложные запросы не получится написать. Все может сломаться уже на запросе вида a=b and (c=d OR c=e), не говоря о having count или order by вычисляемое поле. Приходится переходить на полностью написанный свой SQL код.
* Из своего SQL запроса, написанного без использования ORM к одной таблице, нельзя получить стандартный объект ORM. Т.е запросы
member = Member.ById(param_id)
и
member = Member.sql('SELECT * FROM member WHERE id = ?', param_id)
не будут равноценны. Второй запрос может выдать просто массив.
* Если мы создаем модель Member, то методы взаимодействия с базой данных находятся в ORM и приходится под каждый чих создавать свой метод в модели Member типа
function Member::ById(param_id)
{
connection = ORM::get_connection();
connection.get_table('member')->where('id = ?', param_id);
}
т.е. по сути получается 2 модели — одна для обычных запросов (CRUD логики), вторая для нестанартной бизнес-логики
* очень часто нужно либо хранить структуру базы в виде XML конфигов, моделей, либо при вызове ORM прописывать типы для значений, которые передаешь (характерно для NET)
меня волнует вопрос — выйдет релиз IE9 и через пару месяцев найдут там багу — типа селектор :first не поддерживается и ждать нам х лет следующего браузера как с border-raidius?
собственно ответ известен — MS не выпускала корректирующих патчей по ошибкам верстки и в результате ошибки стали стандартом — удваивается margin-left в IE6 при float:left, ок будем стараться делать его по-другому, не поддерживается border-radius — ок, будем делать картинки для уголков и т.д.
> использовать доступ к глобальному массиву с метода action — это нехорошо, думаю, с точки
> зрения безопасности.
1. мне не доступ к глобальному массиву нужен, а список входных параметров. А других путей кроме как сделать это через глобальный массив, с точки зрения простоты синтаксиса, я не вижу.
2. с точки зрения безопасности весь этот массив входных параметров можно прогнать через stripTags функцию где-нибудь в dispatch методе
3. $this->getParameter мне тоже не нравится :),… этой функцией предполагается пользоваться к каждом методе контроллера
if ($u = User::get_by_id($this->getParameter('id')){… }
а визуально лучше
if ($u = User::get_by_id($param['id']){… }
не в курсе — есть ли где-то реальные истории про создание веб-приложений, которые блокируют доступ, если х попыток получить доступ для такого логина, y попыток восстановить пароль, z запросов с такого-то IP и так далее
почему нельзя иметь глобальный массив params, заполняемый где-то раньше и доступный как
$limit = $params['max'];
мне кажется конструкция
$this->container->request->getParameter
подчеркивает красоту ОО структуры классов и структуризации, но очень неудобна, когда ты пишешь код (5-10 строк) внутри метода контроллера ибо занимает слишком много места
У ТКС — 2%, минимум 150 руб., т.е. 6 000 при снятии 300 000
У связного — 0,3% (мин. 25 руб., макс. 1000 руб.), при переводе через Связной
но мне кажется у них тоже есть особый тариф для таких операций
По альфе не могу понять где это у них запрятано
Если взять любой ORM для PHP или NET, то по сравнению с Rails проблемы следующие:
* Код компактно не получится написать
* Сложные запросы не получится написать. Все может сломаться уже на запросе вида a=b and (c=d OR c=e), не говоря о having count или order by вычисляемое поле. Приходится переходить на полностью написанный свой SQL код.
* Из своего SQL запроса, написанного без использования ORM к одной таблице, нельзя получить стандартный объект ORM. Т.е запросы
member = Member.ById(param_id)
и
member = Member.sql('SELECT * FROM member WHERE id = ?', param_id)
не будут равноценны. Второй запрос может выдать просто массив.
* Если мы создаем модель Member, то методы взаимодействия с базой данных находятся в ORM и приходится под каждый чих создавать свой метод в модели Member типа
function Member::ById(param_id)
{
connection = ORM::get_connection();
connection.get_table('member')->where('id = ?', param_id);
}
т.е. по сути получается 2 модели — одна для обычных запросов (CRUD логики), вторая для нестанартной бизнес-логики
* очень часто нужно либо хранить структуру базы в виде XML конфигов, моделей, либо при вызове ORM прописывать типы для значений, которые передаешь (характерно для NET)
собственно ответ известен — MS не выпускала корректирующих патчей по ошибкам верстки и в результате ошибки стали стандартом — удваивается margin-left в IE6 при float:left, ок будем стараться делать его по-другому, не поддерживается border-radius — ок, будем делать картинки для уголков и т.д.
User.active
то аналогичный код в PHP/Zend будет выглядеть в 2 строки
$u = User.new
$u->select()->active();
> зрения безопасности.
1. мне не доступ к глобальному массиву нужен, а список входных параметров. А других путей кроме как сделать это через глобальный массив, с точки зрения простоты синтаксиса, я не вижу.
2. с точки зрения безопасности весь этот массив входных параметров можно прогнать через stripTags функцию где-нибудь в dispatch методе
3. $this->getParameter мне тоже не нравится :),… этой функцией предполагается пользоваться к каждом методе контроллера
if ($u = User::get_by_id($this->getParameter('id')){… }
а визуально лучше
if ($u = User::get_by_id($param['id']){… }
было бы интересно почитать
$limit = $this->container->request->getParameter('max');
почему нельзя иметь глобальный массив params, заполняемый где-то раньше и доступный как
$limit = $params['max'];
мне кажется конструкция
$this->container->request->getParameter
подчеркивает красоту ОО структуры классов и структуризации, но очень неудобна, когда ты пишешь код (5-10 строк) внутри метода контроллера ибо занимает слишком много места
1. компонента привязана к FileStore, что недопустимо при работе на кластере
2. Yadis в недрах своих хочет массив сессий, что тоже недопустимо при работе на кластере
а в целом понятно написано