Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1] 2  Все   Вниз
  Печать  
Автор Тема: Дальнейшее развитие vu-engine  (Прочитано 103870 раз)
0 Пользователей и 1 Гость смотрят эту тему.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« : 27-02-2006 01:25 » 

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

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

Были промежуточные этапы:
https://forum.shelek.ru/index.php/topic,8252.0.html
https://forum.shelek.ru/index.php/topic,8260.0.html

Растянулось это почти на год. Если честно, то после 2.2.2 я пол года ничего не писал - некогда было, да и не хотелось. Причина, по которой я не выпустил 2.2.2 еще в мае 2005-го - та же, почему сейчас перестал модифицировать копию SMF на нашем форуме: вижу, что мои труды могут легко быть потерты, а то и повредить работе форума при его модификации посредством установки модулей или апгрейда (в SMF используется метод типа diff). Да и совместная работа у нас так и не ладится: об каком-либо изменении узнаем лишь через некоторое время (это об администраторах).

Так вовращаясь к темам по вышеприведенным ссылкам. Было у меня не мало идей по модификации движка vu. Со временем перебродило, что-то стало янее видно, немного прибавилось знаний и опыта. В 2.2.2 я трудился над давно тогда висевшей проблемой удобства и сервиса работы со статьями (с апреля ниодной). Написал и в меру сил обкатал возможности по интерактивному форматированию прямо на странице. Сейчас я считаю, что труд, конечно, не напрасный, но код надо переписать ("всего" порядка 350 строк компактного кода). Ну и не мало потрудился над сизифовом трудом "окультуривания" существующего кода. Гром, извини, но редактор, которым ты пользовался - убогий. И html-код в строках echo не раберешь. И ошибки copy-paste кругом. Благо, браузеры поглатываю и такое.
Правда и у меня редактор не шибко (mcedit), за то стабильный в пране результата. И это радует.
После тем, начатых d34!h и BobiKK, я (в очередной раз) осознал неудобство расширения и правки движка. До этого я считал, что им почти никто и не пользуется, но, недавно, прошелся по поисковикам и посмотрел, что пишут и как ссылаются на наш сайт (club, forum, faq, и пр.). faq - ссылок мало, но кое где народ равняется Улыбаюсь . forum - на удивление мало ссылок. Возможно движок поисковиков не любит. На club - большинство ссылок: примерно 80% - файло, 20% - статьи. Самые популярные - переводы Alf-а. Движек то же упоминается. Нашел да же способ взлома.
В 2.2.3 я сделал попытку изменения гибкости - разделение сушествуюшего, почти монолитного кода на молее мелкие функциональные сотавляющие. Попытка, в общем то, удалась, но когда я дошел до изменения административной части и потратил на правку всего 10-ти файлов (почти 50к кода - в 2.2.2 я умудрилcя перелапатить почти весь код) три дня и понял, что это - типичный сизифов труд (эту верию я не выкладывал). Каждый раз, когда я приступал к правке, я старался вносить не слишком много изменений, чтоб не нарушить работоспосбность. Вот основне недостатки, которые я нашел в коде:
- передача запроса через глобальные переменные;
- разнообразие этих переменных и не всегда оправданное (осмысленное) имя;
- куча переменных внутри класса site - большинство просто дублируются и пересекаются по смыслу;
- ненужное наследование db -> site - проше создать глобальный объект $db - благо, php - не многопоточноя среда программирования;
- использование кода html, несовместимое со стандартами (но браузеры, к сожалению, его понимают) - я сейчас сторонник движения в сторону xhtml+css: ужесточение правил и стандартизация (стремление кода к стандартам + стремление браузов к стандартам даст большую предсказуемсть результата);
- плохая безопастность кода (при обилии файлов скриптов, каждый со своей логикой и поведением, трудно всех их обезапасить);
- основы, заложенные применением классов, в них же и завязли;
- код, описывающий логику, должен быть компактнее и не пересекаться с html-кодом (ф-ии то можно и в сторону отнести);
- базу надо переделывать - первоначальные идеи, вложенные в нее, не соответствуют текущей действительности применения;
- ...
Короче, мне многое хочется поменять, чтобы, при внесении небольших изменений, не надо было перелапачивать весь код опять. Хочется большей гибкости. Я понимаю, что пока не появились ограничения, вводимые идеологией разработки, можно экспериментировать. Что я и хочу предложить...

