Скажем так — у каждой части MVC-приложения есть вполне определённые задачи.
Модель — оперирует данными и, часто, реализует бизнес-логику.
Контроллер — Обрабатывает запросы пользователей оперируя алгоритмом (бизнес-логика — в модели) — т.е. — принимает решение: «По данным запроса — какие данные мне надо получить».
Вью (отображение) — как раз и определяет, как же будет показан набор данных, полученных от Модели.
Т.е., в идеале, логика одна (либо незначительно отличающаяся) для различных вариантов отображения (будь то REST API, ajax, либо простой http). Т.е. меняется только набор вью + некоторые части (авторизация, например, и т.д.). Таким образом — Ваш EntryPoint — всего лишь начало Dispatcher-a.
Почему использование статических классов не всегда оправдано? Тут всё проще — содержимое статического класса держится в памяти до смерти скрипта, а вот переменная, содержащая в себе инстанциированный класс, будет уничтожена как только пропадёт последняя ссылка на неё (Garbage Collector постарается — т.е. я сделаю unset переменной в которой хранился инстанс класса, в котором, в свою очередь, было поле с объектом другого класса — зачистятся оба).
П.С. — перенесите в какой-нибудь профильный блог (PHP, например — так больше народу статью увидит).
Охохо, сейчас что-то будет :)
Использование статиков не всегда оправдано — это раз.
Определение аяксовости запросов надо делать через $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest'? а не разделять по точкам входа. При этом, у Вас точка входа всё-таки одна и Вы теперь придумываете простейший роутинг (либо dispatcher, кому как нравится). При этом, ajax, json, xml и http точки входов отличаются только способом отображения (т.е. — подгружаемыми шаблонами) и их разделение — задача как раз FrontController на основе каких-либо параметров, а не Dispatcher.
Реквестирую убунту для таблеток:
1. Чтоб не кушала аккумулятор, приостанавливая процессор, шину и т.п. в ненапряжные моменты
2. Чтоб контекстные меню и кнопочки маленькие стали побольше
3. Рабочий стол, как был в Netbook Remix — оставить. Удобная проекция главного меню на рабочий стол
4. Чтобы всё это добро не тормозило на тегре либо на арме
Забавно в нём только использование плюшек PHP5. Как таковой код ооочень врядли кто-то будет брать в проект — риск потратить время и силы на внедрение непонятного велик. А так — у каждого в загашнике есть свой валидатор — вылизанный и известный до последней строки.
Кстати, во фронт-контроллере можно удачно отдетектить браузер и для класса вью поставить глобальный префикс для путей (например, mobile/, pc/, tablet/ и т.д.)
.delegate() — самое то. C .live() есть проблемы (с контекстом). onHashChanged тут какбе и не надо — один раз заменить ссылки, а потом заменять перед вставкой контента. Тогда через .delegate() мы будем ловить клики, а вот onHashChange() уже и не понадобится.
Вот блин. Где взять Windows Phone 7 аппарат по лояльной цене? Вот в чём вопрос.
По сути — что-то нет в массовых СМИ либо в оффлайне рекламы: «Купите ХХХ ххх 7 в любом магазине „Евросети“ (не реклама) и т.д. Как простой обыватель, который должен купить Ваше приложение, купив перед этим аппарат, КУПИТ ЕГО? Нечего покупать. Смартфонов нет, Windows-окружения нет (я не про ОС, я про LiveID и т.д.) — что делать обывателю? Покупать HTC на андроиде либо iPhone на iOS.
Как же двигать новую платформу? Почему моя жена как обыватель о ней ничего не знает? Где Вам, господа разработчики, брать денег если нет продаж (равно как и устройств на данной платформе в свободном обращении)?
Зато Бесу было интересно.
Он жил на его левом плече. Маленькая, сантиметров в десять, цветная
татуировка. Бесенок с вилами в руках, хмуро и придирчиво всматривающийся
куда-то вдаль. Длинный хвост Беса был обмотан вокруг пояса, наверное,
чтобы не путался под ногами. Короткая серая шерстка походила на мохнатый
обтягивающий комбинезон.
Некоторое время Алекс придирчиво всматривался в мордочку Беса.
Мордочка была любопытная и довольно-таки спокойная. Самоуверенная.
Если чего не так:
1. Лог пустой;
2. Неправильное форматирование;
2.1. Нет номера тикета вначале лога;
2.2. Присутствуют символы, отличные от английского алфавита, цифр и т.д.;
3. Придумать самим.
У нас, например, для интеграции с TRAC вначале лога должен быть номер issue (не знаю как точно перевести). Плюс у каждой команды/проекта/организации может быть соглашение об именовании для логов в коммитах.
Также, я пока совсем не понимаю — НА ЧТО изменит комментарий бездушная машина :) Для меня алгоритм работы с «плохим» комментарием, который нужно изменить: просто не провести коммит. А автору коммита уже какбе должно быть понятно — на что менять и т.д. :)
Модель — оперирует данными и, часто, реализует бизнес-логику.
Контроллер — Обрабатывает запросы пользователей оперируя алгоритмом (бизнес-логика — в модели) — т.е. — принимает решение: «По данным запроса — какие данные мне надо получить».
Вью (отображение) — как раз и определяет, как же будет показан набор данных, полученных от Модели.
Т.е., в идеале, логика одна (либо незначительно отличающаяся) для различных вариантов отображения (будь то REST API, ajax, либо простой http). Т.е. меняется только набор вью + некоторые части (авторизация, например, и т.д.). Таким образом — Ваш EntryPoint — всего лишь начало Dispatcher-a.
Почему использование статических классов не всегда оправдано? Тут всё проще — содержимое статического класса держится в памяти до смерти скрипта, а вот переменная, содержащая в себе инстанциированный класс, будет уничтожена как только пропадёт последняя ссылка на неё (Garbage Collector постарается — т.е. я сделаю unset переменной в которой хранился инстанс класса, в котором, в свою очередь, было поле с объектом другого класса — зачистятся оба).
П.С. — перенесите в какой-нибудь профильный блог (PHP, например — так больше народу статью увидит).
Использование статиков не всегда оправдано — это раз.
Определение аяксовости запросов надо делать через $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest'? а не разделять по точкам входа. При этом, у Вас точка входа всё-таки одна и Вы теперь придумываете простейший роутинг (либо dispatcher, кому как нравится). При этом, ajax, json, xml и http точки входов отличаются только способом отображения (т.е. — подгружаемыми шаблонами) и их разделение — задача как раз FrontController на основе каких-либо параметров, а не Dispatcher.
Не файл и не директория (там может быть свой index.php|html|htm e.t.c.) — тогда вам на index.php.
А по сути — Вы только что процитировали практически любой MVC-фреймворк: ZF, CodeIgniter, Kohana, CakePHP, Yui, Symfony и так далее
1. Чтоб не кушала аккумулятор, приостанавливая процессор, шину и т.п. в ненапряжные моменты
2. Чтоб контекстные меню и кнопочки маленькие стали побольше
3. Рабочий стол, как был в Netbook Remix — оставить. Удобная проекция главного меню на рабочий стол
4. Чтобы всё это добро не тормозило на тегре либо на арме
Замечтался я что-то.
Фича поистине чудеснейшая. А то я задолбался уже console.log() или sys.puts() расставлять по коду :)
По сути — что-то нет в массовых СМИ либо в оффлайне рекламы: «Купите ХХХ ххх 7 в любом магазине „Евросети“ (не реклама) и т.д. Как простой обыватель, который должен купить Ваше приложение, купив перед этим аппарат, КУПИТ ЕГО? Нечего покупать. Смартфонов нет, Windows-окружения нет (я не про ОС, я про LiveID и т.д.) — что делать обывателю? Покупать HTC на андроиде либо iPhone на iOS.
Как же двигать новую платформу? Почему моя жена как обыватель о ней ничего не знает? Где Вам, господа разработчики, брать денег если нет продаж (равно как и устройств на данной платформе в свободном обращении)?
Он жил на его левом плече. Маленькая, сантиметров в десять, цветная
татуировка. Бесенок с вилами в руках, хмуро и придирчиво всматривающийся
куда-то вдаль. Длинный хвост Беса был обмотан вокруг пояса, наверное,
чтобы не путался под ногами. Короткая серая шерстка походила на мохнатый
обтягивающий комбинезон.
Некоторое время Алекс придирчиво всматривался в мордочку Беса.
Мордочка была любопытная и довольно-таки спокойная. Самоуверенная.
С. Лукьяненко. Геном.
1. Лог пустой;
2. Неправильное форматирование;
2.1. Нет номера тикета вначале лога;
2.2. Присутствуют символы, отличные от английского алфавита, цифр и т.д.;
3. Придумать самим.
У нас, например, для интеграции с TRAC вначале лога должен быть номер issue (не знаю как точно перевести). Плюс у каждой команды/проекта/организации может быть соглашение об именовании для логов в коммитах.
Также, я пока совсем не понимаю — НА ЧТО изменит комментарий бездушная машина :) Для меня алгоритм работы с «плохим» комментарием, который нужно изменить: просто не провести коммит. А автору коммита уже какбе должно быть понятно — на что менять и т.д. :)