Комментарии 137
Спасибо большое!
Сегодня, несколькими часами позже как раз ожидает создание (доработка) сайта на NetCat, теперь, надеюсь, он будет на качественно высшем уровне.
Быть может напишите еще что-нибудь интересное про данную систему? Хинты какие-нибудь или просто советы/мысли/идеи?
Сегодня, несколькими часами позже как раз ожидает создание (доработка) сайта на NetCat, теперь, надеюсь, он будет на качественно высшем уровне.
Быть может напишите еще что-нибудь интересное про данную систему? Хинты какие-нибудь или просто советы/мысли/идеи?
Вот тут есть материал о том, как включить отладку SQL запросов и сделать эмуляцию кэширования «тяжёлых» блоков.
Я анализировал NetCat и многие другие…
Не только он один грешит этим.
Я вообще не понимаю как можно терять контроль над количеством запросов…
Как можно терять контроль над переменными, классами, функциями.
Извините, скажу как разработчик — это все ошибки в архитектуре, изначально была заложена «ошибка»
Не только он один грешит этим.
Я вообще не понимаю как можно терять контроль над количеством запросов…
Как можно терять контроль над переменными, классами, функциями.
Извините, скажу как разработчик — это все ошибки в архитектуре, изначально была заложена «ошибка»
Согласен. Многие грешат, потому и написал, что это может быть интересно не только тем, кто работает с NetCat.
А ещё важно понимать как оно всё работает там, внутри, а не просто складывать сайты как конструктор.
А ещё важно понимать как оно всё работает там, внутри, а не просто складывать сайты как конструктор.
Например, почему не реализовать иерархию обьетов, а модули подключать контроллером в зависимости от иерархии, а не от модулей?
Тогда не надо хуками вылавливать другие модули из вызванных модулей.
Поставил флаги включения модулей и вызывай (плюс ко всему со своими правилами и параметрами), тогда же можно и вызвать модель view через контроллер.
Тогда легче вести контроль над запросами и классами.
А сейчас пока в cms-х наблюдаю разброд и шатание. Ну еще drupal как-то упорядочен и есть стратегия, хотя и там есть заблуждения в архитектуре.
Короче эта отдельная тема топика в «Я пиарюсь» :)
Только врядли напишу, после войн с детьми :)
Тогда не надо хуками вылавливать другие модули из вызванных модулей.
Поставил флаги включения модулей и вызывай (плюс ко всему со своими правилами и параметрами), тогда же можно и вызвать модель view через контроллер.
Тогда легче вести контроль над запросами и классами.
А сейчас пока в cms-х наблюдаю разброд и шатание. Ну еще drupal как-то упорядочен и есть стратегия, хотя и там есть заблуждения в архитектуре.
Короче эта отдельная тема топика в «Я пиарюсь» :)
Только врядли напишу, после войн с детьми :)
Чем выше уровень абстракции, тем меньше контроль над количеством запросов. Это логично, и в этом есть свои преимущества.
Если писать собственные запросы вместо стандартных функций, таки нахрена вообще этот неткат? Тем более для сложных проектов. Видел я пару таких… Если уж говорить начистоту, то для проектов с посещаемостью меньше 100 человек в день нет смысла изголяться, а больше — уже не неткат.
Большая часть времени при разработке уходит на создание удобного back-enda. А в неткате он уже есть готовый. Да и написать пару запросов самому не такая уж тяжёлая задача. Особенно умеючи ;)
На самом деле, я и имею ввиду удобный бэкэнд. Но он нужен не для того, чтобы в нём ломиком ковыряться. Мне просто на одном из мест работы пришлось делать сайты на неткат. И сделал я их порядка 30, пока не уговорил начальника пересесть на рельсы. Теперь потихонечку оргазмирую на рабочем месте от их крутости. А неткат — как страшный сон, иногда возвращается, чтобы добавить функционала к готовым проектам. Так что я знаю о чем говорю, товарищ :)
Да я тоже знаю о чем говорю. Среди решений «из коробки» неткат не худший, особенно если хорошо его знаешь.
Я его не защищаю и не ругаю. Просто качество конечного продукта (сайта) во многом зависит от кривизны рук создателя, а не от инструмента, которым он пользуется.
Я его не защищаю и не ругаю. Просто качество конечного продукта (сайта) во многом зависит от кривизны рук создателя, а не от инструмента, которым он пользуется.
Главное вовремя прервать холивар…
;-)
;-)
Ой как точно замечено, после холиваров, потом уже ничего и не сможешь написать, даже если бы хотел
У нас сразу эмоционально тянутся к минусу в карме
:)
А потом спрашивают, а почему разработчики так мало пишут на habr-e топиков, у них наверно времени нет, или они такие крутые, что не хотят с нами разговаривать :)))
Сначал эти дети замордуют карму, а потом помощи просят :))
У нас сразу эмоционально тянутся к минусу в карме
:)
А потом спрашивают, а почему разработчики так мало пишут на habr-e топиков, у них наверно времени нет, или они такие крутые, что не хотят с нами разговаривать :)))
Сначал эти дети замордуют карму, а потом помощи просят :))
рельсы и джанго наше все. Сейчас пытаюсь забыть как страшный сон друпал :)
вот пересели вы на рельсы… проекты видимо маленькие? или тонкую настройку проводили? у меня сайты на рельсах все таки медленно работают. три монгрел сервера на коредуо 2GHz (там еще парочка приложений, но они совсем маленькие)
На коредуо на одном серваке при нормальной оптимизации и кешировании даже пхп выдаст максимум 30к уников в сутки, опять же все зависит от крутости проекта. На рельсах такого же эффекта можно добиться на двух серваках. При этом времени на проект будет затрачено на порядок меньше. Железо дешевле, чем труд программиста. А сейчас еще ядра 1.9 и 2.0 подтянутся. 1.9 не сильно уступает пхп. Но разговор был совсем не об этом.
Вы не совсем правы. На неткате есть проекты с неплохой посещаемостью. И они нормально работают. Просто надо всегда включать голову, чем бы ты не занимался.
Да это все понятно. Но для того, чтобы сделать что-то действительно стоящее на том же неткате, нужно приложить усилия, которые далеко не сопоставимы с оплатой за работу. Зато на руби — 50 строчек кода и 2 запроса к бд — блог с аяксовыми древовидными комментариями. Вот так вот :)
Спор о том что фреймворк лучше чем CMS? Или о чем?
хоть 2 запроса, а система тормозит как от 100.
на php можно всё тоже самое реализовать, только нужно либо самому уметь, либо как в вашем случае, пользоваться правильными фреймворками.
на php можно всё тоже самое реализовать, только нужно либо самому уметь, либо как в вашем случае, пользоваться правильными фреймворками.
Ну уж нет уж. Тормоза скрипта и узкие места — это две большие разницы. Все-таки общая производительность системы определяется количесвом этих самых узких мест. А для тормозов системы есть кеширование.
лан, про производительность было всердцах брошено, подкрутить можно что угодно. просто упоминание рельс, которые являются фрейморком с далеко не оптимальной скоростью работы, в контексте коробочной cms было неудачной идей. а приведённый пример можно реализовать на голом пыхе без проблем, тем более все мы знаем на чём написан самы популярны блоговый движок
Дак в том то и дело, что разговор был совсем не о производительности фреймворка или интерпретатора, а о производительности кодера. И удобстве использования системы. В современном мире счет идет на минуты и никто не имеет права тратить время на изобретение велосипедов. На голом пыхе :) И у фреймворка как раз производительность нехилая, его пишут умные люди. Тут проблема в интерпретаторе руби. А точнее, в особенностях синтаксиса и архитектуры языка.
да, проблема не в ROR, который мне местами очень импонирует.
ты просто пытаешься сравнить фреймкорк с кмс. да, на роре можно быстренько написать форум, а кмс предпологает, что форум уже готов и его нужно только настроить. это проблема нашего бизнеса, что они пытаются доделывать кмс вместо того, чтобы писать систему сразу под себя. для визитки такой подход подходит, а для сложного проекта нет.
ты просто пытаешься сравнить фреймкорк с кмс. да, на роре можно быстренько написать форум, а кмс предпологает, что форум уже готов и его нужно только настроить. это проблема нашего бизнеса, что они пытаются доделывать кмс вместо того, чтобы писать систему сразу под себя. для визитки такой подход подходит, а для сложного проекта нет.
Все дело в том, что идентичные задачи редко встречаются. Следовательно — переписывание кода. Нестандартные задачи и рюшечки разные — переписывание кода. Для меня что фреймворк, что цмс — две стороны одной медали, два разных подхода, я не спорю что что-то подходит лучше для одних задач, а что-то для других, так и есть. Но в повседневной практике:
а). Очень тяжело переключаться с одного на другое, если пытаться к каждой задаче подбирать инструмент
б). Время разработки коррелируется, если выбрать что-то одно и не сходить с намеченного пути. Потому что распределение нестандартных задач и стандартных одно и то же на большом промежутке времени.
Исходя из этих соображений, я имею право сравнивать фреймворк и цмс, как инструменты с идентичным предназначением.
а). Очень тяжело переключаться с одного на другое, если пытаться к каждой задаче подбирать инструмент
б). Время разработки коррелируется, если выбрать что-то одно и не сходить с намеченного пути. Потому что распределение нестандартных задач и стандартных одно и то же на большом промежутке времени.
Исходя из этих соображений, я имею право сравнивать фреймворк и цмс, как инструменты с идентичным предназначением.
НЛО прилетело и опубликовало эту надпись здесь
я тут из-за 10 запросов то убиваюсь и выдумываю способы их уменьшить. Но 150…
Может лучше забыть о NetCat и использовать Drupal?
P.S. Обращение к разработчикам NetCat (если они вдруг прочитают).
Насчет документации — спасибо за совет, сейчас полностью переписывается Руководство разработчика к версии 4, идея хорошая, учтем. Кстати, сейчас среди партнеров проходит закрытое тестирование кеширования, в следующей версии оно уже будет.
Насчет документации — спасибо за совет, сейчас полностью переписывается Руководство разработчика к версии 4, идея хорошая, учтем. Кстати, сейчас среди партнеров проходит закрытое тестирование кеширования, в следующей версии оно уже будет.
Я получал письмо, но по ссылке, что в нем мне сказали, что у меня недостаточно прав :(
Какой-то я бесправный партнер :)
Какой-то я бесправный партнер :)
Только выходит кеширование на бета-тестинг :)))? %)
Да на нормальной icms, с точки зрения архитектуры, кеширование реализовывается таким же модулем, например в моем проекте, нет «хуков» кеширования в ядре, все реализовано, очень просто, контроллер вызывает модуль кеширования и всё :) Причем вызвать вы можете в любой части иерархии обьектов, и кешировать как блок, так и вызов модуля в блоке? отдавая результат куда — ну правильно в модель view :)))
Да на нормальной icms, с точки зрения архитектуры, кеширование реализовывается таким же модулем, например в моем проекте, нет «хуков» кеширования в ядре, все реализовано, очень просто, контроллер вызывает модуль кеширования и всё :) Причем вызвать вы можете в любой части иерархии обьектов, и кешировать как блок, так и вызов модуля в блоке? отдавая результат куда — ну правильно в модель view :)))
долго пытался понять, при чём здесь netcat
А я первым делом подумал о системной утилите netcat ) Где-то на Хабре проскакивала информация о том, как с её помощью сделать простенький сайт.
Очень очень верное замечание автора, о том что голову нужно включать при разработке проектов. Особенно используя NetCat, которая (в некотором смысле) позиционирует себя как «универсальная» CMS. То есть пригодная для разработки любых проектов. Я полагаю что такая архитектура предполагает некий избыточный функиционал. Я думаю всем понятно, что ручками можно сделать все оптимальней и круче — но! только под один конкретный проект — Чудо оптимизированный запрос/таблицу/процедуру e.t.c
А кеш зачем? Или его там нет?
будет в готовящейся 4-ой версии.
что можете заметить в комментарии: habrahabr.ru/blogs/webdev/43485/#comment_1079742
что можете заметить в комментарии: habrahabr.ru/blogs/webdev/43485/#comment_1079742
У меня остались только негативные воспоминания после использования этой системы. Сам являюсь разработчиком и многое просто приводило в ужас — как неудобно. Такое ощущение, что она полностью делалась для программистов, а для простого клиента изменить, скажем, порядок в шаблоне — подобно пыткам.
ммм… что есть порядок в шаблоне?
ну порядок вывода элементов в списке тех же публикаций.
я уже не говорю о постоянных escap'ах при каждом чихе.
я уже не говорю о постоянных escap'ах при каждом чихе.
А что не так с порядком вывода? Тем более, что этот порядок задаётся совсем не в шаблоне…
А вы скажите это заказчику, когда он хочет чтобы каждая вторая новость уходила с padding-left: 20px, и подствечивалась в другой div.
Знаете этим грешат 90% cms.
На модель view они забивают…
Особенно мне «нравится» таскание кода через все модули и ядро, за такое вообще руки надо вставлять в другое место.
Да когда вы поймете, что таскать через ядро и модули надо только данные. Потом обработанные данные отдать контроллером во view, где тоже продумать модель view, а не отдавать на растерзания шаблонизаторам…
сначала архитектурно описываем модель view а потмо передаем только шаблонизаторам или любому на вывод.
Если изначально подойти к разработке архитектуры под пользователя (особенно работы с темами и моделью view) — вы забракуете 99% cms.
P.S. кстати я изначально начал закладывать в своей архитектуре такую модель поведения.
На модель view они забивают…
Особенно мне «нравится» таскание кода через все модули и ядро, за такое вообще руки надо вставлять в другое место.
Да когда вы поймете, что таскать через ядро и модули надо только данные. Потом обработанные данные отдать контроллером во view, где тоже продумать модель view, а не отдавать на растерзания шаблонизаторам…
сначала архитектурно описываем модель view а потмо передаем только шаблонизаторам или любому на вывод.
Если изначально подойти к разработке архитектуры под пользователя (особенно работы с темами и моделью view) — вы забракуете 99% cms.
P.S. кстати я изначально начал закладывать в своей архитектуре такую модель поведения.
ИМХО, советы малоадекватные, т. к. я как разработчик должен кишки системы знать.
Значит система кривая!
Если я юзаю систему, она должна быть для меня юзабельна, а не я для нее.
И ни хочу даже ничего слушать! :)
Значит система кривая!
Если я юзаю систему, она должна быть для меня юзабельна, а не я для нее.
И ни хочу даже ничего слушать! :)
«нормальное дело» для больших цмс. 1-2 сотни запросов это норма если вы используете обвешаный друпал или джумлу (про остальные, правда, не знаю). Спасает кэширование, есть мысль что если требуется не по-быстрому состряпать default_site, то лучше фреймворки
:)
200 запросов это нормально? Вы так думаете или делали проекты, потом проводили тестирование на нагрузке...?
200-я запросами при выводе, пусть даже и простыми вы положите сервер за раз. Вам и кеширование не поможет.
Уж извнините, я бы уменьшил порядок до от 30 до 50 при хорошем (тяжелом) проекте ну и плюс все виды кеширования, от пассивного до активного.
И что такое «больших cms» — монстров с неправильной архитектурой? Поэтому они и превратились в монстров, потому что ни архитектуры не было, ни стратегии, просто куча кода…
200 запросов это нормально? Вы так думаете или делали проекты, потом проводили тестирование на нагрузке...?
200-я запросами при выводе, пусть даже и простыми вы положите сервер за раз. Вам и кеширование не поможет.
Уж извнините, я бы уменьшил порядок до от 30 до 50 при хорошем (тяжелом) проекте ну и плюс все виды кеширования, от пассивного до активного.
И что такое «больших cms» — монстров с неправильной архитектурой? Поэтому они и превратились в монстров, потому что ни архитектуры не было, ни стратегии, просто куча кода…
Лично видел проект с 1200+ запросов/страницу и сервер жил :) Плохо, но жил.
Обходите стороной разработчиков того проекта ;)
Разве это жизнь?..
1200+ это клиника уже…
Это нверно не веб, это скорее всего какая-нибудь бухгалтерия… им все равно за сколько отдавать данные.
Умножте кол-во запросов на среднее время выполнения… вы думаете юзер будет ждать больее 10 секунд открытие страницы?
Все заканчиваем холивар…
Видел и делал — разные вещи.
Читаем и учим мат. часть, особенно по поводу оптимизации запросов + высоконагруженные БД
И хорош срать в карму, без аргументов.
Это нверно не веб, это скорее всего какая-нибудь бухгалтерия… им все равно за сколько отдавать данные.
Умножте кол-во запросов на среднее время выполнения… вы думаете юзер будет ждать больее 10 секунд открытие страницы?
Все заканчиваем холивар…
Видел и делал — разные вещи.
Читаем и учим мат. часть, особенно по поводу оптимизации запросов + высоконагруженные БД
И хорош срать в карму, без аргументов.
Это не жизнь, это — существование :)
Количество запросов от нагрузки не очень зависит (Ну друпал может переводится, в режим экономии и опятьже много кэшировать, но все равно оптимизации кода на лету пока не придумали, а ленивых я не припомню для цмсок:). Поставьте друпал, модуль views (очень популярный), забейте немного данных и вьюху для них и модуль devel вам все покажет. Не так давно в интенетах пробегало сравнение техже друпала и джумлы и друпал при таких вот показателях оказался более экономным. По поводу того что мне что-то там не поможет: в CMS обычно кроме базы стандартных и необходимых модулей есть еще определенный API. Т. е. конечно можно лезть в ядро и переписывать все подряд или изобретать свои оптимизированные велосипеды, но это все потом придется поддерживать и может быть даже обновлять. Архитектура у джумлы и друпала вполне себе нормальная (кому-то нравится кому-то нет, но стройная система с которой работают много много разработчиков везде присутствует), просто они универсальны сразу имеют много наворотов (вроде интернационализации, расширяемости, подсистем модулей и шаблонов и много т. п.) отсюда и оверхеды такие.
1-2 сотни запросов — это не нормально при любом раскладе!
Не уверен, что те кто делали сайт вообще обращали внимание на скорость. И даже в ужас не надо приходить — вам ведь заплатят за оптимизацию, а им — нет. Закономерное развитие событий. Если бы все сайты изначально делали хорошо, они бы стоили очень дорого и не факт что вообще бы появились.
Вы это серьёзно?
Это же веб — закон таков: юзер за 5 секунд не увидел страницы, он оттуда сваливает!
(читаем маркетинговые исследования)
Понятное дело почему дешево сейчас стоят, извините наплодились ламеры, которые думают, что они великие дизайнеры и давай демпинговать и всовывать подделки.
А вообще разработка качественного веб ресурса, это кропотливая работа, не только верстальщика, но и маркетинга, оптимизаторов, инженеров- програмистов, менеджеров.
Лучше не отвечайте на этот пост :) а то опять подымится холивар :))
Это же веб — закон таков: юзер за 5 секунд не увидел страницы, он оттуда сваливает!
(читаем маркетинговые исследования)
Понятное дело почему дешево сейчас стоят, извините наплодились ламеры, которые думают, что они великие дизайнеры и давай демпинговать и всовывать подделки.
А вообще разработка качественного веб ресурса, это кропотливая работа, не только верстальщика, но и маркетинга, оптимизаторов, инженеров- програмистов, менеджеров.
Лучше не отвечайте на этот пост :) а то опять подымится холивар :))
150 это не так много :)
Делал я как то интернет-магазин на Koobi, так там более 400 запросов было на страницу. По началу всё быстро летало, но по мере роста количества товаров(сейчас >30000) и категорий (сейчас ~20) начало страшно тормозить. Вылечилось созданием дополнительных индексов, кешированием запросов и переписыванием некоторых процедур (были запросы в цикле).
Делал я как то интернет-магазин на Koobi, так там более 400 запросов было на страницу. По началу всё быстро летало, но по мере роста количества товаров(сейчас >30000) и категорий (сейчас ~20) начало страшно тормозить. Вылечилось созданием дополнительных индексов, кешированием запросов и переписыванием некоторых процедур (были запросы в цикле).
Не знаю. Когда в моих проектах, которые писались «с нуля», число запросов доходило до 20, то я начинал нервничать :)
Но тут увы, любой фреймворк и любая cms во многом избыточны и приходится таскать за собой некоторые ненужные вещи, расплачиваясь за некоторое удобство.
Но тут увы, любой фреймворк и любая cms во многом избыточны и приходится таскать за собой некоторые ненужные вещи, расплачиваясь за некоторое удобство.
Я тоже поначалу волновался, остановился на исследованиях, где тяжелые запросы надо разделять, но кол-во не должно превышать ~50 при 10-15 блоках без кеширования.
В принципе легкие запросы на выборку сильно не положат базу, другое дело, когда потерян контроль этих запросов…
Я тяжелою логику раздели на пару запросов, этого достаточно. Все же left join на большом наборе данных нагружает сервер сильнее.
Еще пользуйтесь union, только не переборщите… в итоге вы должны получить не более 50 запросов, дальше (порядок) уже начинается нагибание сервера.
В принципе легкие запросы на выборку сильно не положат базу, другое дело, когда потерян контроль этих запросов…
Я тяжелою логику раздели на пару запросов, этого достаточно. Все же left join на большом наборе данных нагружает сервер сильнее.
Еще пользуйтесь union, только не переборщите… в итоге вы должны получить не более 50 запросов, дальше (порядок) уже начинается нагибание сервера.
Когда вы сказали про koobi — дальше можно и не продолжать…
Качественный код (ну понятное дело — немцы)
и ужасная архитектура (понятное дело — войну нам стратегически проиграли)
Когда вы выбираете cms, в первую очередь смотрите на архитектуру проекта, потому что при большой нагрузке — выплывают все ошибки архитектуры.
Кстати 30000 товаров это не так и много, и уже на 30000 так безбожно тормозит?
А теперь представьте 1M записей, без особой нагрузке со стороны юзеров? а если + нагрузка… не помогут никакие дополнительные серверы… а koobi то платный… а вы уже сделали под него проект! что делать!? кричать help? поздно, надо на начальном этапе анализировать долго и со специалистами.
Качественный код (ну понятное дело — немцы)
и ужасная архитектура (понятное дело — войну нам стратегически проиграли)
Когда вы выбираете cms, в первую очередь смотрите на архитектуру проекта, потому что при большой нагрузке — выплывают все ошибки архитектуры.
Кстати 30000 товаров это не так и много, и уже на 30000 так безбожно тормозит?
А теперь представьте 1M записей, без особой нагрузке со стороны юзеров? а если + нагрузка… не помогут никакие дополнительные серверы… а koobi то платный… а вы уже сделали под него проект! что делать!? кричать help? поздно, надо на начальном этапе анализировать долго и со специалистами.
Я разве не прав имхо?
Опять аргументов нет… не будьте троллями — аргументируйте свои действия.
Зацепили вашу любимую игрушку? Для этого и существуют соц. сети чтобы обсуждать.
Опять аргументов нет… не будьте троллями — аргументируйте свои действия.
Зацепили вашу любимую игрушку? Для этого и существуют соц. сети чтобы обсуждать.
Не бывает панацеи, особенно сложно увидеть на начальном этапе все подводные камни конкретного решения. Проблемы нужно решать по мере их поступления, сегодня сайт — новости и гостевуха, завтра — магазин, блоги, облако тегов и новости с возможностью вывода связанных объектов. Оптимизация отдельная тема, при правильной реализации это очень эффективно, для любых web проектов.
По поводу сделано для программистов, а не для пользователей.
Написать код под всех пользователей — не представляется возможным! Нужно точно знать где требуются усилия разработчика сайта, а где правки пользователя.
Я так понимаю автор топика тестировал полную версию системы со всеми включенными модулями, с предустановленным готовым сайтом из пакета инсталляции, которые сделан для того чтобы показать максимально раздутые возможности системы, а не для реального использования.
Написать код под всех пользователей — не представляется возможным! Нужно точно знать где требуются усилия разработчика сайта, а где правки пользователя.
Я так понимаю автор топика тестировал полную версию системы со всеми включенными модулями, с предустановленным готовым сайтом из пакета инсталляции, которые сделан для того чтобы показать максимально раздутые возможности системы, а не для реального использования.
Автор топика не тестировал, а приводил в чувство работающий проект, который был сделан человеком, почитавшим документацию по NetCat, но не понимающим суть некоторых вещей. Во много в этом вина документации где не сказано о подводных камнях подходов, которые там рекомендуют.
И я попытался донести некоторые вещи до общественности. Возможно это поможет кому-то обойти стороной те же грабли.
И я попытался донести некоторые вещи до общественности. Возможно это поможет кому-то обойти стороной те же грабли.
Маленький вопрос разработчика… :) не netcat конечно же. У меня своя готова.
А если вам не надо писать код, а создать правила (ну как в outlook express или mozilla tb — фильтры для почты, такого плана) —
так вы сможете общаться с cms?
Имхо я считаю что пользователя продукта не надо заморачивать на написание кода.
Пусть разработчики пишут модули.
При грамотной реализации архитектуры, все делается правилами, особенно когда иерархическая унифицированная cms. Причем правилами простейшими… и эта стратегия относится и к модулям тоже!
А если вам не надо писать код, а создать правила (ну как в outlook express или mozilla tb — фильтры для почты, такого плана) —
так вы сможете общаться с cms?
Имхо я считаю что пользователя продукта не надо заморачивать на написание кода.
Пусть разработчики пишут модули.
При грамотной реализации архитектуры, все делается правилами, особенно когда иерархическая унифицированная cms. Причем правилами простейшими… и эта стратегия относится и к модулям тоже!
Созданием сайтов должны заниматься специалисты! Даже созданием сайтов с использованием cms. Точка.
Тут уже вопрос реализации функционала и возможностей архитектуры, не думаю что можно создать архитектуру которая позволит делать всё, рано или поздно появится задача не решаемая стандартным API системы.
Конечно же, но представьте вы можете из cms простыми правилами — не лазя в код сделать соц. сеть или форум!
Причем правила действительно простейшие — они для управления контроллером (спасибо mvc :)
Как вам такое?
Если же уж очень специализировано и «плохо» — подключайте как обычно модули :)
Причем правила действительно простейшие — они для управления контроллером (спасибо mvc :)
Как вам такое?
Если же уж очень специализировано и «плохо» — подключайте как обычно модули :)
Отлично, жду с нетерпением сабжа для тестирования)
Да я бы давно написал бы уже в «Я пиарюсь»
Да после войны с троллями и кармадрочерами карма с 28 упала до минус 2,75
Только мне от этого не хуже… :)))
Хуже скорее тем кто минусовал, ну и ресурсу, а так же действительно тем кто хотел бы увидить что то новенькое…
После инвайтов будет и того хуже (уже заметил), я обычно не боюсь потерять карму, не ею живу :) Не мне от этого плохо.
Реальных аргументов я вижу очень мало — одни эмоции. А с другими разработчиками по вопросам технологий я общаюсь черз icq и т. п.
Здесь меня интересует обратная связь с пользователями, как им было бы легче работать и понятливее.
Да после войны с троллями и кармадрочерами карма с 28 упала до минус 2,75
Только мне от этого не хуже… :)))
Хуже скорее тем кто минусовал, ну и ресурсу, а так же действительно тем кто хотел бы увидить что то новенькое…
После инвайтов будет и того хуже (уже заметил), я обычно не боюсь потерять карму, не ею живу :) Не мне от этого плохо.
Реальных аргументов я вижу очень мало — одни эмоции. А с другими разработчиками по вопросам технологий я общаюсь черз icq и т. п.
Здесь меня интересует обратная связь с пользователями, как им было бы легче работать и понятливее.
>> представьте вы можете из cms простыми правилами — не лазя в код сделать соц. сеть или форум!
Ну нафик. Потому, что там обязательно будут грабли, залежи граблей. Так бывает всегда, когда пытаются сделать супер-пупер-мега-гипер универсальное решение.
Ну нафик. Потому, что там обязательно будут грабли, залежи граблей. Так бывает всегда, когда пытаются сделать супер-пупер-мега-гипер универсальное решение.
Rule Based CMS — фича такая будет)
Только автор не договаривает, что по настоящему сложный функционал придётся описывать довольно сложными правилами (серебряных пуль-то не бывает), а стало быть разработчику придётся учить новый язык (язык этих правил) и вылавливать блох в интерпретаторе этих правил (программ без ошибок тоже не бывает). Шило на мыло может выйти, php-over-php :).
Зачем?
Я не зря пытаюсь сделать легкую в понимании для именно пользователя. (кстати и разработчика тоже, чтобы ему им легче было писать модули, шаблоны, темы)
Вам тяжело например сделать правило для фильтра почты в outlook express?
Почти тоже самое и там.
Никаких языков!!! зачем? вы правильно сказали, никаких заморочек.
Заложено не в правилах? правила лишь расширяют возможности.
А в совершенно другой архитектуре cms, она не похожа не на одну.
Зачем мне как взрослому человеку создавать клон… я уже не в том возрасте. Просто свои навыки 15 лет программирования в десктопах (в основном БД) я перенес в веб.
Здесь толькое «новое» найдет себя на рынке. Я анализировал более 50 основных cms в течении года!
Да согласен есть пару моментов тяжелых в понимании, но самое главное что я ничего не выдумывал я взял самое лучшие из десктопных приложений, с которыми вы сталкиваетесь каждый день, поэтому имхо ничего тяжелого в понимание вы не найдете.
Я не зря пытаюсь сделать легкую в понимании для именно пользователя. (кстати и разработчика тоже, чтобы ему им легче было писать модули, шаблоны, темы)
Вам тяжело например сделать правило для фильтра почты в outlook express?
Почти тоже самое и там.
Никаких языков!!! зачем? вы правильно сказали, никаких заморочек.
Заложено не в правилах? правила лишь расширяют возможности.
А в совершенно другой архитектуре cms, она не похожа не на одну.
Зачем мне как взрослому человеку создавать клон… я уже не в том возрасте. Просто свои навыки 15 лет программирования в десктопах (в основном БД) я перенес в веб.
Здесь толькое «новое» найдет себя на рынке. Я анализировал более 50 основных cms в течении года!
Да согласен есть пару моментов тяжелых в понимании, но самое главное что я ничего не выдумывал я взял самое лучшие из десктопных приложений, с которыми вы сталкиваетесь каждый день, поэтому имхо ничего тяжелого в понимание вы не найдете.
Я с аутлуком не знаком, знаком с TB. И в TB по-настоящему сложные фильтры сделать просто нельзя. К тому же, фильтры для почты это совсем не то, что какая-нибудь хитрющая иерархическая соц-сеть с взаимодействием с внешними (не-http) ресурсами. Даже метафорически.
Ну почему, сам пользуюсь ТВ, супер сложностей там нет, там интуитивно понятно все, есть моменты, но они быстро находятся, что самое главное.
Ну, я не сказал фильтры, я бы сказал стратегия создания правил.
Дело в том что iCMS изначально создавалась как иерархическая система, а не реляционная, это было мне тяжело реализовать систему, а вот пользователям от этого только легче будет.
Да кстати, в cms более 50 обращение к БД на страницу нет :)
время выполнения всех запросов порядка 0,05 сек. вместе с php без кеша 0,1 cек.
Кеширование реализовано модулем! есть как активное — всего блока, так и пассивное (результатов запросов — его планирую убрать, ну не нужно оно, хватает и активного с головой, кеш и на активном можно обновлять при получинии изменения обьекта сущности)
Ну, я не сказал фильтры, я бы сказал стратегия создания правил.
Дело в том что iCMS изначально создавалась как иерархическая система, а не реляционная, это было мне тяжело реализовать систему, а вот пользователям от этого только легче будет.
Да кстати, в cms более 50 обращение к БД на страницу нет :)
время выполнения всех запросов порядка 0,05 сек. вместе с php без кеша 0,1 cек.
Кеширование реализовано модулем! есть как активное — всего блока, так и пассивное (результатов запросов — его планирую убрать, ну не нужно оно, хватает и активного с головой, кеш и на активном можно обновлять при получинии изменения обьекта сущности)
> Ну почему, сам пользуюсь ТВ, супер сложностей там нет
Сложностей нет, никто не спорит. Только сложное правило сделать там нельзя.
Ну покажите её скорей.
Сложностей нет, никто не спорит. Только сложное правило сделать там нельзя.
Ну покажите её скорей.
Работу? Или уже весь код ;)
Код не покажу, пока полностью не допишу.
На счет бета-тестирования можно рассматривать этот вопрос, это в личную, есть опрделенные требования к тестировщикам, одно из них «Соглашение о неразглашении»
Код не покажу, пока полностью не допишу.
На счет бета-тестирования можно рассматривать этот вопрос, это в личную, есть опрделенные требования к тестировщикам, одно из них «Соглашение о неразглашении»
Код, естественно.
з. ы. Кстати, застрахована ли эта система от «умелого» разработчика, типа описанного в посте? (это к вопросу о то, что ваша цмс не делает более 50 обращений к БД на страницу)
з. ы. Кстати, застрахована ли эта система от «умелого» разработчика, типа описанного в посте? (это к вопросу о то, что ваша цмс не делает более 50 обращений к БД на страницу)
Вы врядли сможете сможите привысить эту планку :)
Основы API сделаны, вам достаточно будет пользоваться вызовами API.
Разве что если напишите свой модуль «доставания» данных из БД или напишите его не по документации, но вы сразу обнаружите ошибку, контроллер строго сигнализирует если правила выполняются неправильно, или он запутался в них, или если для одного вызова существуют несколько правил. Т. е. вы сразу всё увидите.
Вам останется только подправить правило, мало того даже правило можно изменять из front-end-a, я уже не говорю про редактирование контента и редактирование шаблона. Можно даже реализовать и добавление правила прямо из фронта, для конкретного блока (обычным модулем). Не забываем это иерархическая система — заблудится в ней — просто не реально. Всё подчиняется дереву контента.
Кстати а изменять запрос можно прямо из редактирования правил :) Это для стандартного модуля и там всего 5 параметров. Контроллер — это мозг (engine).
Основы API сделаны, вам достаточно будет пользоваться вызовами API.
Разве что если напишите свой модуль «доставания» данных из БД или напишите его не по документации, но вы сразу обнаружите ошибку, контроллер строго сигнализирует если правила выполняются неправильно, или он запутался в них, или если для одного вызова существуют несколько правил. Т. е. вы сразу всё увидите.
Вам останется только подправить правило, мало того даже правило можно изменять из front-end-a, я уже не говорю про редактирование контента и редактирование шаблона. Можно даже реализовать и добавление правила прямо из фронта, для конкретного блока (обычным модулем). Не забываем это иерархическая система — заблудится в ней — просто не реально. Всё подчиняется дереву контента.
Кстати а изменять запрос можно прямо из редактирования правил :) Это для стандартного модуля и там всего 5 параметров. Контроллер — это мозг (engine).
Не понял. Мне нельзя из модуля общаться с БД? Если можно, то все проверки идут лесом, потому что я могу написать рекурсивную функцию, например, в которой на каждом шаге рекурсии лезть в БД за тройным лефтджойном.
Понятно, что такое может прийти в голову только идиоту, но практика показывает, что такие существуют. Поэтому, выражение «наша ЦМС не генерирует более 50 запросов на страницу» не верно.
Понятно, что такое может прийти в голову только идиоту, но практика показывает, что такие существуют. Поэтому, выражение «наша ЦМС не генерирует более 50 запросов на страницу» не верно.
Ну почему нельзя :))) Своим модулем можите сколько хотите или «ломать» стандартные…
я имею ввиду из правил — вам просто не зачем, да и по вопросам безопастности тоже.
Делайте свой модуль, подключайте (но запомните пока вы его в правилах не включите — он у вас даже подключаться не будет) — там хоть 20 кратный лефтджоин, главное чтобы вы чувствовали себя хорошо :))
Поломать можно и японскую бензопилу, как в анекдоте :)
я имею ввиду из правил — вам просто не зачем, да и по вопросам безопастности тоже.
Делайте свой модуль, подключайте (но запомните пока вы его в правилах не включите — он у вас даже подключаться не будет) — там хоть 20 кратный лефтджоин, главное чтобы вы чувствовали себя хорошо :))
Поломать можно и японскую бензопилу, как в анекдоте :)
Если код нельзя по каким-то причинам, то пару примеров правил для какого-нть простенького форума/инет-магазина/новостного портала по вкусу, наверное можно рассекретить?
Есть ли возможность частичного кэширования? Например большой объём данных в котором периодически изменяется только одна какая нибудь связанная строчка. Можно кэшировать всё кроме этой строчки, а строчку обрабатывать при отдаче кэша?
Это что такое RB CMS? Такая в разработке?
Пока свою технологию назвал iCMS, CMS уже имеет и название и уже куплен домен в зоне .com
И уже крутит тестово сайты (пока не буду говорить какие, надо еще рефакторить код)
Кстати на 99% готова.
Немного надо порефакторить код, на предмет безопастности и «красоты» кода, все же писалась она 1,5 года (жаль только в свободное время)
Выпускать на рынок не собираюсь пока не будет документации, схем архитектуры и описания API, ну и конечно же рефакторинга. Т. е. еще работы хватает.
Кстати будет она open source. (не для себя делал)
Пока свою технологию назвал iCMS, CMS уже имеет и название и уже куплен домен в зоне .com
И уже крутит тестово сайты (пока не буду говорить какие, надо еще рефакторить код)
Кстати на 99% готова.
Немного надо порефакторить код, на предмет безопастности и «красоты» кода, все же писалась она 1,5 года (жаль только в свободное время)
Выпускать на рынок не собираюсь пока не будет документации, схем архитектуры и описания API, ну и конечно же рефакторинга. Т. е. еще работы хватает.
Кстати будет она open source. (не для себя делал)
Rule Based CMS — как вариант названия вашей разработки, можете использовать, если понравилось) Когда речь заходит о рефакторинге ещё не выпущенного продукта — в голове рождаются не очень приятные мысли, хотя кто знает.
Дональд Кнут: «Многие беды программирования проистекают от преждевременной оптимизации».
Дональд Кнут: «Многие беды программирования проистекают от преждевременной оптимизации».
Rule Based CMS — как вариант названия вашей разработки, можете использовать, если понравилось) Когда речь заходит о рефакторинге ещё не выпущенного продукта — в голове рождаются не очень приятные мысли, хотя кто знает.
Дональд Кнут: «Многие беды программирования проистекают от преждевременной оптимизации».
Дональд Кнут: «Многие беды программирования проистекают от преждевременной оптимизации».
:) спасибо
Обычно в конце работы над проектом — код всегда просматривают и тестируют на возможные, замечу возможные, ошибки в безопастности.
Часто отдают специальным фирмам, специализирующимся на рефакторинге кода (сам разработчик видит свою работу другими глазами), жаль дорого :)
Хуже наоборот, когда выпускают продукт и понятия не имеют о рефакторинге.
Когда я писал код, конечно же думал о безопастности в первую очередь!
Поэтому iCMS имеет разделение прав как по группам, так даже конкретно к определенным юзерам, как acl так и unix подобный вариант для иерархических обьектов, с наследование прав. (это все уже реализовано и работает)
Обычно в конце работы над проектом — код всегда просматривают и тестируют на возможные, замечу возможные, ошибки в безопастности.
Часто отдают специальным фирмам, специализирующимся на рефакторинге кода (сам разработчик видит свою работу другими глазами), жаль дорого :)
Хуже наоборот, когда выпускают продукт и понятия не имеют о рефакторинге.
Когда я писал код, конечно же думал о безопастности в первую очередь!
Поэтому iCMS имеет разделение прав как по группам, так даже конкретно к определенным юзерам, как acl так и unix подобный вариант для иерархических обьектов, с наследование прав. (это все уже реализовано и работает)
Будет здорово, если получится так как написано, но это уже как говорится со временем видно будет.
Уже работает, проходит закрытое бета-тестирование.
Все стандартные функции cms реализованы уже давно :)
Сейчас как раз тестирую расширения возможностей, понятливых для юзера, чтобы он своими руками мог сделать например соц. сеть из cms, причем юзеров не знающих php :)
Все стандартные функции cms реализованы уже давно :)
Сейчас как раз тестирую расширения возможностей, понятливых для юзера, чтобы он своими руками мог сделать например соц. сеть из cms, причем юзеров не знающих php :)
Мне кажется название iCMS будет весьма популярно среди поклонников прочих продуктов на i. Стоит только уточнить не забиндена ли (TM).
Это название технологии
hCMS как-то не звучит, я исходил с буквой «i» из названия «иерархическая» русского языка :))) да и если вызвать google: 3 лимона найденных
… а cms имеет другое название, исходя из маркетинговых целей, домен уже куплен в зоне .com, звучит прикольно, даже дети поймут :)))
Да забыл сказть. CMS изначально задумана как многоязыковая, многосайтовая, тест сайт крутится на 2 языках (там версия 6 мес. назад) — на локалке на трех. Переключается на другой язык очень лекго — сразу переходит на копию страницы в другом языке.
При этом например комменты совершенно другие, т. е. относящиеся к вызванному языку.
В качестве js fw используется jquery, в качестве редактора fckeditor (хотя можно подключить любой), в качестве php fw — не один не подошел, все же архитектура совсем другая, хотя много опыта из них взято.
hCMS как-то не звучит, я исходил с буквой «i» из названия «иерархическая» русского языка :))) да и если вызвать google: 3 лимона найденных
… а cms имеет другое название, исходя из маркетинговых целей, домен уже куплен в зоне .com, звучит прикольно, даже дети поймут :)))
Да забыл сказть. CMS изначально задумана как многоязыковая, многосайтовая, тест сайт крутится на 2 языках (там версия 6 мес. назад) — на локалке на трех. Переключается на другой язык очень лекго — сразу переходит на копию страницы в другом языке.
При этом например комменты совершенно другие, т. е. относящиеся к вызванному языку.
В качестве js fw используется jquery, в качестве редактора fckeditor (хотя можно подключить любой), в качестве php fw — не один не подошел, все же архитектура совсем другая, хотя много опыта из них взято.
Насколько разумно выводить комментарии на текущем языке, остальные будут отметаться?
Вы можите задать правилом, вывести на всех языках :)
Устнавливаете параметр «all» и вперед — если параметр не определен "" то выводится на действующем языке, если надо вывести конкретный (только зачем, когда по умолчанию выведет то что надо) вы можите указать язык. — например так как вы обзовете сущность корня для всего дерева. Например «ru», «en» и т. п.
Там всего один параметр. Просто может повториться копия другого языка (all) плюс оригинал, хотя обычно такое врядли бывает :)))
Это тяжело вообще-то на пальцах обьяснить — поверьте с языками там вообще проще простого.
Устнавливаете параметр «all» и вперед — если параметр не определен "" то выводится на действующем языке, если надо вывести конкретный (только зачем, когда по умолчанию выведет то что надо) вы можите указать язык. — например так как вы обзовете сущность корня для всего дерева. Например «ru», «en» и т. п.
Там всего один параметр. Просто может повториться копия другого языка (all) плюс оригинал, хотя обычно такое врядли бывает :)))
Это тяжело вообще-то на пальцах обьяснить — поверьте с языками там вообще проще простого.
Да забыл и у каждого модуля под каждую тему могут свои шаблоны вывода! Т. е. вы можите их редактировать и изменять, дополнять, да короче делать что хотите.
Или если нет такого шаблон вывод из темы по умолчанию :))
Что хочется реализовать… то что сделал MySpace — когда юзер для себя может загружать свои темы %) потом показывать свои страницы, дополнять виджетами и т. п.
в реализации сложного нет ничего (архитектурно заложена), там только вопрос безопастности (парсер надо правильно настроить, но так чтобы юзер мог много чего себе позволить и не опустить владельца)
Или если нет такого шаблон вывод из темы по умолчанию :))
Что хочется реализовать… то что сделал MySpace — когда юзер для себя может загружать свои темы %) потом показывать свои страницы, дополнять виджетами и т. п.
в реализации сложного нет ничего (архитектурно заложена), там только вопрос безопастности (парсер надо правильно настроить, но так чтобы юзер мог много чего себе позволить и не опустить владельца)
Да, насчет выхода статьи здесь — вы врядли увидите.
Тролли как обычно не дают выйти в плюс :)
Как выложу движок на свой домен, сначала организую там блог, там много и увидите, до выхода официального релиза.
Тролли как обычно не дают выйти в плюс :)
Как выложу движок на свой домен, сначала организую там блог, там много и увидите, до выхода официального релиза.
Рефакторинг рулит
прикольный получился PR — для iCMS :) а вы говорите — тролли, тролли ;)
Как система — хорошая, удобный интерфейс к БД радует, но апи и в особенности вложенные функции — просто ппц .
И как только сотовик на нем сделали… оО
И как только сотовик на нем сделали… оО
Вопрос к автору статьи по поводу пункта «Будьте аккуратны в использовании компонентов с полем «Файл».
Подскажите, каким образом всё же выводить объекты, в которых есть несколько файловых полей, чтоб уменьшить количество запросов?
Подскажите, каким образом всё же выводить объекты, в которых есть несколько файловых полей, чтоб уменьшить количество запросов?
Стараться избегать этих полей.
Можно переписывать логику работы в соответствующих местах исходников. Но вносить изменения придётся, скорее всего, после каждого обновления версии.
Можно написать свою функцию вывода подобных компонентов. Запрос там, естественно получится с join'ами. Затем создать дополнительный компонент, где в префиксе сделать вызов этой функции с необходимыми параметрами и именно этот компонент прикреплять к странице где нужен вывод объектов с файловыми полями.
Можно переписывать логику работы в соответствующих местах исходников. Но вносить изменения придётся, скорее всего, после каждого обновления версии.
Можно написать свою функцию вывода подобных компонентов. Запрос там, естественно получится с join'ами. Затем создать дополнительный компонент, где в префиксе сделать вызов этой функции с необходимыми параметрами и именно этот компонент прикреплять к странице где нужен вывод объектов с файловыми полями.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О том, как не надо делать сайты на NetCat