Код пока не выкладываю - жду первых отзывов.
Написал пока всего порядка 2т строк. Отлажено менее половины.
Пью пиво, экономлю силы, жду отзывов.
« Последнее редактирование: 27-02-2006 01:31 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
d34!h
Гость
« Ответ #1 : 27-02-2006 02:52 » 

Хотелось бы чтоб в новой версии изменили download , мне что-то неочень нравится . В самой первой странице , где у меня главные категории хотелось бы чтоб они были расположены слева где новости , а справа к примеру чтоб открывалась первая категория и в ней были уже то что я представляю для загрузки и  слева обьяснния к ней, имхо что последняя версия в этом неудобна хотябы если много к примеру тогоже софта который я выкладываю
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #2 : 28-02-2006 16:53 » new

d34!h, дизайн определяется шаблонами. Измени их и изменится дизайн.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #3 : 28-02-2006 17:18 » 

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

1. Идея движка родилась как следствие мучений с phpNuke почти три с половиной года назад. Идея заключалась в следующем.
а) модульность движка не должна влиять на его кернел, т.е. ядро. В нюках и других известных бесплатных движках такого рода связки портили все дело.
б) дизайн не должен пересекаться с кодом Улыбаюсь то, чего в 100% добиться не удалось, но удалось стандартизировать все возможные на тот момент требования к внешнему виду.
в) работа должна происходить оптимально быстро, т.е. запросов на каждую страницу должно быть ровно столько, сколько запрошено элементов из базы - не больше. В других очень много лишнего было - куча статистики неотключаемой и т.д.
г) отсутствие необходимости напильника, т.е. все необходимое - это HTML. Во всех других халявных скриптах я видел необходимость некоторой поправки кода находящегося в шаблонах...


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

Учитывая тот факт, что этот скрипт вообще мой первый и пока последний срипт на php, надеюсь огрехи мне простят.
Редактор которым я пользуюсь - нотпад и студия 6 от мелкомягких, никаких редакторов кода я не использовал.

Далее.
То, что я бы хотел увидеть.
1. Освобождения от моего наследия C++ в коде, которое я не смог преодолеть из-за не знания работы в скриптах, так как кроме того, что скрипт - первый на пхп, он еще и первый скрипт для веба у меня тоже Улыбаюсь
2. Сохранение главного принципа, расширение скрипта не влияет на старые модули. Т.е. работа модуля должна  быть не связана ни с чем, кроме него самого и настроек БД. Именно для этого делалось наследование - но оно себя не оправдало Жаль
3. Включение админки в тело скрипта. Идея такая, пусть каждый модуль разельно формирует свои страницы своего администрирования. Таким образом админка должна только обеспечить их безопасность и вызов по стандарту. Тогда написание нового модуля будет включать в себя написание самого модуля, стандартной админки + инсталлятор, который даст возможность изменить БД под этот модуль с помощью добавления таблиц необходимых для его работы.
4. Создать структуру вызова страниц. Вот тут дилема, либо сделать как в форумах, что бы стандартная страница типа index.php в зависимости от параметров вызывала нужное действие, либо сохранить модульные индексы по дифалтным названиям как сейчас на сайте. Но тогда необходимо, что бы вызов каждого моджуля как и сегодня формировался только шаблоном.
Плюс второго подхода очевиден, нет необходимости сложного администрирования блоков, как в Нюках, и нет необходимости загрузки типов (actions) и их хранения для списка активных модулей.
Минус тоже очевиден. Каждый раз в ручную переделывать страницы дизайна. Для постоянно расширяющихся и меняющих структуру, проектов - очень неудобно.


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




 
Записан

А птичку нашу прошу не обижать!!!
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4 : 28-02-2006 21:48 » 

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


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

С целью безопасности, я делаю следующие утверждения:
1) Все запросы должны проходить через один интерфейс (типично - index.php), который выполняет всю работу по последовательной загрузке частей ядра, подготовки данных запроса и предварительного контроля доступа.
2) Все части программы, кроме index.php, - то же php программы, но без кода, который можно было бы вызвать в обход: классы, ф-ии, определения переменных (без вычисления выражений, использующих внешние по отношению к системе данные, непрошедшие проверку) и ... оператор return (php-файл, вызванный через include может возвращать значение). Шаблоны - то же php. Ведь чистый html-файл == php, без программных выражений. Кстати, очень важно, чтобы файлы только php-кодом не содержали никаких символов до и после <?php ?> - это расценивается как вывод и повредит возможности работы с http-заголовками.
3) Хуже дело обстоит с бинарными данными, их все равно надо отдать пользователю. В крайнем случае, можно через скрипт отдавать.
4) Использование register_globals недопустимо.


