Кто писал свою CMS - есть вопрос

Toxic_Cat · 30 Дек 2005

Люди, ну Вы и наспорили...

Главное, чтобы Ваши проекты работали как надо и не поддавались хакеру

Вопрос конечно интересный, но судя по всему можно до бесконечности рассуждать

zarus · 30 Дек 2005

Автор оригинала: Popoff
Каждый, вообще-то, платит деньги за то, чтобы угодили именно ему. Массовость в моем случае - не означает ширпотреб низкого качества. Я делаю то, что делаю и так, как делаю не для того, чтобы сделать быстро и для всех, а для того, чтобы сделать качественно и быстро для того клиента, с которым я работаю в данный момент. То, что мой подход более массов - это один из возможных плюсов. Но вопрос о том, какой подход лучше для массовой разработки - это открытый вопрос, мы не можем ничего говорить. В моем подходе минусов не меньше, чем в подходе ONK, просто эти минусы разные. И плюсы тоже разные.

Вы считаете, что пользователи Windows платят за все, что в него входит? С прикорбием сообщаю, что 95% пользователей не знают и 10% того, что есть в системе, не говоря уже о возможностях MS Office. Сколько в месяц систем вы сможете создать и установить, если будете "переделывать" часть кода под конкретного клиента, и сколько уже готовых CMS Вы сможете продать, при условии, что и в том, и в том варианте поток клиентов будет непрерывным?
Вы же при покупке машины можете потребовать установку дополнительных "модулей", только потому что они изначально предусмотрены, но не внедрены, чтобы удешевить базовый вариант. Или Вы, как дилер автомобилей готовы лезть под капот каждого автомобиля, если только клиент покажет деньги и скажет хочу? "Любой каприз за Ваши деньги" - этот девиз устарел лет на 20, если не больше.

ONK · 30 Дек 2005

А отредактировать я не могу? А вдруг с ошибкой ввел?

Да конечно, были сомнения по этому поводу?

Кеширование как раз и имеет своей целью избавить сервер от необходимости постоянно делать ту работу, которую можно сделать один раз. Почему в случае с сообщениями в Вашем случае Вы считаете, что расходование ресурсов сервера не разумно, а в случае с кешированием вообще - предлагаете купить новый сервер? Вы не считаете, что то, что происходит у Вас - это и есть кеширование? Вы не считаете, что кешировать Вашим способом не выгодно, потому что автоматически теряется функциональность?

У меня нет кэширования, я просто подготавливаю данные для использования их в последствии наиболее оптимальным образом. И ещё я не теряю никакой функциональности, откуда взялось такое предубеждение. Ваш способ кэширования я вообще считаю мало эффективным (для правильно написанного приложения), у меня непосредственно время генерирования выводимой страницы занимает менее 20% времени работы скрипта, без кэширования опкода 70% времени это внутренние накладные расходы компилятора ПХП кода, и ваш способ кэширования только увеличит эти расходы. Дальше 10% времени тратится на обязательные операции движка системы, которые в любом случае должны быть выполнены. Таким образом на самой сложной для генерирования странице предложенным способом можно выиграть не более 20% производительности без кэширования опкода и не более 66% с кэшированием опкода.
Как видно такой способ кэширования почти не имеет смысла без кэширования опкода.
К тому же это всё теория, на практике в динамическом контенте практически нечего кэшировать, а те блоки информации, что можно кэшировать, можно хранить уже в подготовленном виде.

Подсказка - Если бы я занимался проблемой кэширования, я бы обратил пристальное внимание на возможности связки mod_rewrite + ПХП. Даже при поверхностном анализе возможностей предоставляемых mod_rewrite можно найти способ реализации высокоэффективного кэширования, при котором кэшированные страницы будут отдаваться пользователю непосредственно Апач-ем без участия ПХП. При правильной реализации по моим оценкам можно получить прирост производительности на 2 порядка.

Я не против того, что если функциональность не требуется, то можно сделать и так. Но при Вашем подходе система не является расширяемой. Любая новая фича - и действительно окажется, что минимум половину кода проще переписать с нуля. Но этот код не будет нужно переписывать с нуля, если его изначально просто написать по-другому. Это "по-другому" не требует каких-то особых затрат времени и энергии. О TDD можно говорить, что там требуются дополнительные затраты времени на создание тестов, но даже там ясно, что эти затраты потом с лихвой окупаются. В моем же случае даже этих начальных затрат нет.

Не понимаю, откуда берутся подобные выводы? С чего вы взяли, что ваша система более гибкая, чем моя? Неужели Вы изучили мой подход лучше, чем я сам?

Вы храните только в таком виде как будете показывать и не храните исходный вариант сообщения. Я Вас правильно понял?

Правильно.

Даже очень дешевый компьютер стоит в бесконечность раз больше бесплатного скрипта для кеширования. Если бы кеширование вносило хоть какую-нибудь сложность, я бы понял такие растраты. Но кеширование не вносит никаких сложностей. Чем оправдана покупка нового сервера?

Мы просто по разному мыслим, надо смотреть глубже, а не считать копейки. К тому же я привёл своё видение реальной эффективности вашей системы кэширования (с учётом того, что она не оригинальна, это относится ко всем попыткам сделать кэширование на уровне одного лишь ПХП кода).

Ядро системы, разработанной при помощи такой технологии, содержит в себе минимальный набор самых необходимых классов (или функций). Отсутствие сложного ядра упрощает применение этой технологии. Модули, разработанные с использованием этой технологии, выполняют ту и только ту функциональность, которая была оговорена с клиентом. Отсутствие лишней функциональности может упростить сопровождение. К недостаткам можно отнести то, что программные модули, разработанные с использованием этой технологии сложнее расширять, для добавления новых возможностей может потребоваться переписывать некоторую фунциональность с нуля, в системах, разработанных по этой технологии снижается уровень повторного использования существующего кода.

