функции обратного вызова задаваемой конфигурационной переменной
Нет у меня функций обратного вызова. Они запутывают программу, потом в ней не разобраться. Такие функции могут быть скорее как очень сильно редкое исключение из правил, но не правило.
А если в модуле этого нет, то назвать его универсальным нельзя. Скорее это заготовка для создания специализированных модулей.
Да, я уже где-то в этом топике писал о том, что у нас, видимо, проблема с терминологией. Под словом "универсальный" я понимаю "легко расширяемый". При чем под словом "расширяемость" я понимаю не изменение какой-то одной специфической функциональности, а добавление новой функциональности. Не просто при помощи функции обратного вызова в одном проекте что-то считать одним способом, а в другом - другим, а в обоих проектах доступны оба способа.
При этом новая версия, добавляя новую функциональность, и исправляю выявленные ошибки, не приводит к какой либо потере работоспособности и сохраняет все настройки старой версии, т.е. имеет полную обратную совместимость.
То есть: у них - старая версия скрипта (скрипт не содержит в себе никаких настроек, только функции/классы), у нас - новая версия скрипта, они берут у нас новую версию скрипта, копируют поверх старой и у них все работает как и раньше, но добавлена новая функциональность и удалены глюки. Это?
Мне непонятно зачем настолько её усложнять.
Я не специально - оно сомо так получается %) Сначала у меня не было никакой иерархии привилегий, ролей, админов и т.п. Это все клиенты захотели: "так, чтобы в одном списке поменял, а в других само поменялось". В целом, у меня, мне кажется, вполне логичные и естественные решения. Собственно, сама идея c ролями даже не мной придумана - ссылка на оригинал внизу моего описания. Я всего лишь конкретизировал, расписал все подробнее и выполнил конкретную реализацию.
Сообщения я храню в том виде, в котором собираюсь показывать.
А отредактировать я не могу? А вдруг с ошибкой ввел?
По поводу кэширования, я считаю, что если приличный однопроцессорный сервер без средств кэширования ПХП опкода может сгенерировать 25 страниц в секунду, то нет причин для того, чтобы задумываться о кэшировании.
В целом, я, без сомнения, согласен. Если я задумываюсь над кешированием, то это исключительно только потому, что кеширование не представляет собой совершенно никакой сложности для меня - добавить в нужных местах пару вызовов функций, больше ничего не меняется. Если бы была хотя бы малейшая сложность, я бы забил на кеширование.
Просто в таком случае мне не понятно другое:
Автор оригинала: ONK
Делать эти процедуры в момент показа сообщения не разумно как с точки зрения расходования ресурсов сервера, так и с точки зрения отсутствия необходимости постоянно делать ту работу, которую можно сделать один раз.
Кеширование как раз и имеет своей целью избавить сервер от необходимости постоянно делать ту работу, которую можно сделать один раз. Почему в случае с сообщениями в Вашем случае Вы считаете, что расходование ресурсов сервера не разумно, а в случае с кешированием вообще - предлагаете купить новый сервер? Вы не считаете, что то, что происходит у Вас - это и есть кеширование? Вы не считаете, что кешировать Вашим способом не выгодно, потому что автоматически теряется функциональность?
Я не против того, что если функциональность не требуется, то можно сделать и так. Но при Вашем подходе система не является расширяемой. Любая новая фича - и действительно окажется, что минимум половину кода проще переписать с нуля. Но этот код не будет нужно переписывать с нуля, если его изначально просто написать по-другому. Это "по-другому" не требует каких-то особых затрат времени и энергии. О TDD можно говорить, что там требуются дополнительные затраты времени на создание тестов, но даже там ясно, что эти затраты потом с лихвой окупаются. В моем же случае даже этих начальных затрат нет.
Вы храните только в таком виде как будете показывать и не храните исходный вариант сообщения. Я Вас правильно понял?
Надо ещё больше, купи многопроцессорный сервер, оно явно того стоит. Кэширование динамического контента сейчас не актуально.
Даже очень дешевый компьютер стоит в бесконечность раз больше бесплатного скрипта для кеширования. Если бы кеширование вносило хоть какую-нибудь сложность, я бы понял такие растраты. Но кеширование не вносит никаких сложностей. Чем оправдана покупка нового сервера?
Кэширование динамического контента сейчас не актуально.
Это смотря что кешировать. Если делать как Вы - хранить вариант для показа, не называть этот вариант словом "кеш" и не делать систему гибкой, то да, не актуально.
=========================
Резюме.
Мы с Вами обсуждаем две разные технологии разработки программного обеспечения.
Особенность одной из них, о которой говорю я, состоит в том, что при ее применении получаются гибкие программные продукты с мощной функциональностью. Эта функциональность, однако, не всегда требуется потребителю и может затруднить сопровождение только своим присутствием. Применение этой технологии ведет к необходимости введения всевозможных надстроек в виде моих параметров, сложной системы управления привилегиями, универсальной системы кеширования и прочих фич, которые в сумме образуют ядро системы. Это ядро имеет весьма сложную организацию.
Особенность той технологии, о которой говорите Вы, состоит в том, что ее применение не требует разработки сложного ядра. Ядро системы, разработанной при помощи такой технологии, содержит в себе минимальный набор самых необходимых классов (или функций). Отсутствие сложного ядра упрощает применение этой технологии. Модули, разработанные с использованием этой технологии, выполняют ту и только ту функциональность, которая была оговорена с клиентом. Отсутствие лишней функциональности может упростить сопровождение. К недостаткам можно отнести то, что программные модули, разработанные с использованием этой технологии сложнее расширять, для добавления новых возможностей может потребоваться переписывать некоторую фунциональность с нуля, в системах, разработанных по этой технологии снижается уровень повторного использования существующего кода.
Возможно, я перечислил не все плюсы и минусы этих двух технологий.
Обе технологии обладают своими достоинствами и недостатками.
Некоторые из этих достоинтсв и недостатков невозможно или очень сложно сравнить между собой. Хотя я и записал вполне конкретные достоинтсва и недостатки, следует понимать, что их классификация весьма гипотетична и основана на нашем опыте и наших умозаключениях, а не на математическом расчете.
Я предлагаю заканчивать наш разговор, потому что сейчас мы с Вами, кажется, занимаемся банальным спором о том, чья технология лучше. Вы будете отстаивать свою технологию не только потому, что у нее есть объективные плюсы, но и потому, что Вы ее уже используете и для Вас переход на новую технологию связан с известными неудобствами. Это же касается и меня. Изменение используемой технологии на любую другую может быть вызвано только объективными причинами, например, слишком большие затраты на разработку и сопровождение. Ваш опыт говорит Вам о том, что применение той технологии, которую используете Вы, не приводит к большим затратам на разработку и сопровождение проектов. Мой опыт говорит мне о той технологии, которую применяю я, то же самое.
Для того, чтобы продолжить продуктивный разговор, следует написать достаточно полную документацию по используемым нами технологиями начиная от общей организации системы и вплоть до правил составления программных имен. Особое внимание, вероятно, следует уделить вопросу плюсов и минусов наших технологий. Некоторые из них мы уже рассмотрели в этом топике.
Пока такой документации нет, мы видим лишь обрывки особенностей наших подходов. Мой подход может показаться Вам не достаточно продуманным или плохо справляющимся со своей задачей всего лишь потому, что Вы не знаете всех особенностей моего подхода. Точно так же и я могу чего-то не понимать из особенностей Вашего подхода.
Пока такой документации нет, мы можем говорить лишь о том, с каких точек зрения и как сравнивать, но не о том, какая сторона лучше и насколько.
===(добавлено)===
исправил дурацкие опечатки %)