Вторая идея, которую я хочу внедрить и которую тоже надо обсудить до значительно увеличения кода: хранение и интефейс к конфигурации ядра. Я имею в виду данные, вводимые один раз (вручную или (полу) автоматически), которые хранить в базе я считаю излишеством.
Я храню их в php-файлах с return, а после загрузки - во внутреннем массиве объекта с глобальным именем. У объекта есть простой интерфейс, а для простоты получения данных я сделал пару ф-ий (как макросы в С).
На мой взгляд, да же пути к файлам должны быть изменяемые без вгрызания в код.


Давай рассмотрим по кусочкам.
Кодовые вставки сделал как [pre] - как оказалось, в SMF в [code] допускаются только ascii, остальное - корежит.

Вот текущий варант начала index.php (потом многое может измениться):

<?php

// Базовые настройки: путь к config.php и директории с конфигами.
// Остальные настройки находятся в _g('path.config')/*.php
require_once('engine/config.php');
$config = new config();
$config->proc_dir('configs/');

// Сокращения для удобства - можно использовать в любой части кода
function _g($key)
{
    return $GLOBALS['config']->get($key);
}

function _yes($key)
{
    return $GLOBALS['config']->check_yes($key);
}

// Блокировка всего движка для проведения ремонта
if ( _yes('engine.disabled'))
    die ('INFO: engine disabled')

// Загрузка db.php
require_once( _g('path.engine') . 'db.php');
$db = new db();
if ($db->err)
    die ('FATAL: db error: ' . $db->err . '(' . __FILE__ . ':' . __LINE__ . ')');

// .....
?>

В первых строках я задаю единственные два путя, которые надо определить в самом коде.
'engine.disable' и 'path.engine' - на мой взгляд, достаточно осмысленный способ задания имени информации.

Пример главного конфига:

<?php
{ // использование блока { } позволяет пользоваться локальными переменными

    $url_proto = 'http://';
    $url_host = '192.168.200.2';
    $url_path = '/vu3/';
    $document_root = '/var/www/html/';

    $site_url = $url_proto . $url_host . $url_path;

    return "

path.root       = {$document_root}{$url_path}
path.engine     = {$document_root}{$url_path}engine/
path.config     = {$document_root}{$url_path}config/

version         = 3.0.0-alpha-1
encoding        = koi8-r

url.root        = {$url_path}
url.site        = {$site_url}
url.js          = {$site_url}js/

";
}
?>


Прилогаю readme для config.php и db.php.

* config.txt (2.8 Кб - загружено 1317 раз.)
* db.txt (2.24 Кб - загружено 1251 раз.)
« Последнее редактирование: 20-12-2007 15:15 от Алексей1153++ » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 28-02-2006 22:05 » 

Прилогаю код config и db.
Т.к. пишу я с koi8-r, то, чтоб не перекодировать, я скопировал с терминала и по этому нет ни одной табуляции - все пробелами.

* config.php (3.83 Кб - загружено 1264 раз.)
* db.php (4.93 Кб - загружено 1266 раз.)
« Последнее редактирование: 28-02-2006 22:18 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #6 : 28-02-2006 22:16 » 

Вот это пример из 2.2.3: первая проба по разделению class.php.

* site.php (2.49 Кб - загружено 1252 раз.)
* news.php (0.87 Кб - загружено 1264 раз.)
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #7 : 01-03-2006 09:14 » 

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

И еще - как быть с поиском, который у нас отстутствует пока.
Записан

А птичку нашу прошу не обижать!!!
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #8 : 01-03-2006 09:15 » 

Идея с выделением блоков в классы мне нравится...
Записан

А птичку нашу прошу не обижать!!!
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #9 : 01-03-2006 09:27 » 

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

Поиск - реализуем. Думаю, надо попробовать поэкспериментировать с FULLTEXT индексом MySQL.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #10 : 01-03-2006 10:28 » 

Ок - итак - буду ждать дальнейших распоряжений.
Кстати - желательно поиметь Улыбаюсь и документик на русском с основными принципами реализации....
Записан

А птичку нашу прошу не обижать!!!
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #11 : 01-03-2006 12:49 » 

Реализации редиректа, или третей версии?
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #12 : 01-03-2006 14:08 » 

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