Нет технологии, есть подход, и не надо преждевременно делать ошибочных выводов. Сложное, или скорее многофункциональное ядро должно наоборот упрощать разработку модулей по сравнение с более примитивным. Я специально порылся в исходниках Вашего портала, чтобы развеять свои сомнения. И их больше нет, то что я увидел назвать более сложным и функциональным ядром чем то что есть у меня нельзя, скорее наоборот. Весь абзац следует списать на то, что у Вас сложилось неправильное общее впечатление.
Походы у нас действительно разные, но возможно не на столько, на сколько Вам кажется.

Я предлагаю заканчивать наш разговор, потому что сейчас мы с Вами, кажется, занимаемся банальным спором о том, чья технология лучше. Вы будете отстаивать свою технологию не только потому, что у нее есть объективные плюсы, но и потому, что Вы ее уже используете и для Вас переход на новую технологию связан с известными неудобствами.

Вы слишком плохо обо мне думаете.

Я вступил в переписку с вами не ради бесполезного спора, к тому же, заметьте, не не продвигаю здесь какой либо свой программный продукт. Мне интересна эта тема, и ищу узкие места в том, что я делаю и новые идеи. Из многих тем, в обсуждении которых я участвовал я вынес некоторые умные мысли, часть из которых в усовершенствованном виде нашла отражение в моём коде. Возможно, и эта тема поспособствует этому процессу. Как известно, для того чтобы что-то получить, надо что-то дать, именно по этому я стараюсь поддерживать в этой теме некоторую температуру, подкидывая некоторые идеи и споря с Вами.

Очень жаль, что никто более не хочет участвовать в обсуждении и делиться своими мыслями по этой теме, но будем откровенны, я тоже делюсь далеко не всем, чем владею и рассчитывать на подобное не разумно.

Для того, чтобы продолжить продуктивный разговор, следует написать достаточно полную документацию по используемым нами технологиями начиная от общей организации системы и вплоть до правил составления программных имен. Особое внимание, вероятно, следует уделить вопросу плюсов и минусов наших технологий. Некоторые из них мы уже рассмотрели в этом топике.

Мне очень нравится эта идея, более того, у меня есть необходимость в этом. Вопрос из этой серии висит надо мной уже больше года, и я всё никак не могу приступить к его решению.

Хочу внести некоторую ясность, между нашими системами нет критически глобальных различий, есть существенные различия между их компонентами (распределение прав,,,), и степень общей проработанности ядра. Никто не мешает писать сверх универсальные модули, работающие на моей системе. Более того, она больше для этого подходит, чем Ваша. Дело лишь в моих личных предпочтениях в этом вопросе.

zarus, на самом деле Вы меня причислили не к тому лагерю, видимо из-за того, что написал Popoff в своём сообщении. Мой подход - Простота и удобство для конечного пользователя, удобные средства «автоматизации программирования» не перегруженные непродуманной функциональностью удобное ядро, накладывающее минимум ограничений, но предоставляющее большой спектр возможностей + никаких ограничений для тех, кто хочет большего. Хочешь большего - делай.

texrdcom · 30 Дек 2005

А мне кажеться что не зря Zend пообещал разработку фреемворка базового

как только он выйдет, сразу пропадут такие споры а мое CMS круче

Конечно не которые люди все равно будут кричать что мое решения круче но слушать их врядли кто то будет

Popoff · 30 Дек 2005

Я, наверное, привел плохой пример в своей документации по модулю кеширования. Реально я использую этот модуль для кеширования довольно сложных вещей. Тормоз номер один в моей системе - это система многоязычности. Все сообщения хранятся в базе и для каждого выводимого сообщения производится запрос. С другими способами организации многоязычности я познакомился до того, как выбрал этот и при повторном выборе я выбрал бы этот же способ, а не какой-нибудь другой, поэтому выбор способа здесь пока не обсуждается. Взять, например, сообщение в этом форуме. Тут надписи: "Активист" (ввод пользователя у меня тоже может быть многоязычным), "на форуме с", "ноября", "город", название города, "URL сообщения" и т.п. (пусть всего их будет, к примеру, 10) - для каждой надписи выполняется как минимум один запрос. Возьмем страничку, на которой показывается десять сообщений. И как мне быть, чтобы количество запросов не выросло до 100? Красивая фраза "не загружать то, что уже загружено" мало что дает - это можно сделать, вопрос лишь в том, будет ли от этого проще, и нужно ли это?
http://popoff.donetsk.ua/text/work/light/faq/#many-sql

Другие варианты - та же предварительная подготовка данных для последующего использования, которая включает в себя парсинг сообщений форума, службы статей и новостей. Кешировать выгодно как можно более крупными блоками, поэтому на самом деле я не кеширую каждое отдельное сообщение в форуме - я кеширую сразу все сообщения.

Вы храните только в таком виде как будете показывать и не храните исходный вариант сообщения. Я Вас правильно понял?

Нажмите для раскрытия...

Правильно.

Тогда, Вы, наверное, делаете прямое (при сохранении) и обратное (при редактировании) преобразование?

С чего Вы взяли, что Ваша система более гибкая, чем моя?

Я сделал такой вывод по двум соображениям: 1) с точки зрения программиста - я не переписываю код с нуля (разве что только при рефракторинге я могу позволить себе такое удовольствие) и 2) с точки зрения пользователя - клиент получает дополнительные возможности, оставшивеся по наследству из старых версий. Я не против того, что эти возможности могут не потребоваться, но всегда приятно получить больше, чем просил. Тем более за ту же сумму; если я захочу отдельную оплату, то эта всегда будет отдельный модуль.

