Comments 12
Очень странно
Ходил слух что проект с вашей БлогСоцСистемой умер!
Занимательно — будем следить
А то приходиться пользоваться LiveStreet
Ходил слух что проект с вашей БлогСоцСистемой умер!
Занимательно — будем следить
А то приходиться пользоваться LiveStreet
Посмотрел код вашей CMS, ужас просто. C XML вы зря решили делать велосипед, смотрите лучше в сторону __sleep and __wakeup Magic Methods.
жаль, что никто пока с гуру правильного и красивого кода не написал все же такого движка. мы бы посмотрели
Хотелось бы убедиться в «ужасности» моего кода.
Удивительно, что вы хотите поговорить об этом, а не о рац. предложении, которое я высказал, видимо вам рациональность не нужно, ну да ладно, поговорим об этом.
Модуль engine/functions.php можно целиком в блог «говнокод» постить:
replace_symbols: str_replace может принимать масивы в качестве параметров и работать быстрее.
delete_comment, add_comment: почему нет классы comment, где бы еще 10 вещей можно было реализовать, еще 10 функций напишете?
my_karma, user_status, is_registered, is_admin, is_moderator: у вас же есть класс User. Опять функции?
format_time: чудные str_replace. А если у вас php будет на другой язык локализован?
count_smth: "$cnt1 " чудно
Модуль engine/functions.php можно целиком в блог «говнокод» постить:
replace_symbols: str_replace может принимать масивы в качестве параметров и работать быстрее.
delete_comment, add_comment: почему нет классы comment, где бы еще 10 вещей можно было реализовать, еще 10 функций напишете?
my_karma, user_status, is_registered, is_admin, is_moderator: у вас же есть класс User. Опять функции?
format_time: чудные str_replace. А если у вас php будет на другой язык локализован?
count_smth: "$cnt1 " чудно
А зачем, вообще, модуль что-то должен возвращать контроллеру? Это снижает гибкость, автономность и расширяемость. Скажем, потребуется у одного модуля сменить представление на использующее другой механизм. Например, шаблонизатор со Smarty перевести на XML или чистый PHP.
В твоём случае, как я понимаю, при наличии другого шаблонизатора, требуется обучить этому контроллер. Но если оторваться от одной только идеологии MVC, то в рамках объектной парадигмы, какждый объект о всех своих механизмах должен заботиться сам. Принцип «не спрашивай, приказывай». В рамках этой модели контроллер не должен спрашивать, каким шаблонизатором пользуется модель, а отдавать ей команду отрендериться.
У меня так и делается. Контроллер по ссылке находит нужную модель. В модели прописан тип рендеринга, которым она пользуется для представления. Т.е. задача контроллера состоит только в том, чтобы найти соответствующий ссылке объект, запросить у этого объекта его контент и отдать результат запросчику (в частности — браузеру).
Модуль=объект=модель уже имеет в себе описания всего, что нужно дальше. Механизм рендеринга объекта в целом (картинка это, RSS-фид или конкретный глобальный шаблон HTML-страницы, например), механизм рендеринга контентной части в случае HTML-страницы, бэкенд данных, если требуется ORM, описание модели ORM если нужно. В общем, все требуемые данные.
И замена отлаженного Smarty-шаблона на более быстрый, но менее удобный в отработке pure-PHP субшаблон будет заключаться (кроме, собственно, переписывания шаблона) в написании/замены только одной строчки в классе — собственно, указания на класс рендеринга. Контроллеру же эти тонкости до лампочки. Он не спрашивает, он приказывает :)
В твоём случае, как я понимаю, при наличии другого шаблонизатора, требуется обучить этому контроллер. Но если оторваться от одной только идеологии MVC, то в рамках объектной парадигмы, какждый объект о всех своих механизмах должен заботиться сам. Принцип «не спрашивай, приказывай». В рамках этой модели контроллер не должен спрашивать, каким шаблонизатором пользуется модель, а отдавать ей команду отрендериться.
У меня так и делается. Контроллер по ссылке находит нужную модель. В модели прописан тип рендеринга, которым она пользуется для представления. Т.е. задача контроллера состоит только в том, чтобы найти соответствующий ссылке объект, запросить у этого объекта его контент и отдать результат запросчику (в частности — браузеру).
Модуль=объект=модель уже имеет в себе описания всего, что нужно дальше. Механизм рендеринга объекта в целом (картинка это, RSS-фид или конкретный глобальный шаблон HTML-страницы, например), механизм рендеринга контентной части в случае HTML-страницы, бэкенд данных, если требуется ORM, описание модели ORM если нужно. В общем, все требуемые данные.
И замена отлаженного Smarty-шаблона на более быстрый, но менее удобный в отработке pure-PHP субшаблон будет заключаться (кроме, собственно, переписывания шаблона) в написании/замены только одной строчки в классе — собственно, указания на класс рендеринга. Контроллеру же эти тонкости до лампочки. Он не спрашивает, он приказывает :)
Если я Вас правильно понял, то в каждом модуле придется писать что-то про используемый шаблонизатор да еще и «обучить» объекты, т.е. при написании модуля все-равно придется знать, какой шаблонизатор будет использоваться. В моем случае предполагается, что у всех объектов, несущих в себе контент, будут одни и те же методы для получения этого контента (например, getValue (property)). Остается только написать интерфейс для шаблонизатора.
>Если я Вас правильно понял, то в каждом модуле придется писать что-то про используемый шаблонизатор да еще и «обучить» объекты, т.е. при написании модуля все-равно придется знать, какой шаблонизатор будет использоваться
Для типового шаблонизатора всей системы достаточно указать его тип в конфигах хоста. В конкретных классах модулей в этом случае ничего указывать не придётся. При использовании нестандартного для данной системы шаблонизатора — да, имя его класса надо будет указать явно в конкретном классе модуля и в классе конфигуратора модуля. Если в системе используется несколько разных шаблонизаторов, указание их неизбежно в любом случае.
>В моем случае предполагается, что у всех объектов, несущих в себе контент, будут одни и те же методы для получения этого контента (например, getValue (property)).
Да, но что делать, если один объект рисуется через Smarty, другой — через XML, третий — чистым PHP? Если один объект — HTML-страница, а другой — RSS-фид? В этом случае нужно явно указать особенность.
Скажем, у меня традиционно шаблонизатор по умолчанию — это Smarty. У базового для всех представляемых объектов классе base_object есть метод body_engine, который по умолчанию возвращает 'body_page' — это историческое имя Smarty-based шаблонизатора. Если шаблоны на Smarty, то мне не требуется указывать это явно. Если, скажем, нужна скорость и мы используем в качестве шаблонизатора чистый PHP, то у моего модуля переопределяется этот метод как «function body_engine() { return 'body_php'; }». И всё. После этого шаблон ищется не в одноимённом рядом лежащем с классом *.html файле с шаблоном, а в *.tpl.php :)
Для типового шаблонизатора всей системы достаточно указать его тип в конфигах хоста. В конкретных классах модулей в этом случае ничего указывать не придётся. При использовании нестандартного для данной системы шаблонизатора — да, имя его класса надо будет указать явно в конкретном классе модуля и в классе конфигуратора модуля. Если в системе используется несколько разных шаблонизаторов, указание их неизбежно в любом случае.
>В моем случае предполагается, что у всех объектов, несущих в себе контент, будут одни и те же методы для получения этого контента (например, getValue (property)).
Да, но что делать, если один объект рисуется через Smarty, другой — через XML, третий — чистым PHP? Если один объект — HTML-страница, а другой — RSS-фид? В этом случае нужно явно указать особенность.
Скажем, у меня традиционно шаблонизатор по умолчанию — это Smarty. У базового для всех представляемых объектов классе base_object есть метод body_engine, который по умолчанию возвращает 'body_page' — это историческое имя Smarty-based шаблонизатора. Если шаблоны на Smarty, то мне не требуется указывать это явно. Если, скажем, нужна скорость и мы используем в качестве шаблонизатора чистый PHP, то у моего модуля переопределяется этот метод как «function body_engine() { return 'body_php'; }». И всё. После этого шаблон ищется не в одноимённом рядом лежащем с классом *.html файле с шаблоном, а в *.tpl.php :)
ModuleResponse в какой-то мере похож на Document Object Model ;)
Sign up to leave a comment.
Ответы модулей