А птичку нашу прошу не обижать!!!
PooH
Глобальный модератор

ru
Offline Offline
Пол: Мужской
... и можно без хлеба!


« Ответ #13 : 01-03-2006 17:24 » 

а если все HTML вставки вынести в файлы-шаблоны ну то есть, что-бы можно было написать, например:
Код:
<table>
<tr><td>НОВОСТИ</td></tr>
[foreach]
<tr><td>$NEWS_DATE$<br>$NEWS_TEXT$</td></tr>
[/foreach]
</table>
и, соответственно, разбирать его и подставлять данные.
или, например, вывод таблицы
Код:
<table>
<tr><td>$COL_CAPTION[1]$</td><td>$COL_CAPTION[2]$</td></tr>
[foreach]
<tr><td>$COL[1]$</td><td>$COL[2]$</td></tr>
[/foreach]
</table>

или переменными
Код:
news_header="<table><tr><td>НОВОСТИ</td></tr>"
news_row="<tr><td>$NEWS_DATE$<br>$NEWS_TEXT$</td></tr>"
news_footer="</table>"
« Последнее редактирование: 01-03-2006 17:30 от PooH » Записан

Удачного всем кодинга! -=x[PooH]x=-
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #14 : 01-03-2006 17:29 » 

Я предпологаю, что как отображение, так и административные ф-ии включать в один модуль. Т.е., к примеру, модуль news: тут поддержка ввода, редактирования и вывода. Соотв., доступ к тем или иным частям регилируется правами. Скажем, обычный посетитель без логин-пароля имеет уровень 1; баньщик (если удалось его распознать) - 0, а все уровни выше - только зарегистрированные пользователи.
--------------------------
Давай для начала расскажу про реализацию 2.2.3 (она и 8 пунктов админки работают у меня под VMware).

Я вынес все ф-ии show_* и т.п., все их переменные в отдельные модули по назначению. Получилось 6 модулей: articles, links, files, blog, news, misc (одна ф-ия статистики). Теперь код, желающий обработать шаблон, сам заявляет, какие модули ему нужны. Каждый модуль - класс, содержащий информацию об необходимых входных данных и сооответствия ф-ий класса шаблонам. Загрузчик проверяет наличие класса (иначе подгружает и создает объект). В процессе подготовки к обработке шаблона из объектов забирается информация об шаблонах, динамически составляется таблица замены и регулярное выражение. По сути, изменений не много - просто разделил. В итоге, все файлы страниц стали близнецами типа:
Код:
<?php
require_once(&#39;include_modules.php&#39;);
require_once(&#39;include_header.php&#39;);

echo $site->proc_template(&#39;viewart&#39;);

require_once(&#39;include_footer.php&#39;);
?>
Т.е. дальнейшее объединение обработки просто напрашивалось.
Админку я не стал прикручивать - только адаптировал несколько ф-ий для тестов. Еще доработал db, свой argexp, немного поправил экспорт в XML/RSS, внедрил первоначальный вариант задания конфига, как многоуровневого массива (но мне это показалось слишком неудобным), и на этом и остановился. Причина уже упоминается в первом посте: надоело лапатить одни и те же строки, решил, что начать сначала будет лучше. Код модулей хоть и отделился, но остался почти тем же: править не удобно.
--------------------------

Про 3.0.0 - чуть позже.

PooH, замена у нас так и работает: шаблон в HTML-тексте заменяется на вывод ф-ии.
Я пробовал в прошлом году делать парсер, который и параметры в шаблонах мог распозновать, но пока особого смысла в этом не вижу.
« Последнее редактирование: 20-12-2007 15:18 от Алексей1153++ » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
PooH
Глобальный модератор

ru
Offline Offline
Пол: Мужской
... и можно без хлеба!


« Ответ #15 : 01-03-2006 17:45 » 

идея в том чтобы вообще не было необходимости лезть в *.php чтобы например изменить вывод новостей.
Записан

Удачного всем кодинга! -=x[PooH]x=-
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #16 : 01-03-2006 18:20 » 

Кратко о работе vu-3.0.0:

Последовательность выполнения index.php:
1) загрузка конфигурации
2) подключение базы
3) загрузка компонента для проверки доступа
4) разбор параметров GET
5) разбор параметров POST
6) открытие существующей, или создание новой сессии
7) загрузка прочих сервисных компонент ядра
8) определение требуемой страницы, проверка на существование и доступ (соотв. с заменой на какую-либо другую страницу с сообщением об ошибке, или еще чего)
9) обработка страницы и получение от нее данных на вывод
10) произведение манипуляций с заголовками, если необходимо (редиректы и просто назначения)
11) вывод
12) сохранение данных сессии