Следует понимать, что в каждом слове есть два смысла: описательное и эмоциональное. Описательное значение слова "гибкость" в моем понимании - это примерно то, о чем я написал выше. Эмоциональное значение фразы "система не гибкая" в понимании практически всех известных мне людей - в том, что "система плохая". Я ни в коем случае не считаю Ваш подход плохим. Из этих соображений я готов забрать обратно свое слово "гибкость" и заменить его любым другим, на Ваш вкус.

Если бы я занимался проблемой кэширования, я бы обратил пристальное внимание на возможности связки mod_rewrite + ПХП. Даже при поверхностном анализе возможностей предоставляемых mod_rewrite можно найти способ реализации высокоэффективного кэширования, при котором кэшированные страницы будут отдаваться пользователю непосредственно Апач-ем без участия ПХП.

Если честно, я затруднился найти такой способ (1.3.х). Я всегда думал, что знаком с mod_rewrite, но собственных мыслей не имею, да и сама эта возможность мне кажется странной для этого модуля - его назначение в преобразовании УРЛ и мне не свосем ясно, какое отношение кеширование имеет к преобразованию УРЛ. Если это не новая фича для 2.х, то можно в двух словах, в какие абзацы глянуть?

В любом случае, думаю мне такой способ не совсем подойдет - я все же люблю контролировать все на уровне РНР, но было бы интересно узнать о подобном применении mod_rewrite.

Очень жаль, что никто более не хочет участвовать в обсуждении и делиться своими мыслями по этой теме

Чтобы понять, о чем мы пишем, нужно мыслить так, как мы мыслим. К тому же мы пишем слишком много - чтобы разобраться, нужно не только слишком много читать, но и слишком долго вникать. Поэтому, мне кажется, наш разговор и проходит в почти гробовой тишине

Вопрос из этой серии висит надо мной уже больше года, и я всё никак не могу приступить к его решению.

Моя первая попытка была примерно года два назад. Я хочу описать, но поскольку особой необходимости именно в этой документации обычно не возникает, то вот руки до нее и не доходят. Может, из этого топика склепаю че-нить.

У меня, кстати, идея, как можно было бы узнать некоторые стороны наших подходов, которые могут казаться важными. Для этого можно описать какую-нибудь теоретическую задачу, которая, на Ваш взгляд, решается не слишком просто при использовании другого подхода или простое решение приводит к сложностям в сопровождении и попросить описать ее решение.

Например, реализовывали ли Вы когда-нибудь многоязычные приложения? Что Вы будете делать (конкретно: таблицы добавлять, поля дообавлять, скрипты модифицировать и т.п.), если в систему нужно добавить новый язык? Как осуществляется перевод динамического и статического содержимого?

Вы сдали работу и примерно через год эксплуатации клиент захотел, чтобы Вы добавили вап-версию разработанного Вами сайта. Ваши действия?

В Вашем форуме нет настройки для выключения, к примеру, смайлов в заданном топике. Что Вы будете делать, чтобы добавить такую настройку?

Реализовывали ли Вы когда-нибудь фичу, позволяющую глобально управлять гиперссылками - это когда я изменяю, к примеру, адрес статьи, то все ссылки на эту статью меняются автомтически?

Вы разработали какой-нибудь сложный программный комплекс, например, систему учета движения товара на предприятии (на РНР). Сначала клиент говорил, что для каждого типа изделия нужно указывать производителя. Когда проект завершен, выясняется, что нужно указывать не одного, а нескольких производителей. Ваши действия?

Как вариант - Вам сказали, что для изделий можно назначаь такие-то, такие-то и такие-то цены (например, для ювелирных изделий может быть оптовая, розничная, оптовая за грамм, розничная за грамм, с учетом угара металла или без него и т.п. - видов изначально довольно много), которые находятся в известных жестко заданных отношениях. Через некоторое время Вас просят добавить новый вид цены. Ваши действия?

Вы закончили проект, сдали его клиенту и тут выясняется, что клиент хочет воспользоваться дешевым хостингом (жадный попался, ничего не поделаешь), на котором блокируются любые гет-запросы, в которых есть последовательность "port". Все скрипты для управления аккаунтами пользователей включают в себя слово "passport". Ваша задача - переименовать "passport" в, к примеру, "pa". Что Вы будете делать?

Да, кстати, я так и не понял, как Вы решаете такую задачу: в форум нужно добавить ограничение активности пользователя. Что Вы делаете?

И еще один теоретический вопрос, какие у Вас критерии "обратной совместимости"? К примеру, у Вас есть две новые версии одного и того же скрипта. Как Вы определите, что один из них - обладает свойством обратной совместимости, а другой - не обладает?

texrdcom · 30 Дек 2005

ONK
Если я првильно понял вы против универсальных модулей в системах типа cms (в общем)
А Popoff за.
Честно говоря я за решения Popoff .
После разработки не которого количества web программ, и если откинуть всякие мелочи и посмотреть что мы создаем получаеться что все наши приложения не сложнения уровня гостевой книги

это не я придумал это выражения кого то с авторов php опубликованно в статьях на донном сайте.
И честно говоря когда я первый раз прочитал я не согласился с этим как так моя прога и гостевая книга !

Но сейчас я полностью согласен, Потому если разделить визуально представления с логикой приложения то вполне возможно добиться повторного использования модулей - с вытекающем отсюда повторным использованиям кода, чем четче отделяем бизнес логику от изображения, и от механизма анализа запросса пользователя тем больше шансов использовать повторно код модуля. Плюс всегда можно приминить наследования для перекрития кода.
p/s
Если я правильно понял причину вашего спора

Popoff - как вы активируете проверку прав пользователей в модулях вашей системы ?, и может ли модуль в вашей системе обращаться к другому модулю за получениям данных, и возможен ли запуск не скольких модулей одновременно ?

Popoff · 30 Дек 2005

возможен ли запуск не скольких модулей одновременно ?

