Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 208
Все б так «Пиарились» принося пользу новичкам и бывалым…
Вполне себе интересная статья. Спасибо.
Вполне себе интересная статья. Спасибо.
Заметил, что последнее время пост о велосипеде начинается с его картинки (: Ну да ладно, демка будет? Какие модули уже есть? Какие нибудь цифры по скорости генерирования страниц?
Краткое описание имеющийся модулей можно посмотреть вот тут
Демка будет непременно в ближайшее время. Понимаю что мало кому захочется ставить систему просто «чтобы посмотреть».
Для примера, главная страница генерируется 0,044 сек. из них php — 0,04. На более бодром сервере время уменьшается почти вдвое.
Демка будет непременно в ближайшее время. Понимаю что мало кому захочется ставить систему просто «чтобы посмотреть».
Для примера, главная страница генерируется 0,044 сек. из них php — 0,04. На более бодром сервере время уменьшается почти вдвое.
Сходил проверил — про два раза я даже наврал:
Время генерации: 0.008 сек., PHP: 0.008 сек., SQL: 0.000 сек. при 4 запросах
Время генерации: 0.008 сек., PHP: 0.008 сек., SQL: 0.000 сек. при 4 запросах
Вы заставили меня проверить )
Скачал стабильную версию, начал ставить. Первая ошибка «SQL Error: Field 'last_ip' doesn't have a default value» пришлось править kernel.sql и install/index.php. Всякое бывает идем дальше.
Установил. Перешел на главную страницу, тут лично мое мнение — когда будете делать демо версию найдите приличный дизайн, ну очень все скупо сейчас…
Собственно перехожу к скорости генерации. Железо мое core duo 1.73 / 2 гига оперативы, я не знаю на чем тестили Вы, но у меня средняя скорость: 0.25 сек / 10-12 запросов sql(0.039 сек примерно)
Хочу заметить маленькую деталь, если замеряете время рендеринга страницы то ставьте «секундомер» в самом начале скрипта, а не в подключаемом файле после старта сессии(для честности).
Пытался поставить на свой сервак, но там вообще не удалось запустить. Class 'LabVars' not found. Вечером может посмотрю почему так.
Для статической страницы, с выводом меню и текста имхо 42 подключаемых файла многовато будет.
В общем желаю удачи в развитии (:
Скачал стабильную версию, начал ставить. Первая ошибка «SQL Error: Field 'last_ip' doesn't have a default value» пришлось править kernel.sql и install/index.php. Всякое бывает идем дальше.
Установил. Перешел на главную страницу, тут лично мое мнение — когда будете делать демо версию найдите приличный дизайн, ну очень все скупо сейчас…
Собственно перехожу к скорости генерации. Железо мое core duo 1.73 / 2 гига оперативы, я не знаю на чем тестили Вы, но у меня средняя скорость: 0.25 сек / 10-12 запросов sql(0.039 сек примерно)
Хочу заметить маленькую деталь, если замеряете время рендеринга страницы то ставьте «секундомер» в самом начале скрипта, а не в подключаемом файле после старта сессии(для честности).
Пытался поставить на свой сервак, но там вообще не удалось запустить. Class 'LabVars' not found. Вечером может посмотрю почему так.
Для статической страницы, с выводом меню и текста имхо 42 подключаемых файла многовато будет.
В общем желаю удачи в развитии (:
Первый результат я получил на четырехядерном Xeon E5430 2.66GHz.
Во втором случае было «что-то шестиядерное» + memcache:)
Скорее всего, Ваши результаты связаны с тем, что по умолчанию после установки включен режим отладки, который полностью подавляет любое промежуточное кэширование на всех этапах.
Спасибо за пожелание!
Во втором случае было «что-то шестиядерное» + memcache:)
Скорее всего, Ваши результаты связаны с тем, что по умолчанию после установки включен режим отладки, который полностью подавляет любое промежуточное кэширование на всех этапах.
Спасибо за пожелание!
> Пытался поставить на свой сервак, но там вообще не удалось запустить. Class 'LabVars' not found. Вечером может посмотрю почему так.
Я разобрался. Это из-за того что система не умеет работать находясь в поддиректориях. Но достаточно легко лечится. Достаточно в /kernel/core/config.php заменить определение константы LAB_PATH_ROOT = $_SERVER[«DOCUMENT_ROOT»];
на
str_replace('\\', '/', realpath(dirname(dirname(dirname(__FILE__)))));
Пока заработало. Продолжаю осматриваться дальше.
Я разобрался. Это из-за того что система не умеет работать находясь в поддиректориях. Но достаточно легко лечится. Достаточно в /kernel/core/config.php заменить определение константы LAB_PATH_ROOT = $_SERVER[«DOCUMENT_ROOT»];
на
str_replace('\\', '/', realpath(dirname(dirname(dirname(__FILE__)))));
Пока заработало. Продолжаю осматриваться дальше.
С установкой разобрались. Встает новая проблема — как не позволить пользователю разместить на одной странице, скажем, фотоальбом и, например, форум? К здравому смыслу уповать бесполезно, поэтому нужна типизация модулей. Модуль такого-то типа (я для таких модулей где-то подсмотрел понятие «компонент») может быть на странице только один.
Это — не проблема, а ваше видение того «как надо делать сайты». Вы ограничиваете своих пользователей вашим мнением — а этого делать нельзя, вы невсеведущи!
все ограничивают, так или иначе.
пользователь в массе туп, программист хотя бы видит подводные камни неуместных решений.
так что решение ограничить пользователя вполне адекватно.
пользователь в массе туп, программист хотя бы видит подводные камни неуместных решений.
так что решение ограничить пользователя вполне адекватно.
Покажите мне популярную CMS, где пользователи ограничены в выборе модулей на страницу, где нельзя разместить на одной странице фотоальбом и форум.
а есть хоть одно разумное оправдание так делать?
Ну разумеется: форум на сайте фотолюбителей.
Сила модульной системы в том, чтобы иметь возможность из маленьких, но хорошо делающих одно дело модулей, собирать другие системы по частям, не думая о внутреннем устройстве модулей. Предоставлять возможности, а не запрещать их!
Сила модульной системы в том, чтобы иметь возможность из маленьких, но хорошо делающих одно дело модулей, собирать другие системы по частям, не думая о внутреннем устройстве модулей. Предоставлять возможности, а не запрещать их!
может под фотоальбомом достаточно будет модуля комментариев?
Может да, а может и нет. Нам то откуда знать, что понадобится нашему возможному заказчику?
а может даже заказчику не давать делать полный бред, а убедить, что лучше выбрать другие варианты?
Если мы делаем сайт — то да, мы можем выбрать другие варианты.
Если мы делаем CMS — то нет, универсальность важнее.
Если мы делаем CMS — то нет, универсальность важнее.
Не понимаю, почему вы опротестовываете очевидны плюс системы, способной комбинировать любые модули в пользу заведомо ущербной системы с ограничениями.
потребление ресурсов?
Важно различать контентные модули и сателлиты. Контентный модуль занимает главенствующую роль на странице и может влиять на работу сателлитов. Поэтому важно что, чтобы такой конетнетый модуль на странице был один, в противном случае могут возникнуть неоднозначные ситуации.
Приведу пример: есть шаблон у которого есть конетнтный блок про запас (его содержимое определяется установками страницы) и сателлит, к примеру «похожие материалы по теме». И хотим мы по такому шаблону сделать форум, загрузить в контентный блок модуль форума, форум будет передавать сателлиту информацию и мы для каждой темы сможем увидеть похожие материалы со всего сайта (не только с форума). Что произойдёт если мы вместе с форумом вкрутим в страницу и галлерею? Эти модули будут перекрикивать друг друга и сообщать сателлиту разные сведения.
Кроме того конетнетый модуль как правило отвечает за свою часть урл на сайте, по этой причине они также не могут находиться на одной странице, т.к. находятся в разных нейпспейсах. К примеру форум будет отвечать за формарование forum/topic/15, а галлерея за gallery/item/28
Приведу пример: есть шаблон у которого есть конетнтный блок про запас (его содержимое определяется установками страницы) и сателлит, к примеру «похожие материалы по теме». И хотим мы по такому шаблону сделать форум, загрузить в контентный блок модуль форума, форум будет передавать сателлиту информацию и мы для каждой темы сможем увидеть похожие материалы со всего сайта (не только с форума). Что произойдёт если мы вместе с форумом вкрутим в страницу и галлерею? Эти модули будут перекрикивать друг друга и сообщать сателлиту разные сведения.
Кроме того конетнетый модуль как правило отвечает за свою часть урл на сайте, по этой причине они также не могут находиться на одной странице, т.к. находятся в разных нейпспейсах. К примеру форум будет отвечать за формарование forum/topic/15, а галлерея за gallery/item/28
Проблема неоднозначности при обращению контентного модуля к саттелитам решается тем, что форум «говорит» главному шаблону «добавька в область такую-то, правый сайдбар, например, саттелит „похожие материалы“, галерея говорит тоже самое и получаем, в зависимости от логики сателлита, либо два экземпляра „похожие материалы“, либо один экземпляр с похожими материалами и галереи, и форума.
Про урлы вообще как-то наивно смотрится, любая вменяемая CMS, имхо, должна обеспечивать работу по соотношению любого урла с набором необходимых действий и их параметров. Это может быть банальный mod_rewrite, а может быть мощный механизм роутинга со своим языком.
Про урлы вообще как-то наивно смотрится, любая вменяемая CMS, имхо, должна обеспечивать работу по соотношению любого урла с набором необходимых действий и их параметров. Это может быть банальный mod_rewrite, а может быть мощный механизм роутинга со своим языком.
joomla не? два «компонента» на одной страничке не могут быть?
Или вы скажете что вы говорили про модули а я про компонент?
Я прям не скажу что мастер, но вот разрезе джумлы как раз модули на тот же роутинг не влияют например а компоненты очень даже.
Или вы скажете что вы говорили про модули а я про компонент?
Я прям не скажу что мастер, но вот разрезе джумлы как раз модули на тот же роутинг не влияют например а компоненты очень даже.
Честно говоря, Джумлу я забыл, как страшный сон ;)
Но даже в Джумле можно создавать сложные страницы, в которых итоговый вывод будет построен несколькими компонентами.
Но даже в Джумле можно создавать сложные страницы, в которых итоговый вывод будет построен несколькими компонентами.
Да, это мое видение того, как надо делать сайты. И да — я не всеведущ. Именно об этом и написано в статье выше.
Не нужно апеллировать к чужому Opinion'у. Просто используйте или не используйте.
Я не в магазине, я на Хабре — тут самое место, чтобы сталкивать мнения =)
Ну это не важно, это ко всякого рода фреймворкам/CMS относится в той же мере, если не в большей. Сталкивать мнения можно, но не просто ради их столкновения.
Вы говорите: «Это — не проблема, а ваше видение того «как надо делать сайты». Вы ограничиваете своих пользователей вашим мнением — а этого делать нельзя, вы невсеведущи!»
И да, это его мнение, но и его же дело, ограничивать или нет кого-то. А всесведущих нет и в помине.
Вы говорите: «Это — не проблема, а ваше видение того «как надо делать сайты». Вы ограничиваете своих пользователей вашим мнением — а этого делать нельзя, вы невсеведущи!»
И да, это его мнение, но и его же дело, ограничивать или нет кого-то. А всесведущих нет и в помине.
Когда человек точно знает, что именно в системе является его мнением, его видением ситуации — это хорошо, и тут уже можно судить «Нравится/не нравится». Особенно, если это мнение аргументированно, и согласованно со всей системой.
Но иногда человек считает, что *какая-то часть системы* не его видение ситуации, а общая аксиома — и это плохо.
Но иногда человек считает, что *какая-то часть системы* не его видение ситуации, а общая аксиома — и это плохо.
+1
Иначе получаются такие забавные штуки как ОС семейства Виндовс где разработчик знает лучше пользователя что ему нужно.
Иначе получаются такие забавные штуки как ОС семейства Виндовс где разработчик знает лучше пользователя что ему нужно.
Разработчик обязан знать лучше пользователя что ему нужно.
Вы абсолютно правы, а я неправильно выразился.
Разработчик действитель обязан знать лучше пользователя что ему нужно. Проблема в том, что такие разработчики — вымирающий вид. Лучший способ сделать так, как нужно пользователю — быть одним из них. Тогда будут удовлетворены пользователи, предпочитающие те же решения, что и разработчик.
Разработчики интерфейсов из MS же *считают* что знают что нужно пользователю, разрабатывают пользуясь правилом «средней температуры по больнице» и получают что-то, полностью не удовлетворяющее почти никого. Конечно, это не проблема, т.к. большинство пользователей приучили молча тр***ться с тем, что дают.
Loki3000 же с одной стороны пишет для себя, с другой иногда принимает решения «это *никому* не нужно — не будем делать». Именно так. *Никому*, а не *мне*. Т.е. всё-таки пытается сделать более универсальное решение. По комментам видно, что не очень получилось.
Разработчик действитель обязан знать лучше пользователя что ему нужно. Проблема в том, что такие разработчики — вымирающий вид. Лучший способ сделать так, как нужно пользователю — быть одним из них. Тогда будут удовлетворены пользователи, предпочитающие те же решения, что и разработчик.
Разработчики интерфейсов из MS же *считают* что знают что нужно пользователю, разрабатывают пользуясь правилом «средней температуры по больнице» и получают что-то, полностью не удовлетворяющее почти никого. Конечно, это не проблема, т.к. большинство пользователей приучили молча тр***ться с тем, что дают.
Loki3000 же с одной стороны пишет для себя, с другой иногда принимает решения «это *никому* не нужно — не будем делать». Именно так. *Никому*, а не *мне*. Т.е. всё-таки пытается сделать более универсальное решение. По комментам видно, что не очень получилось.
Вы думаете, что разработчики интерфейсов из MS пользуются какими-то другими интерфейсами? :)
А вообще есть только два основных варианта, имхо:
— я делаю для себя и пофиг нужно это кому-то ещё или нет
— я делаю для других и думаю, что знаю, что им нужно (даже если они сами об этом не знают)
Во втором варианте удовлетворить всех никак не получится: одному подавай консоль, потому что он 100500 команд знает наизусть и скорость ввода у него 1000 зн/мин, другому списки, кнопочки, закладки и виртуальную клавиатуру, потому что он не хочет или не может держать в голове всю информацию о контексте или постоянно за ней куда лазить, а хочет её видеть на экране и мышкой на виртуальной клаве наберёт свой пароль быстрее чем на реальной.
И от конкретного производителя тут мало что зависит, с таким же успехом это можно сказать пользователей и других ОС и ПО, большинство матерясь работает с тем, что дают лишь потому, что не дают то, с чем можно работать не матерясь. Или вообще довольны, так как и не подозревают, что можно работать по другому.
А вообще есть только два основных варианта, имхо:
— я делаю для себя и пофиг нужно это кому-то ещё или нет
— я делаю для других и думаю, что знаю, что им нужно (даже если они сами об этом не знают)
Во втором варианте удовлетворить всех никак не получится: одному подавай консоль, потому что он 100500 команд знает наизусть и скорость ввода у него 1000 зн/мин, другому списки, кнопочки, закладки и виртуальную клавиатуру, потому что он не хочет или не может держать в голове всю информацию о контексте или постоянно за ней куда лазить, а хочет её видеть на экране и мышкой на виртуальной клаве наберёт свой пароль быстрее чем на реальной.
И от конкретного производителя тут мало что зависит, с таким же успехом это можно сказать пользователей и других ОС и ПО, большинство матерясь работает с тем, что дают лишь потому, что не дают то, с чем можно работать не матерясь. Или вообще довольны, так как и не подозревают, что можно работать по другому.
На странице может быть несколько вполне независимых друг от друга модулей, но при этом все равно порядок их загрузки как-то необходимо регламентировать. Для разработчика, понимание этого факта волне нормально, а вот пользователи пугаются страшно. Чем больше от них скрыто «механики», тем лучше:)
Стив Джобс? залогинтесь!
Я в статье привел пример. Наверное, я изложил его несколько путано. Попробую еще раз:
Предположим, на странице два модуля. Один из них позволяет переключить пользователю отображаемый скин, а второй занимается некими тяжелыми подсчетами. 99% времени модуль переключения скина ничего не делает, так как нет команды от пользователя, но когда такая команда есть — он должен изменить настройки и осуществить редирект. Неразумно его подключать после модуля расчетов, так как сначала будут произведены расчеты, а потом произведен редирект и пользователь результатов расчетов все равно не увидит.
Так же я уже написал что разделил модули на три больших группы, которые подключаются по очереди.
Предположим, на странице два модуля. Один из них позволяет переключить пользователю отображаемый скин, а второй занимается некими тяжелыми подсчетами. 99% времени модуль переключения скина ничего не делает, так как нет команды от пользователя, но когда такая команда есть — он должен изменить настройки и осуществить редирект. Неразумно его подключать после модуля расчетов, так как сначала будут произведены расчеты, а потом произведен редирект и пользователь результатов расчетов все равно не увидит.
Так же я уже написал что разделил модули на три больших группы, которые подключаются по очереди.
Обращение пользователя происходит к элементу сайта, который может иметь много модулей, а не к конкретному модулю. То что от пользователя поступила команда модулю смены скина, модуль расчетов даже не подозревает. Равно как и вообще не подозревает о его существовании — просто делает свою часть работы.
Нет. В групе порядок уже не важен.
Нет. В групе порядок уже не важен.
Чтобы не было ситуации, когда модуль расчётов пыхтел — кряхтел, а модуль скина потом в конце сказал: «отбой товарищи, мы делаем редирект». Думаю это автор имел ввиду.
Я на самом деле сам ещё не до конца убеждён, стоит ли вводить такое обширное понятие как порядок загрузки. В моей практике иногда требовалось только обозначить вызов некоторых модулей как «отолженный вызов», который выполняется после остальных (порядок отложенных вызовов как правило не важен), например модуль метаинформации сможет вывести метаинформацию о странице лишь после того как отработают основные модули.
А такие вещи как редирект я считаю деструктивными и за них ответственность должен нести либо движок, либо основной модуль, который выполняется первым.
А такие вещи как редирект я считаю деструктивными и за них ответственность должен нести либо движок, либо основной модуль, который выполняется первым.
тут два варианта: или у автора логика в данном вопросе хромает, или сам модуль переключения скинов работает неизвестно как.
Логика в упорядоченном подключении модулей есть только тогда когда они могут влиять друг на друга(например на основе ранее загруженного модуля строится следующий). Ну а в примере автора логики нет — сэкономить ресурсы не выйдет.
Логика в упорядоченном подключении модулей есть только тогда когда они могут влиять друг на друга(например на основе ранее загруженного модуля строится следующий). Ну а в примере автора логики нет — сэкономить ресурсы не выйдет.
ну мне бы тоже хотелось узнать объективные причины, потому что пример из статьи смысла не имеет. но я с автором согласен в том что компоненты(те которые по 1шт на страницу) должны иметь определенный приоритет по отношению к модулям.
ИМХО, тут важен не столько приоритет, сколько именно разделение по разным очередям. Ну и наверное надо добавить параметр «зависит от» для дополнительный модулей, чтобы они не лезли поперек батьки.
Все, что грузится до компонентов — по сути инициализация модулей (подгрузка конфигов, возможно роутинг и т.д.), что после — постобработка, не влияющая на основной результат (что-то вроде плагинов?). Т.е. ядро CMS предлагает набор компонент, а подключаемые модули довольствуются оставшимися очередями. Утрирую, конечно, — можно ведь написать модуль, расширяющий состав компонент…
Все, что грузится до компонентов — по сути инициализация модулей (подгрузка конфигов, возможно роутинг и т.д.), что после — постобработка, не влияющая на основной результат (что-то вроде плагинов?). Т.е. ядро CMS предлагает набор компонент, а подключаемые модули довольствуются оставшимися очередями. Утрирую, конечно, — можно ведь написать модуль, расширяющий состав компонент…
Я предполагаю следующее: модули на странице встречаются в том порядке, в которым они показаны на странице (грубо говоря), а автор хочет этот порядок разбить, для того, чтобы модули которые выполняют потециально деструктивные действия отработали раньше остальных, чтобы было меньше напрасной работы в случае факта редиректа или 404.
нет автор хочет разбить порядок чтобы модули которые сильнее нагружают сервер загружались после тех модулей которые могут оборвать создание страницы(например сделать редирект). но когда мы говорим о модулях которые выводят инфу на экран пользователя — то уже не важно какой и когда отработает, ведь в любом случае пользователь увидит страницу целиком и только потом уже будет работать(давать команды) модулям. ну а тут уже приоритет само собой — сначала выполняется модуль которому пришла команда.
Если в модуле, который выводит инфу на экран пользователя произойдёт редирект, то пользователь в худшем случае увидит обрывок недосформированной страницы, а браузер увидит заголовок, который вынудит его сделать редирект.
а с какой радости в этом модуле сам по себе(без команды пользователя) может произойти редирект? мы с aktuba об этом говорим
Например если содержимое было перенесено. Для пользователя это не очевидно. Для движка тоже. А очевидность может наступить где — нибудь в контентном модуле, который выводит инфу. Но если модули будут вызываться вразнобой, до контентного модуля может быть сделано куча ненужной работы: баннеро крутилки, менюшки, облака тегов и прочие свистелки не имеющие отношения с содержимому.
вот для этого и делаются зависимости. чтобы если один модуль зависит от результата работы другого они подключались в правильном порядке.
Да в том то и дело что они могут и не зависеть. Баннерокрутилка не зависит от контента, если это не контекстная реклама.
Или вы предлагаете каждый модуль который делает редирект ставить в зависимости к остальным? Больно избыточная структура получится.
Или вы предлагаете каждый модуль который делает редирект ставить в зависимости к остальным? Больно избыточная структура получится.
Так и хочется спросить: а вы верите в пользователя?
Иногда удобно знать что какой-то элемент уже отработал. Иногда совершенно не нужно половины модулей, хотя в обширных цмс они все равно отрабатывают… И информация уходит в никуда.
Я немного делал по другому: был уровень запроса, который решал какие модули запускать — немного решало, хоть и не полностью, данную проблему.
Иногда удобно знать что какой-то элемент уже отработал. Иногда совершенно не нужно половины модулей, хотя в обширных цмс они все равно отрабатывают… И информация уходит в никуда.
Я немного делал по другому: был уровень запроса, который решал какие модули запускать — немного решало, хоть и не полностью, данную проблему.
Крайне интересно было почитать. Я как раз велосипед изобретаю тоже. А можно подробнее про кеширование? Всё таки я так и не понял как вы его реализовали в конечном итоге. Особенно кеширование блоками.
Так получилось что я не найдя подходящего решил писать ещё и свой шаблонизатор, с кешированием и пока я просто склоняюсь к мысли что у каждого шаблона нужно устанавливать время жизни кеша и т.д.
Ну т.е. есть шаблон с временим жизни кеша в 10 дней. А все часто изменяемые данные выносятся в отдельные шаблоны с другим временем жизни.
В при кешированиее кешируется все, кроме подключения шаблонов в шаблоне. Подключение вложенных шаблонов происходит даже когда сам головной шаблон берётся из кеша.
Но тут я пока не до конца это реализовал и боюсь что скорость выполнения моего решения будет весьма низкой, да и не совсем мне такой подход нравится.
Так получилось что я не найдя подходящего решил писать ещё и свой шаблонизатор, с кешированием и пока я просто склоняюсь к мысли что у каждого шаблона нужно устанавливать время жизни кеша и т.д.
Ну т.е. есть шаблон с временим жизни кеша в 10 дней. А все часто изменяемые данные выносятся в отдельные шаблоны с другим временем жизни.
В при кешированиее кешируется все, кроме подключения шаблонов в шаблоне. Подключение вложенных шаблонов происходит даже когда сам головной шаблон берётся из кеша.
Но тут я пока не до конца это реализовал и боюсь что скорость выполнения моего решения будет весьма низкой, да и не совсем мне такой подход нравится.
На самом деле, примерно к тому же я и пришел. Только в некоторых случаях я спустился даже не к кэшированию блоков, а к кэшированию запросов к БД. Это полезно в тех случаях, когда внешний вид страницы сильно зависит от настроек пользователя. В итоге вариантов HTML получается множество, повторная их востребованность невелика, а запросы к БД примерно одни и те же.
С главным шаблоном имеется такая проблема. Можно пойти двумя путями: указать некэшируемые области (именно там, где подставляются более мелкие блоки), либо наоборот — указать что именно кэшировать. Я пока попробовал первый способ.
С главным шаблоном имеется такая проблема. Можно пойти двумя путями: указать некэшируемые области (именно там, где подставляются более мелкие блоки), либо наоборот — указать что именно кэшировать. Я пока попробовал первый способ.
Кэш со временем жизни во многих случаях неприменим. Простой пример — пользователь написал комментарий к материалу и наивно хочет его увидеть сразу как написал, а не когда истечёт время жизни у кэша страницы или блока комментов — тут даже 1 секунда будет много, с другой стороны — может быть тысяча запросов на просмотр комментов на один запрос на добавление коммента и дергать базу ради каждого не тру. Кэш надо инвалидировать или поддерживать валидным, а не устанавливать время жизни. Сценарий добавления коммента должен или стереть (пометить как устаревший) кэш страницы или блока комментариев, чтобы при обращении к странице/блоку он сгенерировался уже с новым комментарием, или сгенерировать этот кэш ещё до того, как к нему кто-то обратится (если кэш условно неограниченный и условно постоянный (файловый, например), а не вытесняющий и временный (в ОЗУ))
К сожалению да, такой вопрос я тоже себе задавал, но до реализации этого пока ещё не дошёл и не знаю как это решить. Но например добавлением функции сброса кеша и нового кеширования необходимых шаблонов в случае каких-то операций добавления удаления, редактирования и т.д. Но это тоже не самый лучший вариант, но другого я пока не придумал
Записи в кэше можно тэгировать, например, присваивать кэшу блока/страницы тэги с именами таблиц, id записей и т. п., вплоть до отдельных полей, из которых эти блоки/страницы получаются. При запросах на изменение таблиц удалять из кэша все записи с такими тэгами (таблицами/id/полями). Самое сложное при большой нагрузке — сделать так, чтобы при отсутствии (устаревании) кэша два практически одновременно полученных одинаковых запроса не начали генерировать страницу/блок параллельно, а второй ждал пока первый сгенерирует, а потом взял уже готовый кэш, но в тоже время, чтобы он не ждал бесконечно, чтобы из-за зависания одного обработчика не зависли все.
Да. Нечто подобное и я хотел сделать. Но только не тонко, чтобы при изменении записи в БД менять ту часть кеша, которая эту запись хранит, а при малейшем изменении шаблона менять сразу весь шаблон заново (кеш я имею ввиду). Конечно ваш вариант мне в целом нравится больше, но думаю что для моего проекта это будет уже слишком.
А вот про распараллеливание и возможные конфликты при одновременном создании кеша спасибо. Такая мысль мне к сожалению в голову даже не приходила, надо будет подумать как это реализовать.
А вот про распараллеливание и возможные конфликты при одновременном создании кеша спасибо. Такая мысль мне к сожалению в голову даже не приходила, надо будет подумать как это реализовать.
>Самое сложное при большой нагрузке — сделать так, чтобы при отсутствии (устаревании) кэша два практически одновременно полученных одинаковых запроса не начали генерировать страницу/блок параллельно
С этой проблемой я на определенном этапе столкнулся. В итоге, стал перед началом генерации данных ставить lock метку, если ее еще нет. Это позволило существенно снизить нагрузку в момент устаревания кэша.
С этой проблемой я на определенном этапе столкнулся. В итоге, стал перед началом генерации данных ставить lock метку, если ее еще нет. Это позволило существенно снизить нагрузку в момент устаревания кэша.
В таком примере выход простой – сделать постинг через AJAX. Сервер возвращает, например, {posted: true}, и на стороне клиента через JS добавляем пост к остальным.
Yii — фрейворк, автор описал CMS, сравнивать их бессмысленно. хотя с помощью уии можно решить те же задачи что и при помощи цмски, но способ решения будет сильно отличатся.
А можно и не на Yii. Давайте без фанатизма
можно было, но смотря какая была цель этого велосипеда. если хотелось поучится, сделать свое и что то очень легковесное — то без уии все же лучше. Ну а во всех остальных случаях конечно быстрее(относительно времени написания), легче и «красивее» было бы с помощью фреймворка.
Подскажите, как оптимально сделать вывод title заголовков в CMS(на PHP) движке?
Как оптимально — не знаю.
У меня эти данные хранятся в настройках узла, но могут быть изменены любым из подключаемых модулей.
У меня эти данные хранятся в настройках узла, но могут быть изменены любым из подключаемых модулей.
1. формируете ВСЕ данные в контроллере — передаете тайтл во вьювер, во вьювере выводите.
2. буферизуете вывод данных на страенице, перед отдачей подставляете тайтл
2. буферизуете вывод данных на страенице, перед отдачей подставляете тайтл
Вьювер сам должен из данных стряпать тайтл. Ни в коем случае не передаете тайтл во вьювер из контроллера.
Если это страница новости, то вы должны передать только новость, а вьювер вывести «Суперсайт / новости от 7 декабря / Найден убийца Листьева».
Если это страница новости, то вы должны передать только новость, а вьювер вывести «Суперсайт / новости от 7 декабря / Найден убийца Листьева».
Только лучше наоборот — «Найден убийца Листьева / новости от 7 декабря / Суперсайт». Чтоб видимая во вкладке часть заголовка была уникальной.
согласен, я должен в БД забить новость, а вьвер сам сформировать дизайн, верстку и еще провести сео-оптимизацию текста
Но никто не запрещает формировать данные в контроллере в виде $data->title = «Main page»; $data->body = «Welcome!» ;)
"… мне до этих ребят дела нет" (с)
Fatal error: Class 'OpenId' not found in /home/labcms/www/kernel/modules/login/auth.class.php on line 57
В качестве бонуса могли бы выложить объяснения, каким образом велосипед из картинки может двигаться (долго смотрел — так и не смог понять) :).
Ногой протягиваете цепь, а пружина возвращает ее обратно. потом снова протягиваете цепь.
Правда движение будет не такое равномерное.
Правда движение будет не такое равномерное.
Это Степпер, раньше такие популярные были cyclepedia.ru/content/stepper
Сейчас еще есть elliptigo (гуглите сами =)
Сейчас еще есть elliptigo (гуглите сами =)
Не совсем понимаю зачем запихивать структуру сайта в дерево? Вы написали, что потом меню удобно генерировать. А если пункт меню должен ссылаться на внешний ресурс? А если в какой-то ветке структуры окажется 1000-100 000 потомков? Все ли в природе можно нанизать на дерево?
Элементы дерева могут так же быть внешними, внутренними ссылками или даже алиасами.
Очень большое количество элементов в дереве, скорее всего, будет говорить о неправильном проектировании сайта, так как большую часть навигации выполняют сами модули. Движку-же надо только определить какие модули необходимо подключить.
Очень большое количество элементов в дереве, скорее всего, будет говорить о неправильном проектировании сайта, так как большую часть навигации выполняют сами модули. Движку-же надо только определить какие модули необходимо подключить.
Золотые слова! Дерево это хорошо. Особенно когда его можно использовать, или не использовать. Дерево как основная и неизменная структура сайта (в любой CMS) – плохо.
Дополню своими «если» (не только применимо к сабж-CMS, а вообще):
А если у элемента два родителя? Вводить и кодить фолксономию (теги) после прихоти заказчика? Или ставить в шаблонах <? if ?> костыли?
Или два типа родителей (то есть в одной структуре он родитель, а в другой — всего лишь ветка)?
А если это каталог товаров (импортируемый из Excel), размером в 15000 строк? Выводить весь?
А если не все пункты меню нужны (то есть в дереве 50 страниц, а меню только на 6 важнейших)?
А если пункт меню ссылается на первого дочернего подпункта? (хотя, именно в этом случае, думаю, будет алиас)
А если все страницы равнозначны, и общая структура — паутина (как в википедии)?
А структура сайта разве не распределена? В одной таблице — и текст со страниц, и обновляемый каталог на многотыщ товаров? В таком случае и деревьев должно быть два. А если всё лежит в одной таблице… Что ж, битрикс вон тоже вроде покупают и даже ставят.
А если элемент дерева вообще не имеет текстового титла? Так бывает, люди импортируют фотографии и каталоги продукции огромными пачками по FTP, через массовый flash загрузчик, или архивами, или просто скидывая исполнителю компакт-диск с фотографиями. Как выводить их в дереве?
А если элемент не имеет титла, только длинный HTML текст? Так иногда бывает, у новостей, например. Выводить в дереве его?
А если к каждой странице нужны комментарии? Я, например, не представляю себе дерево постов Хабрахабра с комментариями. Даже если оно будет, в какой ветке будут висеть пользователи?
Я конечно, извиняюсь за такую резкую критику. Написание CMS, несомненно, полезная вещь как для программиста, так и для его окружения (компании, в которой он работает, и подобных случаев).
Дополню своими «если» (не только применимо к сабж-CMS, а вообще):
А если у элемента два родителя? Вводить и кодить фолксономию (теги) после прихоти заказчика? Или ставить в шаблонах <? if ?> костыли?
Или два типа родителей (то есть в одной структуре он родитель, а в другой — всего лишь ветка)?
А если это каталог товаров (импортируемый из Excel), размером в 15000 строк? Выводить весь?
А если не все пункты меню нужны (то есть в дереве 50 страниц, а меню только на 6 важнейших)?
А если пункт меню ссылается на первого дочернего подпункта? (хотя, именно в этом случае, думаю, будет алиас)
А если все страницы равнозначны, и общая структура — паутина (как в википедии)?
А структура сайта разве не распределена? В одной таблице — и текст со страниц, и обновляемый каталог на многотыщ товаров? В таком случае и деревьев должно быть два. А если всё лежит в одной таблице… Что ж, битрикс вон тоже вроде покупают и даже ставят.
А если элемент дерева вообще не имеет текстового титла? Так бывает, люди импортируют фотографии и каталоги продукции огромными пачками по FTP, через массовый flash загрузчик, или архивами, или просто скидывая исполнителю компакт-диск с фотографиями. Как выводить их в дереве?
А если элемент не имеет титла, только длинный HTML текст? Так иногда бывает, у новостей, например. Выводить в дереве его?
А если к каждой странице нужны комментарии? Я, например, не представляю себе дерево постов Хабрахабра с комментариями. Даже если оно будет, в какой ветке будут висеть пользователи?
Я конечно, извиняюсь за такую резкую критику. Написание CMS, несомненно, полезная вещь как для программиста, так и для его окружения (компании, в которой он работает, и подобных случаев).
CMS без дерева сайта — утопия.
Потому что без дерева не построить мультиязычные ресурсы, у которых структуры кардинально отличаются друг от друга. Для пользователя, да и оператора CMS, легче воспринимать сайт как набор страниц.
Потому что без дерева не построить мультиязычные ресурсы, у которых структуры кардинально отличаются друг от друга. Для пользователя, да и оператора CMS, легче воспринимать сайт как набор страниц.
CMS — это вообще утопия… Нет, если достаточно текстового наполнения и сайт за 100 баксов на программинг, то в принципе хватит, но я лично предпочитаю пользоваться своей CMF. Минимальное ядро системы, на которое наращивается необходимый функционал. Ядро подразумевает жесточайшие правила кода (при этом не нарушая возможности вертеть нею как угодно). Так же само собой разделение кода и дизайна, кеширование. Выбрана такая схема была, потому как у меня нет одинаковых сайтов, у меня к каждому находится новый подход, так как все растет и развивается. Сохраняется только мини-ядро. Само собой модули пишутся таким образом чтобы их можно было в дальнейшем использовать повторно, если это необходимо.
Редкий случай, когда ваше мнение мне кажется излишне категоричным.
Ну почему же утопия? Почему я должен произвольный граф вырождать в дерево? Почему я должен в структуре сайта ограничиваться лишь связями «родитель-дети», а не, например, «предыдущий-следующий» (и потом вводить для таких связей костыли)? И без дерева, вернее не сводя структуру к всего лишь дереву, мультиязычный ресурс тоже вполне себе можно построить и куда более гибкий, чем «деревянный», например связи со страницами с тем же контентом, но на другом языке, через дерево, где языки — это ветви от корня (такое дерево имеете в виду?) не реализовать без костылей в виде, например, прямых ссылок, или многократного дублирования, по-моему.
Ну почему же утопия? Почему я должен произвольный граф вырождать в дерево? Почему я должен в структуре сайта ограничиваться лишь связями «родитель-дети», а не, например, «предыдущий-следующий» (и потом вводить для таких связей костыли)? И без дерева, вернее не сводя структуру к всего лишь дереву, мультиязычный ресурс тоже вполне себе можно построить и куда более гибкий, чем «деревянный», например связи со страницами с тем же контентом, но на другом языке, через дерево, где языки — это ветви от корня (такое дерево имеете в виду?) не реализовать без костылей в виде, например, прямых ссылок, или многократного дублирования, по-моему.
Это не проблема реализации, это проблема восприятия пользователем сайта. Однозначные и предсказуемые движения по дереву не вызывают негативной реакции.
Приведу пример. Есть ресурс размещения авторских фотографий. На нем есть два раздела «Галлерея фотографий» и «Фотографы». Если человек рассматривал галлерею, выбрал какую-то работу, и захотел посмотреть информацию об авторе, то он не должен попадать в раздел «Фотографов», хотя это и кажется абсолютно логичным. Он должен получить информацию о фотографе на этой же странице, что и понравившаяся фотография. Потому что его основная цель — просмотр фотографий, а вспомогательная — информации об авторах.
И наоборот, при просмотре авторов, нужно иметь возможность просматривать их работы без перебрасывания между «ветками».
Реализация будет в виде произвольных графов, но вот для пользователя гораздо удобнее видеть вырожденное и не очень глубокое дерево, потому что его гораздо проще держать в голове.
Приведу пример. Есть ресурс размещения авторских фотографий. На нем есть два раздела «Галлерея фотографий» и «Фотографы». Если человек рассматривал галлерею, выбрал какую-то работу, и захотел посмотреть информацию об авторе, то он не должен попадать в раздел «Фотографов», хотя это и кажется абсолютно логичным. Он должен получить информацию о фотографе на этой же странице, что и понравившаяся фотография. Потому что его основная цель — просмотр фотографий, а вспомогательная — информации об авторах.
И наоборот, при просмотре авторов, нужно иметь возможность просматривать их работы без перебрасывания между «ветками».
Реализация будет в виде произвольных графов, но вот для пользователя гораздо удобнее видеть вырожденное и не очень глубокое дерево, потому что его гораздо проще держать в голове.
Вот как раз к галерее или, скажем, большому документу, разбитому на главы/страницы чистое дерево не удобно применять. Нужны ещё, как минимум, связи «старший брат — младший брат» («предыдущий» — «следующий»). Пользователю будет неудобно для просмотра очередной фотографии переходить в альбом или для просмотра очередной главы/страницы переходить в оглавление.
А можно попоброднее, как вы себе представляете структуру сайта — не дерева? Как это будет выглядеть в пространстве урл.
/users/volch — вывод моих данных как пользователя
/authors/volch — вывод моих данных как автора
/users+authors/volch — вывод моих данных и как пользователя, и как автора используя модули users и authors, а не третий модуль users_authors
:)
А вообще, древовидное пространство урлов с возможностями современных средств перезаписи урлов и роутинга не более чем условность и дань традиции «статического» интернета.
/authors/volch — вывод моих данных как автора
/users+authors/volch — вывод моих данных и как пользователя, и как автора используя модули users и authors, а не третий модуль users_authors
:)
А вообще, древовидное пространство урлов с возможностями современных средств перезаписи урлов и роутинга не более чем условность и дань традиции «статического» интернета.
В узлах дерева могут располагаться записи самых разных типов — не только страницы, но и ссылки на другие страницы в том же сайте, внешние ссылки, разделители, вообще любые информационные сущности.
Если у элемента два родителя, и это не очень типично для данного сайта — к одному из родителей присоединяется ссылка на страницу, находящуюся в другой ветке иерархии, только и всего. Если ситуация типична для сайта — то, видимо, стоит просто взять другую CMS, построенную на принципе тегов и таксономий — друпал, например. Ну, или реализовывать систему тегов в этой CMS.
Стоит посмотреть, как это решено в TYPO3 — для иерархических сайтов это пока самое гибкое решение, что я видел. В частности, если пункт меню ссылается на первый дочерний подпункт, то для этого есть тип страницы «Shortcut», который может ссылаться либо на произвольную страницу в дереве сайта, либо на первую подстраницу, либо на случайную подстраницу. Если этого мало (например, хочется на последнюю подстраницу) — всегда можно написать несложное расширение. Но для этого, конечно, придется в документации попастись.
Ну и, опять же, CMS — это инструмент вполне конкретного предназначения. Делать на CMS общего назначения Хабр — это как ножом гайки заворачивать.
А вот есть ли в какой-нибудь CMS реализация дерева через Nested sets из коробки?
Если у элемента два родителя, и это не очень типично для данного сайта — к одному из родителей присоединяется ссылка на страницу, находящуюся в другой ветке иерархии, только и всего. Если ситуация типична для сайта — то, видимо, стоит просто взять другую CMS, построенную на принципе тегов и таксономий — друпал, например. Ну, или реализовывать систему тегов в этой CMS.
Стоит посмотреть, как это решено в TYPO3 — для иерархических сайтов это пока самое гибкое решение, что я видел. В частности, если пункт меню ссылается на первый дочерний подпункт, то для этого есть тип страницы «Shortcut», который может ссылаться либо на произвольную страницу в дереве сайта, либо на первую подстраницу, либо на случайную подстраницу. Если этого мало (например, хочется на последнюю подстраницу) — всегда можно написать несложное расширение. Но для этого, конечно, придется в документации попастись.
Ну и, опять же, CMS — это инструмент вполне конкретного предназначения. Делать на CMS общего назначения Хабр — это как ножом гайки заворачивать.
А вот есть ли в какой-нибудь CMS реализация дерева через Nested sets из коробки?
>А вот есть ли в какой-нибудь CMS реализация дерева через Nested sets из коробки?
Изначально была идея реализовать и nested sets тоже… Даже таблицу иерархии сделал отдельно, чтобы можно было использовать либо одну, либо другую… Но через некоторое время дрогнул, таблицы объединил, а про nested sets забыл до лучших времен:)
Изначально была идея реализовать и nested sets тоже… Даже таблицу иерархии сделал отдельно, чтобы можно было использовать либо одну, либо другую… Но через некоторое время дрогнул, таблицы объединил, а про nested sets забыл до лучших времен:)
Реализовывать дерево средствами РСУБД, имхо, не самая хорошая идея. Во всех известных мне реализациях есть большие минусы и выбор заключается в выборе наименьшего для данной ситуации зла.
Кроме прочего, CMS должно быть возможно установить на стандартный shared-хостинг. Понятно, что это решение неидеальное и всегда какой-то компромисс. РСУБД вообще для системы, в которой много похожих, но вовсе неодинаковых сущностей — не лучшее рещение. Гораздо элегантнее контент любого сайта (включая всю служебную информацию, информацию о пользователях и пр.) запишется в виде какого-нибудь JSON или XML… Ну вот как станет обычным делом иметь на хостинге, к примеру, Монго, тогда и в CMS можно его использовать как основной носитель данных.
А пока что — увы — у мускла конкурентов на LAMP shared хостинге нету.
А пока что — увы — у мускла конкурентов на LAMP shared хостинге нету.
Ну тут как с играми на линуксе, по-моему. Хостеры не делают такие тарифы, потому что нет CMS, использующих Mongo, Couch и т. п., разработчики не делают таких CMS, потому что нет тарифов… Сдаётся мне, что разработчики должны делать первый шаг, и некоторые уже делают.
Как компромисс можно ввести абстракцию хранилища, чтобы использование mysql или mongodb задавалось на уровне конфигов. Но на личном опыте познал, что это не так просто, всё-таки задача куда сложнее, чем скрыть различия между двумя РСУБД. Или монго не показывает своих преимуществ, или мускул надрывается на данных «без схемы».
Как компромисс можно ввести абстракцию хранилища, чтобы использование mysql или mongodb задавалось на уровне конфигов. Но на личном опыте познал, что это не так просто, всё-таки задача куда сложнее, чем скрыть различия между двумя РСУБД. Или монго не показывает своих преимуществ, или мускул надрывается на данных «без схемы».
Угу, согласен, дерево слишком негибкая структура. Смешанные графы — вот выход :) Дерево лишь их частный случай, как и плоский список.
Не нужно все страницы сайт запихивать в дерево! Дерево только определяет основные разделы. Если у Вас есть каталог товаров, который импортируется из Excel и содержит 15 000 наименований, то в дереве это будет всего один раздел «Каталог». А при переходе в этот раздел подключается модуль, который уже и выводит наименования.
Есть один раздел «Новости». А внутри этого раздела много страниц, которыми управляет модуль «Новости». Но в дереве будет только один раздел.
Внешняя ссылка? Пожалуйста! Создайте раздел «для партнёров» и укажите модуль=ссылка. Управление таким разделом будет заключаться только в том, что бы указать ссылку.
Есть один раздел «Новости». А внутри этого раздела много страниц, которыми управляет модуль «Новости». Но в дереве будет только один раздел.
Внешняя ссылка? Пожалуйста! Создайте раздел «для партнёров» и укажите модуль=ссылка. Управление таким разделом будет заключаться только в том, что бы указать ссылку.
Спасибо, реальные советы как сделать велосипед :)
О, кэширование…
Вот почти всё я у себя сделал, кроме нормально кэширования.
И почитать про блочное кэширование или кэширование запросов ничего не нашёл — только глупые руководства на тему «кэшируем страницу»/«кэшируем выдранные новости».
Не видели ничего подобного, или может в двух словах механизм разъясните? :)
Вот почти всё я у себя сделал, кроме нормально кэширования.
И почитать про блочное кэширование или кэширование запросов ничего не нашёл — только глупые руководства на тему «кэшируем страницу»/«кэшируем выдранные новости».
Не видели ничего подобного, или может в двух словах механизм разъясните? :)
Опять эти "{foreach name=«top_news» item=«new» from=$top_news}"
Как они надоели
Как они надоели
Чем?
Сложный синтаксис, долго печатать
Для профи — да. Для новичков — нет, так как данная конструкция более человекопонятная, проще запоминать.
{foreach name=«top_news» item=«new» from=$top_news}
{$new.news_date|date_format}
{/foreach}
у автора
[top_news]
%news_date%
[/top_news}
мой подход
где проще?
{$new.news_date|date_format}
{/foreach}
у автора
[top_news]
%news_date%
[/top_news}
мой подход
где проще?
А как верстается сам %news_date%?
[news_date]
%day% %month% %year%
[/news_date]
если news_date это массив
если же, news_date строка, то просто выводится как задано в базе или обработано через скрипт
%day% %month% %year%
[/news_date]
если news_date это массив
если же, news_date строка, то просто выводится как задано в базе или обработано через скрипт
В таком случае не вижу принципиальной разницы.
В смарти обязательно указывать foreach, тут не надо. Система сама определить [news_date] массив или строка
А как показать только первый элемент из массива не перебирая весь цикл?
ну понятно
[top_news|first], например (как у автора — хз)
ну и т.п.
foreach — это тяжелое программистское наследие. надо стремиться к декларативности
[top_news|first], например (как у автора — хз)
ну и т.п.
foreach — это тяжелое программистское наследие. надо стремиться к декларативности
Не вижу никаких проблем с использованием foreach. Борьба с ним может приводить к невразумительным последствиям. Язык должен быть однозначным, а не позволять делать одно и то же двадцатью разными способами.
> Язык должен быть однозначным, а не позволять делать одно и то же двадцатью разными способами.
Какой язык? Язык шаблонов? С каких пор появление в аком языке foreach делает некий гипотетический язык шаблонов однозначным? :-\
Что значит «делать одно и то же двадцатью разными способами» применительно к языку шаблонов, наприер, описанному выше?
Какой язык? Язык шаблонов? С каких пор появление в аком языке foreach делает некий гипотетический язык шаблонов однозначным? :-\
Что значит «делать одно и то же двадцатью разными способами» применительно к языку шаблонов, наприер, описанному выше?
Я вообще противник управляющих шаблонов. Вся логика должна быть в PHP.
Например нам нужно показать самую свежую новость, т.е первый элемент массива. Так зачем нам передавать все новости в шаблонизатор? Делаем sql выборку только одной новости и передаем её шаблонизатору.
Например нам нужно показать самую свежую новость, т.е первый элемент массива. Так зачем нам передавать все новости в шаблонизатор? Делаем sql выборку только одной новости и передаем её шаблонизатору.
Первая новость из списка может иметь дизайн, отличный от всего остального списка. И логика построения темплейта будет примерно такая: показать новость с нулевым индексом с особым шаблоном, а потом, ниже, вставить список от 1 до 24-го элемента.
Очень похоже на синтаксис шаблонизатора из ABO.CMS.
В смарти3 уже можно так: "{foreach $top_news as $new}"
Не смог зайти на сайт через MyOpenId. Скачал CMS и попробовал поставить на Денвер — сначала редиректил на страницу с localhost/denwer/, потом к адресу дописал index.php и посыпались ошибки :(
пытаюсь зайти на тестовом (вашем) сайте через OpenId, указываю свой гуглоакк — «Пользователь www.google.com/accounts/o8/id?id=AItOawlUPylndO2Pgou8DsZpQZDsdkQVViy2BNQ не найден», пытаюсь воспользоваться OpenId со своего домена (через myopenid.com) — «Пользователь (имя моего домена) не найден»
сыро :(
сыро :(
заглянул в файлик \labcms_trunk_full\upload\kernel\modules\forum\edit_post.phpб кодес очень не тру :( каша редкая, вы писали про mvc вначале, советую использовать контроллеры и экшены и sql запросы храните лучше в том же xml, а то они у вас захардкожены по всему коду) и не забывайте включать профайлер, перформанс очень важен и советую сделать обертку для http запросов, $_POST и иже с ним не есть гуд по всему коду. вообще много чего можно говорить, нет времени к сожалению копать кодес, используйте паттерны и успехов вам)
Топик прямо в тему… Мастерю свой велосипед :-) Спасибо.
А как в вашей CMS сделать следующую задачу
1. На главной показываем 10 последних новостей
2. Есть отдельный раздел «Новости», в котором представлены 24 последние новости + 1 новость с большой картинкой и чуть более детальным описанием
3. Новость отображается в виде страницы с ЧПУ, например /news/10_10_2010/demo_news.html, кроме самого тела новости будет еще список из 10 похожих новостей
4. Есть архив новостей, который показывает список новостей на определенную дату.
Мне интересно, как вы будете страницы строить для всего этого.
1. На главной показываем 10 последних новостей
2. Есть отдельный раздел «Новости», в котором представлены 24 последние новости + 1 новость с большой картинкой и чуть более детальным описанием
3. Новость отображается в виде страницы с ЧПУ, например /news/10_10_2010/demo_news.html, кроме самого тела новости будет еще список из 10 похожих новостей
4. Есть архив новостей, который показывает список новостей на определенную дату.
Мне интересно, как вы будете страницы строить для всего этого.
Если надо в точности выполнять все условия, то просто напишу соответствующий модуль.
Как это в дереве страниц будет отображено? Просто написать модуль любой сможет…
Имхо необходим список таких вот вопросов. Большой список, чтобы каждый разработчик мог задать себе вопрос: а на моей CMS можно реализовать следующее:
1. На главной показываем 10 последних новостей
2. Есть отдельный раздел «Новости», в котором представлены 24 последние новости + 1 новость с большой картинкой и чуть более детальным описанием
3. Новость отображается в виде страницы с ЧПУ, например /news/10_10_2010/demo_news.html, кроме самого тела новости будет еще список из 10 похожих новостей
4. Есть архив новостей, который показывает список новостей на определенную дату.
И так далее. По принципу Да/нет, можно/нельзя. Не «модуль фотогалерея — Есть! Модуль Новости — Есть!» (Этим болеют разного рода таблицы сравнения CMS), а именно нетипичные задачи.
Добавлю задачу вывода фотогалереи в каждой новости, вставку сущностей иного рода между новостями (как на хабре — между постами — голосования), упорядочивание по неделям (то есть постраничная навигация, одна страница — одна неделя), поиск по свойствам родительских элементов (чтобы по запросу процессоры находить элемент Intel Atom).
А также:
Выводить снизу новости (где полный текст) шесть новостей, из них три — это следующие по дате после текущей, и три предыдыщие (тут уже Limit-om в запросе не обойтись).
Переименовать страницу /catalog/mebel/id342234 в /Italyanskaya-Mebel-Kupit-moskva. С сохранением функционала и без правки .htaccess. В том числе, если система работает без Apache (на nginx например).
Дать возможность администратору менять вон тот номер телефона компании, что в подвале на каждой странице.
1. На главной показываем 10 последних новостей
2. Есть отдельный раздел «Новости», в котором представлены 24 последние новости + 1 новость с большой картинкой и чуть более детальным описанием
3. Новость отображается в виде страницы с ЧПУ, например /news/10_10_2010/demo_news.html, кроме самого тела новости будет еще список из 10 похожих новостей
4. Есть архив новостей, который показывает список новостей на определенную дату.
И так далее. По принципу Да/нет, можно/нельзя. Не «модуль фотогалерея — Есть! Модуль Новости — Есть!» (Этим болеют разного рода таблицы сравнения CMS), а именно нетипичные задачи.
Добавлю задачу вывода фотогалереи в каждой новости, вставку сущностей иного рода между новостями (как на хабре — между постами — голосования), упорядочивание по неделям (то есть постраничная навигация, одна страница — одна неделя), поиск по свойствам родительских элементов (чтобы по запросу процессоры находить элемент Intel Atom).
А также:
Выводить снизу новости (где полный текст) шесть новостей, из них три — это следующие по дате после текущей, и три предыдыщие (тут уже Limit-om в запросе не обойтись).
Переименовать страницу /catalog/mebel/id342234 в /Italyanskaya-Mebel-Kupit-moskva. С сохранением функционала и без правки .htaccess. В том числе, если система работает без Apache (на nginx например).
Дать возможность администратору менять вон тот номер телефона компании, что в подвале на каждой странице.
Разумеется, без написания модуля «номер телефона»
То есть предлагаете составить типичный список нетипичных задач? :)
Наверное в любой CMS всё это можно сделать, вопрос лишь квалификации того, кто делает, например, умеет ли он программировать на ассемблере ARM :) и многое ли будет использоваться изначального функционала CMS, кроме логотипа в админке :)
Наверное в любой CMS всё это можно сделать, вопрос лишь квалификации того, кто делает, например, умеет ли он программировать на ассемблере ARM :) и многое ли будет использоваться изначального функционала CMS, кроме логотипа в админке :)
в заголовке не «Хороших», а «Веселых». =\
Опишите, пожалуйста, ту часть системы где происходит подмена файлов дизайна, то есть выбор между базовым и кастомным. Это при помощи php'шного file_exists()?
и как это отражается на производительности?
и как это отражается на производительности?
При первой генерации элемента дерева, в него складывается информация, которую неразумно генерировать каждый раз (список подключенных модулей, настройки, права доступа и т.п. После чего объект сохраняется на диск. Среди прочего, объект содержит частичную информацию об имеющихся дизайнах и шаблонах (пока, к сожалению, не полную, но со временем я это исправлю). Вот на этапе генерации объекта — file_exists, при следующих запросах — опрос свойств объекта.
а затем во время отрисовки страницы система подключает файлы, пути к которым берет из сгенерированного объекта?
Покажите пример административной части. Пару картинок на дают особо чтото понять, и очень страшны.
Спасибо.
Спасибо.
Вы ничего не понимаете в CMS. Никто. А я понимаю, но делать не буду, потомучто нет ни времени ни денег. И рассказывать тоже не буду. И это у вас не велосипеды. Это мясорубки. А мясорубка не поедет, как ты ее ни крути.
Как в анекдоте — «если не видеть других машин — жигуль классная тачка...» ;)
Но столкнувшись с реальными потребностями, далёкими от «вакуумных измерений» (просто показать страничку и форум): «выходим опять на Дерибасовская» ставим готовую CMS(F) и допиливаем под себя…
Но столкнувшись с реальными потребностями, далёкими от «вакуумных измерений» (просто показать страничку и форум): «выходим опять на Дерибасовская» ставим готовую CMS(F) и допиливаем под себя…
из доступных cms/f я не пока не видел ни единого нормального двига, по сути одно говно. Все идет хорошо если вам не надо сделать решение отличающееся от гостевой книги и сайта визитки… когда появляется не стандартная задача, сразу вылазит миллион косяков этих недо cms/cmf, тонны кривого кода в котором черт ногу сломит и бредовые архитектурные решения от которых мозг кипит. Если вам нужно решение не обыденное то нужно брать фреймворк, я предпочитаю ZF или Symfony, еще есть yii еще но я его не копал. В них грамотный код, паттерны и стандарты а не потуги пьяной обезьяны как в modx и иже с ними… )
Много хорошего встречал в Phenotype CMF. Там, при всех недочетах, много очень грамотных и удачных реализаций.
попробуйте с drupal.org (именно ядро как CMF)
среди модулей естественно есть как грамотные, так и…
среди модулей естественно есть как грамотные, так и…
Среди меня есть мнение, что любой велосипед основан на предыдущем, личном опыте, и если вы осознаёте, что это велосипед, значит опыт этот вам вреден. Например, вы сделаете «модульность», а в непредвиденной ситуации она не поможет и вы будете делать модуль в котором забабахаете всё по старинке, и все следующие модули будут такими же.
«Пичаль» при старте, дальше стало не интересно
Warning: Smarty error: unable to read resource: «stage0.tpl» in W:\work\test\kernel\classes\Smarty\Smarty.class.php on line 1092
Warning: Smarty error: unable to read resource: «stage0.tpl» in W:\work\test\kernel\classes\Smarty\Smarty.class.php on line 1092
Зря вы с самого начали сели сразу на самые большие грабли и слазить уже не собираетесь по видимому.
Зачем выбрали sql в качестве хранилища по умолчанию? У вас же документы в cms — ну так и юзайте no-sql, а в дополнение бонусом получаете: кеширование, безопасность? асинхронность и версионность!
Зачем выбрали sql в качестве хранилища по умолчанию? У вас же документы в cms — ну так и юзайте no-sql, а в дополнение бонусом получаете: кеширование, безопасность? асинхронность и версионность!
А обновляться, кстати, можно средствами какой-нить VCS (SVN, Git и иже с ними). Считай система сама знает какие файлы действительно обновились, а какие трогать не надо. А то приходиться вручную релизы сравнивать, чтобы свои правки не затереть. Правда конечно подготовка юзера должна быть повыше ради таких прелестей.
Реализовывать какой-то VCS протокол средствами PHP? Увольте, но я лучше средствами VCS и шелла при коммите билда подготовлю замену изменившимся файлам и выложу их теми же средствами на http/ftp. А в самой CMS реализую процедуру проверки «нет ли чего нового» и, может быть, обновления. А своих правок в идеале быть не должно; если уж решились на это, то чтобы не сравнивать вручную релизы заведите себе репозиторий для оригинала CMS и сравнивайте хоть новые релизы со старыми, хоть новые релизы со своими средствами VCS — она для того и предназначена.
Причем тут вообще PHP? Я имею ввиду, что весь движок должен лежать на хостинге как рабочая копия. А вы на шелле будете вашей любимой VCS сливать обновления. Кто хочет только stable, кто хочет — cutting edge. А в админку уведомлялку присобачить и хватит :). Ну можно конечно консольные вызовы в админку обернуть, но все равно не сильно удобно будет.
Если уж на то пошло то он должен деплоиться из рабочей копии по хуку или ручками, а рабочей копии или её части быть доступной из веба, мягко говоря, необязательно. Но это мелочи, главное что большинство (ну, многие) хостеров не дают доступ к шеллу, а если дают, то не дают устанавливать свой софт (любимую VCS в данном случае)
читал. плакал. хотелось пристрелить.
прочитал и понял — проектируем жуткий монстр с 20 запросами на страницу.
но изобретение велосипеда — дело хорошее (если позволяют ресурсы).
сам изобрел не один, некоторые даже успешно крутят колеса.
сам изобрел не один, некоторые даже успешно крутят колеса.
А у меня не становиться.
Сначала была ошибка в Db.php 146 строчке, но потом почитал форум, исправил kernel.sql и теперь выдает
SQL Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DROP TABLE IF EXISTS labcms__groups' at line 1 at T:\home\virtual\labcms\kernel\classes\Db.php line 139
Array
(
[code] => 1064
[message] => You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DROP TABLE IF EXISTS labcms__groups' at line 1
[query] => DROP TABLE IF EXISTS labcms__groups;
[context] => T:\home\virtual\labcms\kernel\classes\Db.php line 139
)
Что делать? пробовал обе версии.
Сначала была ошибка в Db.php 146 строчке, но потом почитал форум, исправил kernel.sql и теперь выдает
SQL Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DROP TABLE IF EXISTS labcms__groups' at line 1 at T:\home\virtual\labcms\kernel\classes\Db.php line 139
Array
(
[code] => 1064
[message] => You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DROP TABLE IF EXISTS labcms__groups' at line 1
[query] => DROP TABLE IF EXISTS labcms__groups;
[context] => T:\home\virtual\labcms\kernel\classes\Db.php line 139
)
Что делать? пробовал обе версии.
В каждом втором резюме веб-разработчика, которое мне приходит, есть упоминания о том, что человек делал свою CMS. Если экстраполировать на всю совокупность веб-разработчиков, то можно представить себе эпическое кладбище всех CMS мира.
Кстати, как вы решили бороться с конфликтами в таблицах БД различных модулей.
К примеру модуль Каталог и ПростойКаталог, если их установить то видимо они займут таблицы products, categories и т.п. но поля у них могут быть разные, что делать?
К примеру модуль Каталог и ПростойКаталог, если их установить то видимо они займут таблицы products, categories и т.п. но поля у них могут быть разные, что делать?
Забавно, но каждый раз упомнув про mvc переходят к шаблонизатору. ща напишу капсом:
ПОЖАЛУЙСТО, ВЕЛОСИПЕДОСТРОИТЕЛИ, ИСПОЛЬЗУЙТЕ МОДЕЛИ, ХВАТИТ ПИСАТЬ SQL В КОНТРОЛЛЕРАХ
об остальном промолчу, грустно, но потенциал есть, вам бы в команду к хорошему программисту.
ПОЖАЛУЙСТО, ВЕЛОСИПЕДОСТРОИТЕЛИ, ИСПОЛЬЗУЙТЕ МОДЕЛИ, ХВАТИТ ПИСАТЬ SQL В КОНТРОЛЛЕРАХ
об остальном промолчу, грустно, но потенциал есть, вам бы в команду к хорошему программисту.
Поковырял немного ЦМСку:
1. error_reporting(E_ALL & ~E_NOTICE);
Стыдно должно быть, товарищ! Вы же не битрикс на коленках лабаете.
2. Система не запускается из поддиректории.
3. Из админки удалил раздел «админка» и всё :) Пипец.
1. error_reporting(E_ALL & ~E_NOTICE);
Стыдно должно быть, товарищ! Вы же не битрикс на коленках лабаете.
2. Система не запускается из поддиректории.
3. Из админки удалил раздел «админка» и всё :) Пипец.
1. Кто же спорит — error_reporting(E_ALL | E_NOTICE); хорошо и красиво, когда дело касается только собственного кода. А когда используются сторонние библиотеки, то вместо того чтобы их использовать в соответствии с API, начинаешь их ковырять на предмет облагораживания кода… Ну один раз можно на это отважиться… но ведь это приходится проделывать после выхода каждой новой версии. Возникает резонный вопрос — а нафига, собственно?
2. это изначально и не планировалось
3. А чего Вы ожидали?:)
2. это изначально и не планировалось
3. А чего Вы ожидали?:)
Админка — это часть системы, а не контента. Она должна быть «выше» контента. Она не может быть частью контента.
Вы же не можете из админки удалить папку «classes». Точно также из админки нельзя удалять админку.
Вы же не можете из админки удалить папку «classes». Точно также из админки нельзя удалять админку.
Админка тоже модульная. Можете ее чем-то дополнить или что-то убрать… А можете вообще использовать собственную. Так что налагать на нее какие-то дополнительные ограничение мне не представляется необходимым.
>>Админка — это часть системы, а не контента. Она должна быть «выше» контента. Она не может быть частью контента.
это кто так решил? это cms авторская, и архитектура авторская, избавляйте голову от стереотипов должно быть как у всех, вон у LiveStreet, что есть двигло хабра, тоже админка как плугин цепляется и что?
это кто так решил? это cms авторская, и архитектура авторская, избавляйте голову от стереотипов должно быть как у всех, вон у LiveStreet, что есть двигло хабра, тоже админка как плугин цепляется и что?
С момента удаления админки это перестаёт быть CMS-кой по определению. Это как «кастрированный плейбой».
Проще в код системы вставить проверку if ($id == 1) { throw new Exception(); } // что бы не возможно было удалить админку. Чем потом эту админку восстанавливать, когда какая-нибудь секретарша её шлёпнет.
Проще в код системы вставить проверку if ($id == 1) { throw new Exception(); } // что бы не возможно было удалить админку. Чем потом эту админку восстанавливать, когда какая-нибудь секретарша её шлёпнет.
Ну что же вы так, у нас тоже админка часть дерева и даже разделы в админке так же админятся в админке, рекурсия.
Конечно удаление надо ограничить и задать кучу вопросов, да и так просто не удалить когда уже подразделы у неё есть, зато это даёт возможность расширять, кастомизировать например под партнеров дизайн админки и/или вообще заменять её на удобную тому или иному клиенту.
Конечно удаление надо ограничить и задать кучу вопросов, да и так просто не удалить когда уже подразделы у неё есть, зато это даёт возможность расширять, кастомизировать например под партнеров дизайн админки и/или вообще заменять её на удобную тому или иному клиенту.
Статья отличная.
Что касается labcms.
CMS конечно сырая, багов и недоработок много, но я надеюсь что вы доведёте её до ума, и напишите на основе своих опытов ещё одну статью.
Что касается labcms.
CMS конечно сырая, багов и недоработок много, но я надеюсь что вы доведёте её до ума, и напишите на основе своих опытов ещё одну статью.
Локи, видно, что вы затратили много усилий на создание CMS. Скажите, а какие цели вы преследовали? вы хотели получить опыт создания собственной системы с нуля или вы хотели помочь другим, решив для них какую-то востребованную задачу, какую? или что-то другую?
понравилось то, что вы помогаете людям на форуме разобраться с системой
не понравилось то, что система писалась для «для программистов» :(
понравилось то, что вы помогаете людям на форуме разобраться с системой
не понравилось то, что система писалась для «для программистов» :(
Изначально писалась для собственных нужд. Чтобы был некий удобный набор «кубиков» для создания сайтов. Потом пришла мысль что этими кубиками можно поделиться с другими, систематизировав их и обернув в единый интерфейс. А потом пришла следующая мысль, которая заключалась в том, что программистам такая система не нужна, так как каждый из них пишет аналогичную:) Так что вектор переместился на пользователей: как можно больше «механики» упрятано вглубь, как можно больше всего управляется кнопочками через интерфейс. Вот в этом направлении сейчас ее и развиваю.
с программистами это вы верно подметили, каждый пишет своё :) позвольте немного советов:
— вы интересно пишите, вам стоит писать статьи для пользователей. Расскажите им, как легко управлять сайтом на вашей системе. И пишите не только на хабре – тут профи, публикуйте везде где можете.
— снимите небольшой ролик, покажите, как за 1 час сделать сайт на вашей системе (попробуйте Camtasia)
— порекомендуйте пользователям хостинг, чтобы ваша система гарантированно там стартовала, я читал на вашем форуме о проблемах с хостингом. снимите эту головную боль с пользователя и у них будут твёрдое убеждение, что вас легко устанавливать.
— поместите на сайт 5-7 ярких скриншотов вашей системы. пользователи любят лазами :)
— сделайте на сайте раздел «они уже пользуются LabCMS». опишите эти проекты. пользователям будет психологически легче начать использовать вашу систему, если они будут знать, что они не одни такие :)
— попросите тех, кто уже пользуется вашей системой написать о вашей системе 2 предложения. Разместите на сайте эти хвалебные речи и укажите ФИО автора (с фото будет ещё лучше). Это добавит веса вашим заявлениям о том, что система действительно гибкая, удобная, и быстрая. В это будет легче поверить.
— Установите личный контакт с вашими пользователями. напишите на сайте о себе/о команде. Сейчас многие сайты безликие. А если вы расскажите на сайте о себе, поместите фото, вашим пользователям будет приятнее иметь дело с вашей системой. Они будут знать, что ей занимается человек/ команда. А не какой-то аноним, которому страшно доверять.
— вы интересно пишите, вам стоит писать статьи для пользователей. Расскажите им, как легко управлять сайтом на вашей системе. И пишите не только на хабре – тут профи, публикуйте везде где можете.
— снимите небольшой ролик, покажите, как за 1 час сделать сайт на вашей системе (попробуйте Camtasia)
— порекомендуйте пользователям хостинг, чтобы ваша система гарантированно там стартовала, я читал на вашем форуме о проблемах с хостингом. снимите эту головную боль с пользователя и у них будут твёрдое убеждение, что вас легко устанавливать.
— поместите на сайт 5-7 ярких скриншотов вашей системы. пользователи любят лазами :)
— сделайте на сайте раздел «они уже пользуются LabCMS». опишите эти проекты. пользователям будет психологически легче начать использовать вашу систему, если они будут знать, что они не одни такие :)
— попросите тех, кто уже пользуется вашей системой написать о вашей системе 2 предложения. Разместите на сайте эти хвалебные речи и укажите ФИО автора (с фото будет ещё лучше). Это добавит веса вашим заявлениям о том, что система действительно гибкая, удобная, и быстрая. В это будет легче поверить.
— Установите личный контакт с вашими пользователями. напишите на сайте о себе/о команде. Сейчас многие сайты безликие. А если вы расскажите на сайте о себе, поместите фото, вашим пользователям будет приятнее иметь дело с вашей системой. Они будут знать, что ей занимается человек/ команда. А не какой-то аноним, которому страшно доверять.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CMS своими руками. Теория велосипедостроения