Это - линейная часть. Каждая ветка, может ветвится.

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

Вопросы?



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

И ты туда же? Все бы вам страницы обозреть... Улыбаюсь
Давайте все-таки сначала сделаем среду для программ, а отображением страниц и абстрагированием от html-кода в php-коде займемся чуть позже. Я, собственно, для этого и начал тему: чтоб не переписывать одно и то же! Так бы я написал сейчас полуфабрикат, а потом оказалось бы, что чем-то пользоваться совсем не удобно, а то и невозможно (опять таки, я о среде) и пришлось бы вносить изменения в ядро, а затем лопатить вышестоящий код. Поверте, что это не малая работа и если прыгать с место на место, то только запыхаемся.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
PooH
Глобальный модератор

ru
Offline Offline
Пол: Мужской
... и можно без хлеба!


« Ответ #17 : 01-03-2006 18:43 » 

Не, ну я не говорю, что все бросать и делать вывод, это я так... мысль высказал. Так сказать для фиксации идеи. Ты на мои высказавания можешь особог внимания не обращать. Так как с движком, PHP и всем прочим знаком только на пример VUEngine. Но хочу понять как все это работает. В свою очередь, могу идеи толкать... над чем надо подумать?
Записан

Удачного всем кодинга! -=x[PooH]x=-
Finch
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #18 : 01-03-2006 19:47 » 

Есть идеи по сохранению старых ссылок, но для этого нужно следующее: в апаче (надо проверить, наверняка через .htaccess можно) можно назначить обработчиком для директории скрипт и все обращения будут попадать к нему. Его же задача будет вычислить новый url и отправить ответ Moved с указанием этого url-а.
Т.е. проблема, теоретически, решаемая. Практика покажет остальное.
Я вчера кое -что искал. Вот наткнулся случайно http://sitemaker.ru/technologies/webserver/error404handling/
Основная идея делать в .htaccess запись ErrorDocument 404 /path/error.html
Где,
ErrorDocument - Сама деректива
404 - Номер ошибки
/path/error.html Файл которыйбудет отображаться при данной ошибке.

Хотя видел сообшение, что IE когда видит код возврата 404, вставляет собственную страницу.
« Последнее редактирование: 01-03-2006 19:49 от Finch » Записан

Не будите спашяго дракона.
             Джаффар (Коша)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #19 : 01-03-2006 22:02 » 

Есть нечто лучше, но для этого надо иметь доступ к конфигурации хоста.

Alias / /full-path/club.shelek.com/cgi-bin/handler.php