Я почему-то вспомнил фразу Толстого: "делать ничего - гораздо хуже, чем ничего не делать"

О Вашем вопросы Вы можете почитать на моем сайте. Вот Вам ссылка:

ONK · 31 Дек 2005

texrdcom, читайте внимательнее то, что я пишу. Я не против универсальных модулей, мне не нравится описанная мною концепция «сверх универсальных модулей». К тому же, как выяснилось мы с Popoff по разному понимаем что есть «универсальный модуль». То, что он считает универсальным модулем, я называю «заготовкой» для создания специальных модулей. При этом я таки имею по настоящему универсальные модули и использую их.

Popoff

Тормоз номер один в моей системе - это система многоязычности. Все сообщения хранятся в базе и для каждого выводимого сообщения производится запрос. С другими способами организации многоязычности я познакомился до того, как выбрал этот и при повторном выборе я выбрал бы этот же способ, а не какой-нибудь другой, поэтому выбор способа здесь пока не обсуждается. Взять, например, сообщение в этом форуме. Тут надписи: "Активист" (ввод пользователя у меня тоже может быть многоязычным), "на форуме с", "ноября", "город", название города, "URL сообщения" и т.п. (пусть всего их будет, к примеру, 10) - для каждой надписи выполняется как минимум один запрос. Возьмем страничку, на которой показывается десять сообщений. И как мне быть, чтобы количество запросов не выросло до 100? Красивая фраза "не загружать то, что уже загружено" мало что дает - это можно сделать, вопрос лишь в том, будет ли от этого проще, и нужно ли это?

У Вас просто недостаточно проработанное в мелочах ядро системы, оно не предоставляет вам необходимую функциональность, решающую вашу проблему. Я тоже храню фразы многоязыкового интерфейса в СУБД, ещё я там храню десятки шаблонов, сотни конфигурационных переменных и вообще всё, с чем работаю. При этом у меня нет никаких проблем с излишком SQL запросов. Потому что модуль знает всё что ему может понадобиться и запрашивает это у системы перед запуском. Часть информации о наиболее важных потребностях модуля хранится в соответствующей таблице системы (я уже писал о инструментах управления модулями которые у меня есть), менее важная и более часто изменяемая часть этой информации хранится непосредственно в модуле и запрашивается перед его исполнением (например набор фраз многоязыкового интерфейса).

Тогда, Вы, наверное, делаете прямое (при сохранении) и обратное (при редактировании) преобразование?

Да, именно так. Но обратное преобразование не всегда требуется, если браузер пользователя поддерживает визуальное редактирование, сообщение можно отдавать в виде html кода.

Если честно, я затруднился найти такой способ (1.3.х). Я всегда думал, что знаком с mod_rewrite, но собственных мыслей не имею, да и сама эта возможность мне кажется странной для этого модуля - его назначение в преобразовании УРЛ и мне не свосем ясно, какое отношение кеширование имеет к преобразованию УРЛ. Если это не новая фича для 2.х, то можно в двух словах, в какие абзацы глянуть?

В любом случае, думаю мне такой способ не совсем подойдет - я все же люблю контролировать все на уровне РНР, но было бы интересно узнать о подобном применении mod_rewrite.

Мы все достаточно часто ошибаемся, всё от того, что нам лень читать документацию.

http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html

на первой же картике, демонстрирующей алгоритм работы mod_rewrite можно обнаружить участок выделенный красным цветом, позволяющий предположить наличие необходимой нам функциональности. Переходим к чтению описания директивы RewriteCond и обнаруживаем всё, что нам необходимо. Думаю, что дальше вы сами разберётесь как объединив эту функциональность с возможностями ПХП получить желаемый результат.

Например, реализовывали ли Вы когда-нибудь многоязычные приложения? Что Вы будете делать (конкретно: таблицы добавлять, поля дообавлять, скрипты модифицировать и т.п.), если в систему нужно добавить новый язык? Как осуществляется перевод динамического и статического содержимого?

Да, конечно. Зайду в «админцент->управление многоязыковым интерфейсом» там есть кнопка добавить поддержку нового языка. Если на неё нажать, то появится форма, предлагающая ввести идентификатор языка и его название на нём самом, а также на всех уже поддерживаемых языках. Там же есть все необходимые инструменты для поиска и редактирования фраз. С вводимым пользователями содержимым всё сложнее.

Вы сдали работу и примерно через год эксплуатации клиент захотел, чтобы Вы добавили вап-версию разработанного Вами сайта. Ваши действия?

Посмотрю, будет ли достаточно поменять шаблоны.

В Вашем форуме нет настройки для выключения, к примеру, смайлов в заданном топике. Что Вы будете делать, чтобы добавить такую настройку?

Думать… Вы сомневались? Или мне расписать здесь, как легко у меня добавляются новые конфигурационные переменные и редактируются шаблоны?

Вы разработали какой-нибудь сложный программный комплекс, например, систему учета движения товара на предприятии (на РНР). Сначала клиент говорил, что для каждого типа изделия нужно указывать производителя. Когда проект завершен, выясняется, что нужно указывать не одного, а нескольких производителей. Ваши действия?

Хотя я и не делал ничего подобного, но по более мелким проектам скажу, что подобные нюансы обычно всплывают при составлении ТЗ, если нет, то клиент платит ещё.

Как вариант - Вам сказали, что для изделий можно назначаь такие-то, такие-то и такие-то цены (например, для ювелирных изделий может быть оптовая, розничная, оптовая за грамм, розничная за грамм, с учетом угара металла или без него и т.п. - видов изначально довольно много), которые находятся в известных жестко заданных отношениях. Через некоторое время Вас просят добавить новый вид цены. Ваши действия?

Если у некой сущности есть множественная характеристика, для её хранения в любом случае будет предусмотрена отдельная таблица. Соответственно нет причин отказываться от автоматизации процессов генерирования форм отображения в интерфейсах отображения. Как раз в последнем проекте у основной сущности было много подобных характеристик.

Вы закончили проект, сдали его клиенту и тут выясняется, что клиент хочет воспользоваться дешевым хостингом (жадный попался, ничего не поделаешь), на котором блокируются любые гет-запросы, в которых есть последовательность "port". Все скрипты для управления аккаунтами пользователей включают в себя слово "passport". Ваша задача - переименовать "passport" в, к примеру, "pa". Что Вы будете делать?

Я не понял вторую часть вопроса. По первой части, если кратко, я не возьмусь за такой проект. Подобные вещи я предпочитаю выяснять до, а не после. У меня есть возможность предложить клиенту разные варианты хостинга с гарантированными для меня параметрами, попытку сэкономить 10 баксов я не оценю.

Да, кстати, я так и не понял, как Вы решаете такую задачу: в форум нужно добавить ограничение активности пользователя. Что Вы делаете?

Я решаю эту задачу. (Решил пару лет назад.)

И еще один теоретический вопрос, какие у Вас критерии "обратной совместимости"? К примеру, у Вас есть две новые версии одного и того же скрипта. Как Вы определите, что один из них - обладает свойством обратной совместимости, а другой - не обладает?

Об этом я написал ранее вполне понятно и полно, пока добавить мне нечего, а цитировать самого себя я не люблю.

Алексей Пешков · 31 Дек 2005

Я соглашусь с тем, что интерфейс моей системы привилегий не слишком удобен в использовании (имена привилегий прописываются в виде строк, а не выбираются галочками), но гибче, чем у меня, я пока что ничего не видел.

клиент получает дополнительные возможности, оставшивеся по наследству из старых версий. Я не против того, что эти возможности могут не потребоваться, но всегда приятно получить больше, чем просил.

Клиент получает раздутый унаследованный код, разобраться в котором не находит время и желание даже сам разботчик.

Popoff · 31 Дек 2005

Алексей Пешков
код чистый и понятный. как только я чувствую, что код становится сложным и непонятным - я его рефракторю вплоть до написания с нуля.

-~{}~ 31.12.05 12:01:

Алексей Пешков
сложность с галочками в системе привилегий состоит в том, что неизвестно какие галочки существуют, а какие - нет. почитай о базовых и динамических привелегиях. редактор с галочками - это просто надйстройка над моей системой, которую я еще не написал.

-~{}~ 31.12.05 12:09:

суть моего подхода не в том, чтобы избавиться от пересмотра старого кода - в этом нет ничего плохого. суть - в том, чтобы избавиться от переписывания с нуля по внешним обстоятельствам. если я решаю пересмотреть свой код, то это я решаю, и делаю это, как только появляется какое-нибудь свободное время. при другом же подходе я не только вынужден переписывать код с нуля по возникновению внешних обстоятельств, но и получаю множество версий одного и того же, каждую из которых я должен сопровождать.

-~{}~ 31.12.05 12:12:

именно таким спообом я и получил, к примеру, свою универсальную систему управления привилегиями. при раздутии кода это было бы много разных немножко более простых систем управления привилегиями, в каждом модуле - своя.

-~{}~ 02.01.06 01:12:

У Вас просто недостаточно проработанное в мелочах ядро системы, оно не предоставляет вам необходимую функциональность, решающую вашу проблему. Я тоже храню фразы многоязыкового интерфейса в СУБД, ещё я там храню десятки шаблонов, сотни конфигурационных переменных и вообще всё, с чем работаю. При этом у меня нет никаких проблем с излишком SQL запросов. Потому что модуль знает всё что ему может понадобиться и запрашивает это у системы перед запуском. Часть информации о наиболее важных потребностях модуля хранится в соответствующей таблице системы (я уже писал о инструментах управления модулями которые у меня есть), менее важная и более часто изменяемая часть этой информации хранится непосредственно в модуле и запрашивается перед его исполнением (например набор фраз многоязыкового интерфейса).

В моем случае для экономии ресурсов используется один универсальный способ - кеширование.

Для того, чтобы не расходовать зря ресурсы, Вы придумываете кучу разных способов для каждого случая - свой.

Сообщения Вы храните в каком-то промежуточном состоянии. Нехранение исходного сообщение приводит к известному минусу - может потребоваться обратное преобразования которое, в зависимости от остального подхода, может оказаться не всегда тривиальным или возможным. Я понимаю, что сообщения форума, особенно старые сообщения, редактируются очень и очень редко. Но я все же склоняюсь к мысли о том, что исходная копия лишней не будет.

Переводы и шаблоны Вы загружаете перед запуском модуля. Такой подход тоже не лишен минусов - нужно как-то заранее узнавать, что потребуется; точно узнать нельзя - может загрузиться что-нибудь лишнее, а что-нибудь - недогрузиться и тогда его придется подгружать потом.

Отличие Вашего подхода от моего в том, что Вы любите городить огород в начале, а я - в конце. Нельзя говорить о том, что городить огород в начале - значительно лучше, чем городить огород в конце. Лучше - это когда не требуется городить огород.

Но обратное преобразование не всегда требуется, если браузер пользователя поддерживает визуальное редактирование, сообщение можно отдавать в виде html кода.

А у Вас не существует конструкций, которые нельзя перевести назад? Например, у меня будет весьма затруднительно перевести назад цитирование. В службе статей таких непереводимых назад фич - пруд пруди: автоматическое содержание, фотогалерея, опросы... А вообще, мне кажется странным, когда я вводил одно, а при редактировании вижу совсем другое.

Мы все достаточно часто ошибаемся, всё от того, что нам лень читать документацию.

Я понял, о каком способе Вы говорите. Вы действительно считаете, что этот способ лежит на поверхности и для того, чтобы узнать о существовании этого способа, достаточно просто прочитать документацию? Я был знаком с RewriteCond и раньше, но о подобном способе никогда не задумывался.

Поздравляю! Вы объясняете как настоящий преподаватель. Так, чтобы ничего не было понятно. (с) Ю.В.

В Вашем форуме нет настройки для выключения, к примеру, смайлов в заданном топике. Что Вы будете делать, чтобы добавить такую настройку?

Нажмите для раскрытия...

Думать… Вы сомневались? Или мне расписать здесь, как легко у меня добавляются новые конфигурационные переменные и редактируются шаблоны?

У Вас конфигурационные переменные могут зависеть от темы форума? (форум -> темы -> топики -> сообщения)

Вы разработали какой-нибудь сложный программный комплекс, например, систему учета движения товара на предприятии (на РНР). Сначала клиент говорил, что для каждого типа изделия нужно указывать производителя. Когда проект завершен, выясняется, что нужно указывать не одного, а нескольких производителей. Ваши действия?

Нажмите для раскрытия...

Хотя я и не делал ничего подобного, но по более мелким проектам скажу, что подобные нюансы обычно всплывают при составлении ТЗ, если нет, то клиент платит ещё.

Вопрос, на самом деле, был немножко в другом. Суть в том, что это изменение, как мне кажется, невозможно внести, не изменяя структуру базы данных. Как Вы следите за обновлением структуры базы данных?

Да, кстати, я так и не понял, как Вы решаете такую задачу: в форум нужно добавить ограничение активности пользователя. Что Вы делаете?

Нажмите для раскрытия...

Я решаю эту задачу. (Решил пару лет назад.)

Нет.

У меня. Я рассматриваю активность пользователя как исходное данное. Чтобы добавить ограничение по активности, в моем случае нужно внести изменение в одном месте - непосредственно перед добавлением сообщения.

У Вас?

И еще один теоретический вопрос, какие у Вас критерии "обратной совместимости"? К примеру, у Вас есть две новые версии одного и того же скрипта. Как Вы определите, что один из них - обладает свойством обратной совместимости, а другой - не обладает?

Нажмите для раскрытия...

Об этом я написал ранее вполне понятно и полно, пока добавить мне нечего, а цитировать самого себя я не люблю.

Если Вам тяжело процетировать себя, то это сделаю я:

Автор оригинала: ONK
Это модуль поддерживающий простой способ обновления старой версии на более новую версию. При этом новая версия, добавляя новую функциональность, и исправляю выявленные ошибки, не приводит к какой либо потере работоспособности и сохраняет все настройки старой версии, т.е. имеет полную обратную совместимость.

Я также добавлю свою цитату по поводу обратной совместимости:

Автор оригинала: Popoff
у них - старая версия скрипта (скрипт не содержит в себе никаких настроек, только функции/классы), у нас - новая версия скрипта, они берут у нас новую версию скрипта, копируют поверх старой и у них все работает как и раньше, но добавлена новая функциональность и удалены глюки. Это?

Я задал свой вопрос, потому что в Вашем определении обратной совместимости не ясно, какой способ обновления Вы считаете простым и как Вы определяете сохранность всех настроек старой версии? Возможно также, у Вас есть какие-нибудь простые критерии непотери работоспособности, отличные от автоматических тестов?

Когда я пишу в этот топик, я думаю о том, как я смогу использовать написанное здесь. В частности, задавая этот вопрос, я думал о том, что хорошо бы сформулировать какие-нибудь критерии обратной совместимости. Например.

Признаки наличия обратной совместимости:
1. Для обновления достаточно простого копирования скриптов и/или шаблонов
2. Копируемые скрипты не содержат в себе никаких настроек. Если в копируемых скриптах содержатся настройки, то это настройки по умолчанию, которые могут быть переопределены в других файлах.
3. Если для копируемых скриптов введены новые настройки, то для этих настроек существуют знаения по умолчанию, которые будут использованы, если в старой инсталяции системы этих настроек еще не было. Дополнительно настраивать старую инсталяцию не требуется.
4. Изменения в структуре базы данных касаются только индексов.
5. ?

Признаки отсутствия обратной совместимости:
1. Изменена структура базы данных
2. Изменен формат хранения данных (например, раньше хранили bb-коды, а теперь - html).
3. ?

Имея формальные признаки наличия/отсутствия свойства обратной совместимости, мы можем сравнивать наши подходы. Например, "добавить кеширование в существующий скрипт проще, чем добавить предварительную обработку, потому что при добавлении предварительной обработки либо меняется структура базы данных (добавляется дополнительное поле, в котором хранится результат обработки), либо меняется формат хранения данных (раньше хранили исходный код, а теперь - результат обработки)".

-~{}~ 02.01.06 01:30:

Признак наличия свойства обратной совместимости для формата данных:
5. Формат данных является расширяемым и изменения в формате касаются его расширения. Формат данных является расширяемым тогда и только тогда, когда существующие скрипты игнорируют все то, что они не понимают или является для них неправильным и работают правильно при недостатке данных.

ONK · 2 Янв 2006

Сообщения Вы храните в каком-то промежуточном состоянии. Нехранение исходного сообщение приводит к известному минусу - может потребоваться обратное преобразования которое, в зависимости от остального подхода, может оказаться не всегда тривиальным или возможным. Я понимаю, что сообщения форума, особенно старые сообщения, редактируются очень и очень редко. Но я все же склоняюсь к мысли о том, что исходная копия лишней не будет.

Если пользователь решил создать таблицу шириной в 100к пикселей, или что ни будь другое, не разрешенное настройками фильтра html кода, то в зависимости от настроек фильтра html код этой таблицы будет либо отображен после обработки htmlspecialchars(), или просто удалён. Данные, находившиеся таблице, останутся в документе без каких либо потерь.
Все разрешенные html конструкции пропускаются без изменений, и соответственно при редактировании сообщения будут выглядеть также как и при его создании. Преобразование специальных маркеров у меня полностью поддерживается в оба направления, так что никаких проблем с

,

PHP:

 и др. конструкциями нет. При желании, весь html код может быть преобразован в текст, форматированный расширенным набором специальных маркеров.
Считаю, что хранение лишних данных (таких как исходные копии) не оправдано.

[quote]Переводы и шаблоны Вы загружаете перед запуском модуля. Такой подход тоже не лишен минусов - нужно как-то заранее узнавать, что потребуется; точно узнать нельзя - может загрузиться что-нибудь лишнее, а что-нибудь - недогрузиться и тогда его придется подгружать потом.[/QUOTE]
Мне ещё не удалось создать ни одного модуля, который бы не знал  какой набор шаблонов, конфигурационных переменных или переменных интерфейса ему нужен для работы.

[quote]
Поздравляю! Вы объясняете как настоящий преподаватель. Так, чтобы ничего не было понятно. (с) Ю.В.[/QUOTE]
Я объясняю так, как хотел бы, чтобы объясняли мне, не давая оснований заподозрить в излишней ограниченности мышления. © мой

Вы же поняли, значит я сделал всё правильно.

Когда я наткнулся на то, что RewriteCond предоставляет возможность проверки существования реального файла, я сразу подумал, что если когда-либо буду заниматься проблемой кэширования, эта функциональность mod_rewrite будет наиболее достойным для приоритетного изучения.
Сейчас я уже на 90% представляю, как это можно было бы централизовано реализовать в моей системе для модулей отдающих статический контент (изменяемый только при модификации исходных данных). Будет свободное время, займусь этим вопросом.

[quote]
У меня. Я рассматриваю активность пользователя как исходное данное. Чтобы добавить ограничение по активности, в моем случае нужно внести изменение в одном месте - непосредственно перед добавлением сообщения.[/QUOTE]
Активность пользователей я рассматриваю как их право. Если пользователь злоупотребляет своим правом его можно ограничить, как по минимальному интервалу времени, так и по максимальному количеству за сутки.

На сколько я понял, Вы слишком узко представляемее себе процесс установки/обновление универсального модулей. Из-за этого у Вас возникаем много лишних вопросов. Этот процесс может не ограничиваться только лишь копированием файлов, он может вообще выглядеть по другому. Например, это может быть запуск инсталляционного скрипта, или активизация в админцентре процесса установки/обновления модуля. Если допустить, что инсталлятор может проделать некую подготовительную работу, например, преобразовать таблицу в базе данных, добавить новые конфигурационные переменные и др., то все ваши вопросы снимаются и всё становится на свои места.
Перечисленные вами «признаки отсутствия обратной совместимости» не имеют никакого отношения к обратной совместимости.

Popoff · 2 Янв 2006

Преобразование специальных маркеров у меня полностью поддерживается в оба направления, так что никаких проблем

Если честно, я с трудом представляю себе, как в обратную сторону преобразовать подобного вида галерею (внутри все рисунки - это один тег) или автоматическое содержание. Особенно с учетом того, что галерея и содержание зависит от шаблона, а наборов шаблонов может быть много разных и шаблоны могут изменяться дизайнером по идее без уведомления программиста.

Мне ещё не удалось создать ни одного модуля, который бы не знал какой набор шаблонов, конфигурационных переменных или переменных интерфейса ему нужен для работы.

Тем не менее, это огород. ПОка что не вижу никаких преимуществ такого способа перед кешированием.

Перечисленные вами «признаки отсутствия обратной совместимости» не имеют никакого отношения к обратной совместимости.

Это очень хорошо. Это означает, что теперь Вы можете их сформулировать в своем видении

Из-за этого у Вас возникаем много лишних вопросов.

На самом деле у меня нет никаких вопросов. Все свои вопросы я давным-давно решил и радуюсь. Просто иногда у меня закладываются подозрения, что решение подобных вопросов при Вашем подходе - сложнее, чем при моем. Именно поэтому я их и задаю, чтобы иметь возможность сравнить. Не чтобы узнать (как их решить просто, именно просто, а не как-нибудь еще, при моем подходе, я и так знаю), а чтобы сравнить и изменить свой подход, если окажется, что Ваш подход действительно лучше.

У меня тоже бывают инсталяторы. Но инсталяторы - это сложнее, чем простое копирование файлов. Если я могу внести такое изменение, чтобы не пришлось создавать инсталятор, то я считаю, что скрипты имеют обратную совместимость. С учетом возможности введения инсталятора у меня вообще почти любые скрипты имеют обратную совместимость. Вопрос лишь в сложности инсталятора.

Мы спорим, Вы не находите?

Особенность любого спора - в том, что спорщики хотят спорить, а не получить что-то новое. Верный признак спора - повторы и короткие, ничего не значащие ответы на вопросы. Повторы я заметил (я заметил, что я повторяюсь) еще когда заговорил о споре в первый раз, Вы, видимо, тоже заметили повторы. Короткие ответы предназначены для того, чтобы последнее слово осталось за тем, кто ответил (здесь хорошо описано, почему этого можно хотеть и как это помогает в споре). Например, ответ "это не является" представляет из себя короткий ничего не значащий ответ, потому что на самом деле ни меня ни вас не интересует, является ли тот список чем-то или не является. Тем более, что само Ваше утверждение "не является" - весьма спорно, как спорны и сами критерии. Примерно по такой же схеме некоторые, знающие хорошо много разных способов хранения деревьев, пишут, что вложенные множетсва - это хорошо (то есть "является"). Видимо, рекламируют. Мне лично интересно было бы узнать по существу - критерии. Имея эти критерии, можно было бы сравнивать подходы. Нет критериев - нельзя сравнивать. Свое видение критериев я Вам высказал. То, что написали Вы, тоже нельзя считать критериями, я уже написал, почему. Более того - я задал Вам вопросы, ответив на которые Вы могли бы превратить Ваше высказывание в критерии. Вы, давая короткий ответ, либо скрываете от меня эти критерии, либо надеетесь, что я сам о них догадаюсь. С таким же успехом я мог бы надеяться, что Вы сами догадаетесь, что означает, к примеру, "дружественное наследование" в терминах моей системы управления привилегиями при условии отсутствия документации. Догадаться Вы врядли сможете. Ответы типа "Я решаю эту задачу." или "Думать… Вы сомневались?" также дают очень мало чего нового. Без сомнения, Вы будете думать и решать эту задачу. У меня могли быть сомнения насчет чего угодно, но только не насчет этого. Вы сомневались?

Есть еще один признак спора - уход в сторону. Вы все еще помните, с какого вопроса начался наш разговор? Вы думаете о том, как то, о чем мы говорим сейчас, поможет разрешению именно того, первого вопроса?

flash-vkv · 2 Янв 2006

такой вопрос мое ядро подключает 100 мудулей и соберает их за 4 сек это нормально или делать все по другому

Rammstein · 3 Янв 2006

2 flash-vkv
Маньячим по тихому?

Это зачем тебе их сразу в одну дырку? Представь, если одновременно на сайт зайдёт человек 15. При том это не твой локалхост, а вирт. хостинг. Они на долго застрянут.

[offtop]Нашёл хоть одного географического соседа[/offtop]

flash-vkv · 3 Янв 2006

исли взять к примеру что все эти 100 модулей записаны в одном скрипте то выигрыш будет всего в два раза, я не учитываю тот факт что ешё их придется подгонять друг под друга.
Пытаюсь найти уневерсальный способ обьединения модулей, идея в том что взаимодействие между модулем и ядром у всех происходит по одному принцепу. те в идеали бы выгледело бы так сушествует запрос и ответ. запрос простая строчка ответ тоже строчка,
если присоединять простым инклуде встает проблемма что у разных модулей не должно быть обинаковых (имени) переменных(глоб) и классов с одним именем, не совсем это вписывается в идею, это больше похоже на одно большое приложение где все надо продумать.
сейчас делаю при помоши инклуде но не тот который в пхп а в хмл. В пхп обьекте DOM XML есть метод xinclude но я реализовал его в всвоем видиние помимо простова гет запроса еше добовляется пост и SID. стандартный метод xinclude выиграша не дает кроме правельного поддержания стандарта. НО это если использовать HTTP как канал который будет обьединят ядро и модуль и втоже время отделит коды модуля и ядра.

Кто как связывает модули, у всех ли остается не решона проблема "в каждом модуле унекальные имена классов". Я не учитываю спрособ писания скрипта не используя ОПП, в таких сриптах вобшем можно добится этова но только остается учитывать что имена функций должны быть унекальны.

ONK · 3 Янв 2006

flash-vkv, а зачем одновременно подключать сразу 100 модулей?
Модули нужны какраз для того, чтобы их можно было подключать и выполнять по отдельности в зависимости от поступившего вешнего запроса.

Rammstein · 3 Янв 2006

Мне кажется, что идея с XML/SOAP вообще не удачная для связи модулей... по многим причинам, вчастности производительность. Проще всё организовать через классы и не мучаться....

-~{}~ 03.01.06 17:30:

Немного подумал - SOAP/XML хорошее решение в том случае, когда модулями являются две разные системы, например, CMS и система сбора статистики....

Royal Flash · 3 Янв 2006

Текста много, а вот посуществу не очень...

Мой вариант решения многоязычности сайта под CMS:
Все наполнение хранится в базе, например MySQL
Наполнение разделяется на 2 части: информационное наполнение (новости, картинки, опросы и т.д.) и статическое наполнение (например авторизация, текст кнопок войти, логин, пароль)

Информационное наполнение записывается в базу, в свои таблицы, в соответствии с правилами для модуля, который отвечает за вывод его содержимого. Т.е. новости, к примеру, записываются в 5 столбцов: id, дата, тема, новость, автор., а фотогалерея в 4: id, название картинки, подпись, автор.

Статическое наполнение заносится в одну таблицу: id, содержимое. Id нужен для связи с конкретным разделом, а вот в содержимом храним в массиве все содержимое статичесских данных: arr[0], arr[1], ... arr[n]. Для этого форума статика это: URL сообщения | инфо об авторе | жалоба | IP: Записан | редактировать | ОТВЕТИТЬ и ЦИТИРОВАТЬ и т.д.

Данный метод, на мой взгляд, намного экономнее, в плане расхода ресурсов, чем предложенный Popoff, так как использует всего 1 sql запрос к базе, вместо неограниченного их кол-ва.

Popoff · 4 Янв 2006

Royal Flash
изначальный вопрос, вообще-то был в том, что лучше - универсальные модули или специализированные. все остальные вопросы - это вокруг этого.

ONK
Ты меня убедил. Заранее подгружать сообщения - это выгодно. Теперь у меня два огорода: один - в начале, второй - в конце

Royal Flash · 4 Янв 2006

Popoff
Не в том, вот только как тебе мое решение, что скажеш?

Кто писал свою CMS - есть вопрос

Новичок

Хитрожопый макак

Пассивист PHPСluba

Новичок

popoff.donetsk.ua

Новичок

popoff.donetsk.ua

Пассивист PHPСluba

Новичок

popoff.donetsk.ua

Пассивист PHPСluba

popoff.donetsk.ua

Новичок

PHPClub::News

Новичок

Пассивист PHPСluba

PHPClub::News

-=MaestrO=-

popoff.donetsk.ua

-=MaestrO=-