Примеси
… при желании мы можем вообще не использовать прототипы
На выполнение конструкций вида this.property = value; требуется время. Поэтому, чем больше объектов в системе и чем сложнее функции-конструкторы этих объектов, тем медленнее будет работать наш код.
Лучше всё таки использовать прототипы, либо говорить про подобные «примеси» с оговоркой на скорость.
> > языке есть 3 типа данных, которые действительно являются полноправными объектами
> а как же RegExp, Node, Arguments..?
Имхо, всё, что имеет свойство constructor и не является скалярным значением — полноправный объект.
Например, DOM-элемент в IE — это не-полноправный объект =)
В кеше лежат отдельные объекты, а при выборке одним sql-запросом мы не знаем какие объекты закешированы, а какие нет — теряется смысл кеша.
Именно поэтому вы и не сможете уйти от ста (или тысяч ?) запросов к кэшу/БД.
Имхо:
Вы не то кэшируете. Запись таблицы — слишком маленькая сущность, чтобы быть закэшированной.
Если вы от этого не откажетесь, именно в «социальных сетях и интернет-сообществах» ваши принципы кэширования проявят себя с отрицательной строны. Правда, если откажетесь — придётся всё переделывать.
Имхо, в каждом отдельном случае должны быть свои проверки.
if (!method_exists($this->modules[$moduleName]['object'], $method))
throw new CoreException (lang('error_controller_module_return_invalid_object','core'));
Если похачит верстальщик, то программист (опять же) потом сделает новый контроллер (если будет нужно). И переделывать не придётся, если в задаче будет чётко прописана структура данных.
Вобщем, если что-то сделано неправильно на «первых шагах» пути, то всё равно придётся переделывать все остальные шаги.
PS Мы друг друга не переспорим =) Ты говоришь, что некоторые ошибки — «почти фатальны», а я говорю, что большинство ошибок «легко исправимы». Я с тобой в принципе согласен, но считаю, что многое зависит от организации работы. Если у меня всё получится сделать — всё будет хорошо, если нет — ну чтож теперь поделаешь… =)
Ну я не спорю с тем, что разработка — циклична. Но мне цикличность не нравится и я хочу свести её к минимуму.
> возможность быстро похачить приложение
В каждом есть хотябы чуть-чуть дурака: например, программер может сделать тоже самое, что и верстак + к тому: команда — она на то и команда, чтобы иметь и пользоваться возможностью общаться друг с другом.
Это понятно, что всех «наших» можно обернуть словом «комманда», а менеджер и клиент — как бы в стороне. Но противоречий всё равно нет: последовательность действий команды должна идти строго к клиенту, по возможности не возвращаясь к предыдущим шагам.
Мой вариант последовательности мне кажется оптимальным.
А мне всегда казалось, что это наоборот — хорошо. Программист должен быть прокладкой между БД и верстальщиком, Верстальщик — между программистом и манагером, а Манагер — между верстальщиком и клиентом (дизайнеры-враги-человечества как бы в стороне: они не прокладки =))
Так можно разделить зоны ответственности и достичь строго последовательного выполнения задачи, что в итоге приведёт к сокращению времени разработки.
> В чем трудность использовать JSON?
Трудность — в проблеме №3 =) Если отказаться от её решения, то от схемы на картинке придётся так же отказатся и подгружать аяксом не «данные+шаблон», а «text/html» (а это мне не нравится — не красиво как-то)
У меня, видимо, не получится сначала собрать все данные «страницы», а уже потом — наложить XSL: я хочу, чтобы клиент обращался не к странице, а к Resource (что-то типа RESTful, только без HTTP-методов PUT и DELETE)
А, обращаясь к объекту, можно выбрать только данные объекта =) Дополнительные объекты для сборки страницы должны быть добавлены уже внутри шаблона.
А XSL на клиенте я использовать не могу: я его просто не знаю =(
Лучше всё таки использовать прототипы, либо говорить про подобные «примеси» с оговоркой на скорость.
> а как же RegExp, Node, Arguments..?
Имхо, всё, что имеет свойство constructor и не является скалярным значением — полноправный объект.
Например, DOM-элемент в IE — это не-полноправный объект =)
Что лучше Объект «100 Комментариев» или 100 Объектов «Комментарий»?
Именно поэтому вы и не сможете уйти от ста (или тысяч ?) запросов к кэшу/БД.
Имхо:
Вы не то кэшируете. Запись таблицы — слишком маленькая сущность, чтобы быть закэшированной.
Если вы от этого не откажетесь, именно в «социальных сетях и интернет-сообществах» ваши принципы кэширования проявят себя с отрицательной строны. Правда, если откажетесь — придётся всё переделывать.
Ещё можно посмотреть в сторону Reflection
Давайте незачётку! eval без должной фильтрации запроса до добра не доведёт =)
А ещё: подскажите, пожалуйста, где у вас там находится место, в котором происходят выборки объектов (из кэша, а если нет — из таблиц)
Вобщем, если что-то сделано неправильно на «первых шагах» пути, то всё равно придётся переделывать все остальные шаги.
PS Мы друг друга не переспорим =) Ты говоришь, что некоторые ошибки — «почти фатальны», а я говорю, что большинство ошибок «легко исправимы». Я с тобой в принципе согласен, но считаю, что многое зависит от организации работы. Если у меня всё получится сделать — всё будет хорошо, если нет — ну чтож теперь поделаешь… =)
> возможность быстро похачить приложение
В каждом есть хотябы чуть-чуть дурака: например, программер может сделать тоже самое, что и верстак + к тому: команда — она на то и команда, чтобы иметь и пользоваться возможностью общаться друг с другом.
В любом случае — нет в мире совершенства.
Мой вариант последовательности мне кажется оптимальным.
Так можно разделить зоны ответственности и достичь строго последовательного выполнения задачи, что в итоге приведёт к сокращению времени разработки.
А я думал, что заговор раскрыл. Отбой =)
>… но он явно быстрее подгрузки XML-таблиц прямо в XSLT через document()
А это действительно на существенно быстрее?
PS Кстати, Explay3 на UMI.CMS чем-то похожа (как мне показалось)
Так то он так. Но в моём варианте есть 2 контроллера, а в твоём — 3 (третий объединяет данные первых двух)
+ к тому, для введения спец.контроллера нужно 2 человека: программист-моделей-и-контроллеров и верстальщик, а без него — нужен только верстальщик =)
Трудность — в проблеме №3 =) Если отказаться от её решения, то от схемы на картинке придётся так же отказатся и подгружать аяксом не «данные+шаблон», а «text/html» (а это мне не нравится — не красиво как-то)
Но есть «Проблема №3» — не хватает алгоритма.
А в код сериализатора я, пожалуй, подсмотрю =)
Сейчас у меня есть только данные: restful.joos.nnov.ru/a0/data/index.xml (а это HTML: restful.joos.nnov.ru/a0/data/index.html)
А потом всё это должно быть вставлено в конечную HTML-страницу: restful.joos.nnov.ru/a0/index.html
(там — полная абстракция =)
А, обращаясь к объекту, можно выбрать только данные объекта =) Дополнительные объекты для сборки страницы должны быть добавлены уже внутри шаблона.
А XSL на клиенте я использовать не могу: я его просто не знаю =(