Произойдет трансляция URL /* в локальный путь на сервере /full-path/club.shelek.com/cgi-bin/handler.php/* и при любом запросе исполняется этот скрипт. Пример с моего локального сервера:
[SERVER_SOFTWARE] => Apache/2.0.52 (ASPLinux)
    [SERVER_NAME] => h2.host1.local
    [DOCUMENT_ROOT] => /var/www/virt/h2.host1.local/www/
    [SCRIPT_FILENAME] => /var/www/virt/h2.host1.local/cgi-bin/index.php
    [QUERY_STRING] => aaa=xxx
    [REQUEST_URI] => /labuda.php?aaa=xxx
    [SCRIPT_NAME] =>
    [PATH_INFO] => /labuda.php
    [PATH_TRANSLATED] => /var/www/virt/h2.host1.local/cgi-bin/index.php/labuda.php


Код при этом целиком скрыт с глаз Ага Красиво, но не всегда реализуемо: от хостера зависит.
« Последнее редактирование: 01-03-2006 22:19 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #20 : 01-03-2006 22:17 » 

Проверил -  ErrorDocument срабатывает аналогично. Необходимое условие: AllowOverride FileInfo для директории, в которой находится .htaccess

Кстати, код ответа легко переопределить: header('HTTP/1.1 200 OK', true);
« Последнее редактирование: 20-12-2007 15:19 от Алексей1153++ » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #21 : 02-03-2006 12:33 » 

Я думаю, что все у нас работает, так как 404 страница для сайта установлена.
Записан

А птичку нашу прошу не обижать!!!
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #22 : 02-03-2006 13:31 » 

Беру таймаут на день-два. Нужно немного концепцию обдумать.

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
PooH
Глобальный модератор

ru
Offline Offline
Пол: Мужской
... и можно без хлеба!


« Ответ #23 : 02-03-2006 14:15 » 

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

Удачного всем кодинга! -=x[PooH]x=-
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #24 : 02-03-2006 14:24 » 

Согласен с обоими - впереди выходные, кидай затравку.
Записан

А птичку нашу прошу не обижать!!!
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #25 : 03-03-2006 10:36 » 

Вечерком напишу.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #26 : 03-03-2006 21:25 » 

Собственно, размышления о концепции ядра.

Ядро сосотоит из набора кирпичиков. Эти самые кирпичики заничаются каждый своей задачей: поддержка БД, разбор и составление URL, работа с параметрами POST (и файлами), работа с cookie, с сессией, и всем чем угодно. Главное - чтоб каждый кирпичек работал с одной неделимой вещью, а все остальные - через него.
Что это даст:
1) Компановка конечного приложения с необходимым функционалом, а не со всей кучей.
2) Простота изменения: менять или наращивать придется лишь в одном месте. Это, конечно, не совсем так: напр., SQL-запросы, оптимизированные под MySQL на других СУБД могут не заработать. Это можно списать на зависимости одних компонент от других - это нормально.
3) Получается toolkit для создания web-приложения. Не надо будет каждый раз писать заново, или подбирать подходящее из наработок, а всего-лищь скомпоновать из блоков ядро, минимум программирования в index.php, конфиги: остается только работа с логикой и дизайном.
4) Древовидная система: index.php в корне, блоки - ветки. Можно легко удлинить ветку, добавив необходимые блоки. При этом, корень и прочие блоки не нуждаются в изменении.

Для группирования ф-ий и данных блока я оформляю его как класс.

Стоит задача найти оптимальное решение по интерфейсу управления блоками и доступу к их ф-иям. Задачка включает в себя следующие требования:
1) Простота добавления блока к приложению.
2) Централизованное управление загрузкой, инициализацией, хранением блоков.
3) Простота вызова ф-ий блока: чтоб код был логичным, читаемым и не длинным.

Надеюсь, для начала этого достаточно?
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #27 : 04-03-2006 23:07 » 

Вот информация для дальнейшей головоломки. Это - основа.
Смотрите, спрашивайте, критикуйте, предлогайте.

Внимание: файл я заменил. Убрал с десяток ошибок.

* vu-core-3.0.2.tar.gz (4.94 Кб - загружено 1251 раз.)
« Последнее редактирование: 04-03-2006 23:39 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
PooH
Глобальный модератор

ru
Offline Offline
Пол: Мужской
... и можно без хлеба!


« Ответ #28 : 06-03-2006 08:53 » 

Цитата
Смотрите, спрашивайте, критикуйте, предлогайте.
я бы стремился к тому, чтобы в index.php было только что-то вроде:
Код:
$core = new core__core();
ini_set('error_reporting', E_ALL);
ini_set('display_errors', 'on');
$core->run();

то есть:
1. _g и _yes вынес бы в utils.php
2. config был бы объектом (свойством) core и создавался бы при $core = new core__core();
3. был бы класс core_modules, который отвечал бы за загрузку модулей ядра (тоже $core = new core__core(); );
4. был бы класс user_modules, который отвечал бы за загрузку пользовательских модулей (тоже $core = new core__core(); );

по поводу загрузки модулей.... я бы создал отдельный файл настроек core_modules.cfg:
Код:
[LOADING]
db
main

[DB]
param1 = ....

[MAIN]
param1 = ....
...
ну то есть, идея в том, что все настройки вынести из кода.

а также:
user_modules.cfg:
Код:
[LOADING]
news
links

[NEWS]
count = 5

[LINKS]
color = red
...


ЗЫ: все сугубо ИМХО.
« Последнее редактирование: 20-12-2007 15:21 от Алексей1153++ » Записан

Удачного всем кодинга! -=x[PooH]x=-
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #29 : 06-03-2006 10:54 » 

PooH, развитие на месте не стоит. В текущей версии я вынес подобные ф-ии. Без комментариев index.php занимает пол стронички.

2) Идея интересная. Подумаю. В принципе, она соответствует текущей концепции. Только есть одно НО: настройки лучше загрузить до загрузки модулей.

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

Завтра выложу продолжение. Несколько переиначил, расширил и еще ошибок нашел.
« Последнее редактирование: 06-03-2006 10:56 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Страниц: [1] 2  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines