На этот раз для опытов был выбран один из распрастранённых и вполне вменяемых и рабочих клонов php-nuke slaed. Очень хотелось посмотреть чего у него там внутри.
В процессе исследования и оптимизации организма системы удалялись встреченные на пути табличные теги, застарелые оформительские теги типа FONT, вросшая в тело скрипта тяжелая графика... и другоеподобное в целях общего отделения ценности данных от их художественного оформления.
При обледовании выяснилась целесообразность системной модернизации построения отдельных модулей.
Процесс модернизации непрерывен и продолжается постоянно. Модернизируемый код снабжается обильными комментариями по поводу иссследуемых деталей и органов, так что можно следить за версиями нового портала.
Тестовая демонстрационная версия портала "Бесплатная юридическая консультация", там можно скачать обновлённые версии или на портале творческого исследования PHP-Nuke
Пятничная клоническая версия "Пятница-13". (Средняя механизация PHP-Nuke) newcontinent.ru 2006-01-13 Beta Else2
легко скачать
Средняя механизация PHP-Nuke
Краткое демагогическое вступление (торопливым можно пропустить): Основной девиз всех действий - упрощение и упрощение. Всяческих человеческих и программных сложностей. Второй принцип кодо-динамики - "Программы пишутся для людей!"
В том смысле, что, конечно очень даже хорошо, если код традиционно ориентирован и оптимизован для исполнения машиной, но основное то его потребительское качество - это легкость его прочтения и усвоения читателем, впрочем как и любого другого читаемого текста. И не просто читателем, а читателем, возможно до того не знакомого ни с идеями заложенными в коде, ни даже с самим способом их закладки в конечное блюдо. В каком то смысле любой осмысленный текст - это код, побуждающий окружающий мир к действию. И в этом смысле программный код мало чем отличается от литературного текста. Вообще весьма светлая и перспективная идея - совместить два процесса в одном - чтение скрипта (может быть даже первое ) и одновременное постижение примитивов скриптового программирования. Изучают же основы Basica в школе, ну типа как легко усвояимые и запоминаемые на всю жизнь алгеброические формулы разложения и преобразования условных сущностей этого мира. В этом смысле гигант програмной (в большей степени маркетинговой) мысли Микрософт унифицировал конструкции разнообразных программных языков. Ну в самом деле, давно пора было привести конструкции к единому общепринятому, общепонятному стандарту. А уж выбранный компилятор скомпилит гениальную програмиссткую мысль в нечто понятное, опять же избранной, операционной системе.
1. Потрава табличных тегов и польза от Великого наследия.
Picasso
Собственно оптимизация для этого случая свелась к традиционному травлению, по возможности, разнообразной табличной вёрстки, тормозящей активные мозговые процессы дизайнеров и кодёров. Помимо явной неоправданности повсеместного использования таблиц к месту и не к месту, полное удаление или замена на благородные теги "< DIV >" улучшает сканирование содержания сайта поисковиками. Некоторые, говорят, что в последнеее время те, так вообще отказываются вчитываться в нагромождение табличных тегов и просто игнорируют огромные массивы ценного интеллектуального содержания нерадивых сайтов. И вот ещё одна дизайнерская новость в подачи содержания - почему бы не предъявлять данные в виде свободных кубиков (квадратиков).
Для экперимента модуль файлы выводится кубиками. Вот для примера выведены Мировые новости. Блоки определены со стилем "display: inline" и свободно вываливаются в линеечку. На мой, невоспитанный дизайнерскими изысками взгляд, так совершенно без разницы в одну-две-три или боле колонок выведутся однотипные кубики новостей. По этому же принципу построены галереи замечательных художников
мыслитель Пабло Пикассо, великий и откровенный живописец Ваг Гог, пародоксальный Амедео Модельяни, невероятный Михаил Врубель, искренний Валентин Серов и др. Великие и Великолепные. Кстати отличные учителя истинного дизайна мысли и вообще. И отличный источник аватар, взамен полутворческому похрюкиванию профессиональных рисовальщиков аватар. Конечно, "Девочка с персиками" , "портрет клетчатого",
Амедео Модельяни
"изыски Модельяни" не позволят писать глупости, под такими аватарами будет просто неприлично тупить и писать форумскую чушь и вообще идиотничать. Так что и здесь воспитательная роль настоящего искусства просто необходима, особенно в экстремальных условиях теперяшних интернет форумов.
2. Всеобщая солидарность.
Особенно мучительно угнетение мозга и рук оптимизатора внутри типичного модуля PHP-Nuke. Отыскав нужное место где спрятался заветный цикл вывода содержимого модуля простак оптимизатор быстренько заменит по своему вкусу вид выводимого и уже довольно потрёт наруженные ручки, ноо только скорее всего скорого на руку оптимизатора постигнет разочарование и никакого эффекта от внесенных измененией оптимизатор скорее всего не увидит - вот так вот сразу. А покопавшись в дебрях модуля незадачливый оптимизатор с удивлением обнаружит существования целой кучи функций содержащих одни и те же циклы вывода данных. И только методично прошерстив их все, можно быть уверенными, что подходящее оформленьице выводимых данных теперь будет при любом вызове.
Что бы избежать мучительно ремонта агрегатного модуля, можно прибегнуть к заведению одной основной функции вывода данных, например "view", совмещающей в себе анализ поступающих аргументов (эту идею следует развивать, так она, ко всему прочему, избавит от кучи ненужных параметров в адресах, кстати эта методика давно и упорно пропагандировалась Microsoft в том же учебном Basic(е)) .
На основе анализа поступающих аргументов-данных, внутри такой функции формируется один универсальный и единственный запрос на отбор данных из таблицы с учётом задаваемых параметров. То есть если, например передан аргумент "seach" в виде набора поисковых фраз, то из него будет сформировано условие where, а если он не передан, то и не будет никакого условия для поискового отбора. С этой точки зрения условия отбора, например, по категории (или категориям) это всего лишь одно из условия отбора, каковое можно производить по всем полям таблицы. Вот это уже почти концепция простого выбора и представления данных, через одну функцию вместо отдельных функций на каждую команду, где циклы вывода данных в HTML многократно повторяются. Может это и экономично для машины, но путанно для человека-sapience модернизирующего. Поэтому - "всё через одни ворота", и с предварительным разбором передаваемых данных.
Вот это я постаралась сделать в модуле "links", там внутри полно соображений и идей по ходу дела, смотрите внутри.
Например забавное вынесение голосования за сущность непосредственно в основной список и запуск команды голосования посредством js, на событие изменения ("onchange"), без дополнительной специальной кнопочки с громождением формы.
Вот еще забавная идея - встраивать короткие url(ы) сразу и непосредственно в код. Этим конечно увеличивается зависимость от наличия файла .htaccess, но это всего лишь ещё один необходимый файл, такой же как илюбой другой файл с вынесенными функциями, например, а нормальный хостер всегда предоставляет возможность использование своего .htaccess. Зато здесь же, неожиданно достигается и некоторая независимость модуля от разнообразия версий нюк типа index у них всегда впереди или module, или ещё какой другой файлик впереди вызывается. Это дело вкуса, конечно.
Модуль вполне рабочий, хотя и находится в стадии дальнейшей принципиальной оптимизации, точнее теперь сказать разработке.
3. Долой шаблонность решений ! И классовая независимость.
После долгих и мучительных размышлений неожиданно подрос вывод о неразумности использования внешних функций, обычно размещаемых в файле шаблона для окончательного и бесповоротного вывода данных. Это конечно жутко непринципиально в плане жесткого разделения данных от их вида. Но это всего лишь скрипт, а не фундаментальный продукт со строгой концепцией яйцеголовых теоретиков "данные-вид". И шаблон и модуль - это тот же PHP, так, что дизайнеру все равно придётся познать скриптовый язык. Так лучше сразу в модуле и определять, тем самым кстати порождая ещё одну очень перспективную концепцию - "естественного сремление всякого модуля к полной независимости и личной свободе"! И даже по возможности к классовой независимости!. То бишь будет у него некий интерфейсик, может даже стандартизироованный, а может и не один. (Еще ни разу не получалось просто так выработать один единственный стандарт хоть в чём-нибудь сразу и для всех.) И вот в этот интерфейсик и надо будет подать всё необходимое от ядра или ещё откуда, а может и просто инициализируя ручками. Ну это всё теория и на будущее. А в будущем этих скриптиков вообще может статься не оказаться
. А будет один чей-нибудь продукт наподобие Office ну или даже StarOffice Так что проще товарищи, проще! Это всего лишь скриптики.
В свете этих соображений внешний вид сформированных данных концептуально формировать только при помощи CSS или для пущих возможностей XML-XSL(если выживет) И тогда смена темы сведется к тривиальной подмене файла с определением стилей CSS никаких заморочек со сложнейшими построениями каталожных структур с файлами темы. Надо отметить что идеи эти вовсе не новы и давненько применяются умными разаботчиками например в punbb впрочем у них у продвинутых, тоже не мало своих заморочек
. Но CSS - это есть наш последний и решительный ответ европейскому мракобесию PHP-Nuke и её жалких местных клонических приспешников.
4.Перерождение.
Вся эта мелкая оптимизация неизбежно приведёт к большему концептуальному перерождению системы, возможно напрочь отрицающего предшественников. Эта работа проводится непррерывно и отражается в очередных версиях размещаемых на тестовом портале "Бесплатная юридическая консультация" и на портале творческого исследования PHP-Nuke
Одна из перерожденческих идей - это выделение стандартного набора функций для обеспечения нормального безбедного существования стандартного модуля системы, на основе которого можно было бы легко и быстро, а главное безошибочно создавать необходимое колличество специализированных модулей. В самом деле, если присмотреться, то невелико различие между функциональностью модуля каталога ссылок и функциональностью новостей или контента. Разница только в литературном обозначении в общем-то однотипных полей. В одном случае беспокойный мозг изобретательного проектировщика обзывает поле hometext и еще одно уже для полного содержания совсем уже поти неприлично "bodytext". В тоже время, точнее несколько раньше, вовсе не последние умы человечества неоднократно разрабатывали (и не раз) всяческие универсальные структуры данных. Свою живучесть демонстрирует стандарт тегов метаданных в HTML. Так чего же в который раз изобретать один и тот же велосипед!? Description! и никаких hometext-ов! И хорошо бы вставить в стандартный набор полей "Key"! - Очень необходимое поле для любого порядочного модуля описывающего любую сущность, будь то link или единца контента. Вот сленговые чудеса обозначения простых вещей - статья, новость, страница книги, описание ресурса в каталоге (краткое - description и полное - просто text). Кстати в каталоге - всё равно в каком - ссылок, фильмов, аудио-дисков, анекдотов, ... или даже особых таких специальных крышычек для особых таких специальных футлярчиков с прибамбасиками и т.п. ! И для всех пригодится поле author и mail, и date, и note... И также никто не сможет поспорить, что всем сущностям пригодится label маленькая такая картиночка ну и побольше image и т.д. В этой пятничной 13 версии 2006 года, для экперимента, модуль "pages" был получен путями простого копирования скриптов модуля "links" и для пробы, основная контенто-выводящая функция сама была выведена в библиотекку "function/function". Хотя впринципе, вывести эту нахалку можно в любой другой файл подключаемый на ранней стадии. И туда же можно отвести всю компанию её приятелей, необходимых для нормальной работы модуля функций: save, add, vote. Обобществив стандартный набор функций для общих коллективных нужд всех модулей и сформировав таким образом обще-колхозный интерфейс, как у всех более менее порядочных портальных систем.
В стандартные функции-методы придется передавать дополнительный параметр - имя таблицы с которой связан модуль или же использовать жесткую зависимость: например имя модуля = имя таблицы. Что бы избежать опасной передачи имени таблицы - лучше использовать внутренний case, его вариант предложен в новенькой коллективной функции "v()".
Конечно есть модули, в которых просто необходим чрезвычайно богатый набор специфических полей. Например в моделе службы знакомств каких только половых полей не понатыкали, чтоб уж точно определить искомого партнёра. Несмотря на всю утопичность подобного рода подходов к знакомствам - проблема полевого богатства остаётся. И одно из её решений - это передача массива с подробными параметрами полей и затем обработка такого массива в цикле, наподобие как это сделано в MSAccess в конструкторе форм, достаточно заглянуть в файл описания формы в basic проекте - цельный метаязык описания формы. В PHP вполне можно обойтись штатными средствами и получить мечту малопрофессионального разработчика приложений - access для MySQL. Эта методика уже некоторе время отрабатывается и будет предметом следующей клонической оптимизации и статьи, и версии какого-нибудь завалящего клона PHP-Nuke.
Дополнительные материалы:
Инструкция по установке оптимизованной клонической версии:
1.Распаковать архив и залить (закачать) содержимое папки portal к себе на сайт. Для простоты можно прямо в корневую папку сайта "www" или "public_html", а можно в какую-нибудь папку с красивым названием внутри корневой.
2. Отредактировать файл config/config.php
$dbhost = "localhost"; //
$dbuname = "login"; // Ваш логин к базе данных
$dbpass = "pass"; // пароль к базе даных (обычно логин и пароль высылает вам ваш провайдер)
$dbname = "db name"; // наименование Вашей базы данных
$admin_file = "admin"; //
$adminlogin = "admin"; // первичный вход в систему просто задайте любой ваш логин
$adminpassword = "admin"; // просто задайте любой ваш пароль
$prefix = "org"; // префикс к таблицам базы данных. По умолчанию org.
// Если Вы установите другой то нужно будет отредактировать SQL файл newcontinent.sql
// и заменить там префикс.
// Для редактирования можно использовать простые реакторы типа notepad, editplus.com ...
"Залейте" файл newcontinent.sql на в Вашу базу данных. Обычно это делается через phpMyAdmin которая есть у любого нормального хостера. Там нужно будет открыть Вашу базу и выбрать команду SQL в верхнем меню и указать SQL файл на вашем локальном компьютере с sql-инструкциями. В нашем случае это файл newcontinent.sql.
После выполнения вышепредложенных действия портал должен заработать. Это нехитрый механизм усатновки практически любой нюки. Всяческие инсталяторы практически делают всё это же самое, только в интерактивно-ламерском режиме
Но настоящий то проффи никогда не сподобиться пользоваться кривыми или же даже прямыми инсталяторами, а выполнит всё в точности как написано да ещё и с глубоким пониманием производимых процессов, и никак иначе. Иначе, извиняюсь но ...
Но, что бы контролировать Nuke в качестве администратора, нужно срочно выполнить важнейшее действие И те кто до сюда не дочитал - те сами виноваты! Нужно мгновенно вызвать файл admin.php! То есть [путь_к_вашему_портала]/admin.php . Ну грубо, вызвать в командной строке файл admin.php, который лежит в корне (основной папке) портала. И при первом вызове Вы сможете завести заветную запись главного администратора! Задать для наиглавнейшего администратора подходящий умный секретный логин и хитрый пароль (и их надо придумать заранее). В дальнейшем их конечно можно переправить и главный админ может завести ещё кучу дополнительных админов для своего сайта. Сами понимаете, что если вы сразу не заведёте такого главного админа, то его с удовольствием заведёт кто-нибудь другой, при случае и этот кто-нибудь другой сможет полностью распоряжать своим сайтом как администратор.
--------------------------------------------------------------------------------
Первая антитабличная оптимизация PHP-Nuke 7.9 от newcontinent.ru можно легко скачать
версия "Пятница-13". (Средняя механизация PHP-Nuke) newcontinent.ru 2006-01-13 можно легко скачать
