Обновить
4
0
anotherpit@anotherpit

Пользователь

Отправить сообщение
ни ваш пример, ни пример из поста не работает в opera.
а мышиные жесты к к safari прикрутить по-прежнему нельзя?
— привет, какие планы (прищур)?
— иду на каток (улыбка).
— жаль, хотел пригласить тебя в кино (слеза).

на мой взгляд, отвратительно.
похоже, в марте я поменяю телефон
{failname} — опечатка по Фрейду
начинающим разработчикам просто необходимо попрактиковаться на таких великах прежде, чем начинать от чего-то экстендиться.
про разные понятия вы, видимо, правы :-)

а того, что вы называете костылями, в коде операционных систем ничуть не меньше, чем в коде всех этих js-фреймворков и бибилиотек.

вы видели, как «крайне ограниченные средства html/css» довольно успешно используются, скажем, в extjs или в упоминавшемся выше qooxdoo?
Мне кажется, что отдавать даже несжатый css и js код клиенту за один раз проще, чем добавлять к клиенту и серверу функциональность по их подгрузке.

Зависит от сложности приложения, согласитесь.

К тому же, это нарушит чистоту архитектуры

Не то, чтобы нарушит. Дополнит, я бы сказал.

сервер может работать без изменений в коде с любым клиентом

Мы тут о разных серверах, похоже, говорим. Вы имеете в виду сервер приложения, я же в предыдущем комментарии имел в виду сервер, с которого пользователь получает клиента. Это не обязательно одно и то же.

Но, в общем, динамическая подгрузка клиента, наверное, действителньо выходит за рамки предложенной вами архитектуры и статьи, соответственно.
части клиентского кода, разумеется
Спасибо. Грамотный подход и отличная статья.

Я бы, правда, не стал ограничивать протокол общения клиента и сервера одним только JSON'ом. В больших приложениях зачастую бывает полезно докачивать CSS и JS (собственно, части клиентский код) не сразу, а по мере необходимости. Тут одним JSON'ом не обойдёшься.
поправьте заголовок — to be continueD
Этот класс _не_работает_ с нескалярными параметрами. Это сделано специально.

да, у меня мелькнуло такое подозрение. тогда стоит, наверное, в комментариях к классу сообщить об этом ограничении.
Работа с нескалярными параметрами выглядит не очень удобной:
$arrayParam = $obj->getArray();
$arrayParam['deeply']['nested']['param']['value'] = 'something';
$obj->setArray($arrayParam);

По-моему, стоит задуматься о возвращении параметров по ссылке.
ну, и я о том же: на диаграмме serialize медленне, чем json_encode, но unserialize быстрее, чем json_decode. почему ж тогда «serialize/unserialize быстрее всегда»? unserizlize быстрее всегда, да. а serialize, наоборот, медленнее всегда, получается.
Итог: serialize/unserialize быстрее всегда.

как так? у вас же на диаграмме serialize медленнее, чем json_encode.
прямо вот сейчас успешно сотрудничаем с smstraffic.ru. это как раз оно и есть.
не сбежишь — согласен. но это же ещё не повод…
тогда и на рапиду заодно
да уж, перспектива двух конкурентных веток совсем не радует

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность