ExBB Community ExBB Community
 Сайт проекта ExBB Общение объединяет!
Войдите на форум при помощиВойти через loginza
 Чат на форуме      Помощь      Поиск      Пользователи     BanList BanList

Страниц (13): В начало « ... 5 6 7 8 9 10 11 [12] 13 »

> Найдено сообщений: 186
Flat Отправлено: 21 июля 2018 — 11:16 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
1Bot пишет:
До сих пор сложно разрабатывать модули (нет описания интерфейсов взаимодействия ядра и модуля, тут полиморфизм ООП был бы очень кстати), чтобы их было легко интегрировать в админку и в основной форум.

Вот не согласен, что обязательно нужен полиморфизм ООП и вообще ООП. Помните как всё начиналось? Был простой и относительно понятный скрипт. Его можно было понять начинающему в PHP. Это была его фишка, как и то, что он имел файловую базу. Ввели ООП, пусть даже "недоООП", однако, чтобы понимать код, теперь нужно быть программистом, программистом-админом, а не просто админом с начальными навыками PHP. Но это всё лирика, а давайте о модульности.
Если кто остался в трезвом уме и твёрдой памяти, ибо прошло уже много лет, и помнит ещё то, что Юрий говорил о модульности в данном движке. Он говорил - чтобы написать какое-то расширение к exbb, необходимо изучить ВЕСЬ код exbb! Однако мало тех, кто осилил это. Многие говорили в том же духе и желали иметь такую систему, в которой можно было бы одним кликом устанавливать модули.
Чтобы этого добиться необходимо написать абсолютно новое ядро, о чём говорил Юрий. Также он писал, что одному это не по силам, ибо посмотрите сколько программистов работают над импортными популярными движками. По силам-не по силам, это ещё тот вопрос..
Создание нового ядра назрело и перезрело. Развитие exbb остановилось потому, что невозможно вменямо писать для него модули. Форк, который поддерживает вебмастер это другой зверь, традиционный, и скорее всего тупиковый. Это попытка разукрасить давно умершего..

К чему я пришёл после долгих раздумий.
1) Должна быть тотальная модульность.. Такая, при которой возможно будет в один клик заменить даже само ядро системы.. Цель: при установке модулей не лазить в код, а просто запускать инсталлятор. Он сделает всю работу за нас.
2) Для написания модуля не нужно будет знать весь код движка, а только некоторые правила создания модуля и соглашения.
3) Всё в движке должно быть строго одинаково и сделано по аналогии со всеми остальными. Что это значит? Каждый модуль состоит из 4 главных файлов:
1. install.php - инсталлятор модуля. Запускается в один клик и устанавливает модуль в систему;
2. uninstall.php - деинсталятор модуля. Удаляет модуль из системы;
3. index.php - головной файл модуля, который его запускает при работе;
4. config.php - файл конфигурации модуля. В нём прописаны зависимости модуля, какие компоненты он запускает, версию, и др. параметры;

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

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

Система становится логичной и понятной. Каждый делает своё дело и никому не мешает. Так мне это представляется.
Flat Отправлено: 16 июля 2018 — 12:03 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
Flat пишет:
Текстовая база предполагается будет иметь такой вид:
<?die;?>$arr=array (
'id' => 1,
'name' => 'admin',
'pass' => 'jfjdkfvslklak84j4wyff7dhe7dhe'
'mail' => 'hhhhh@mail.ru',
array (
0 => 1
),
);

Если использовать такой вид:
CODE:
<?php
if (!defined('IN_EXBB') ) die('Hack attempt!') ;
return array
(
'id' => 1,
'name' => 'admin',
'pass' => 'jfjdkfvslklak84j4wyff7dhe7dhe'
'mail' => 'hhhhh@mail.ru'
);
?>

то отпадает необходимость в функции read, так как теперь файл подключаем просто:
$nameOfArray=include "datfile.php";
Flat Отправлено: 13 июля 2018 — 14:09 • Тема: ExBB 2.0.0-Pre • Форум: Релизы

Ответов: 138
Просмотров: 81219
NordWest пишет:
Да, есть такая проблема.

Кстати, при таком подходе(да и в других случаях), можно облегчить жизнь пользователей скрипта путём простого добавления в основной скрипт комментария с русской строкой замещения. В этом случае вообще не придётся лазить по ланг файлам. Радость
Flat Отправлено: 13 июля 2018 — 13:34 • Тема: ExBB 2.0.0-Pre • Форум: Релизы

Ответов: 138
Просмотров: 81219
NordWest пишет:
Другое дело, что и в языковых файлах нужно наводить порядок и выработать какую-то систему.

Наверно вы правы. Можно упростить скрипт таким образом:
Делаем на каждый модуль свой один lang файл. Вместо ассоциативного массива используем простой массив. Что это даёт? А вот смотрите: сейчас, что бы посмотреть строку замещения необходимо открыть языковой файл и, заметьте!, ОТЫСКАТЬ строку вида $lang['Forum_Info'] = 'Информация о форуме'; по id Forum_Info. Просто так глазами не получится слишком долго, а время - деньги, как говорят американцы, поэтому надо задействовать поиск по файлу в редакторе. А это опять же утомительно постоянно нажимать на кнопки теряя время. По каждой строчке использовать поиск?
Если же вместо английских алиасов сделать простой числовой индекс то проблема снимается. Если в файле строки упорядочены по своим индексам, то найти нужную строку не представляется сложным:
$lang[0] = 'Информация о форуме';
$lang[1] = 'Ответов';
$lang[2] = 'Темы';
Смотрим на число и сразу находим нужную строку, это гораздо быстрее и приятнее, чем пользовать поиск по файлу. Кстати, для разрабов движка это сущее облегчение, ибо не нужно тратить время на постоянное придумывание алиасов на английском языке.
Flat Отправлено: 13 июля 2018 — 12:27 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
Желательно бы ещё реализовать механизм настройки стиля отображения, как например это сделано в жж из админки. Чтобы не лазить по коду, а менять всё через центр.
Flat Отправлено: 12 июля 2018 — 10:59 • Тема: ExBB 2.0.0-Pre • Форум: Релизы

Ответов: 138
Просмотров: 81219
WebMaster пишет:
Да, места требуется больше, однако, с этой кодировкой не возникает проблем при использовании нестандартных символов, чего добиться с Windows-1251 было затруднительно.

А что если делать вставки посредством html последовательностей? Так мы избежим потерю места на хостинге и обеспечим поддержку юникод-симовлов.. Правда тут без js не обойтись..
NordWest пишет:
Я бы то же не стал отказываться от мультиязычности.

"И нам становится страшно что-то менять"..
А что если сделать два варианта: один с поддержкой мультиязычности, а другой без оной? Ну, типа лайт-версии основного форумного движка.. Не всем же нужен навороченный форум, некоторым нужно что-то попроще и попонятней, в зависимости от уровня админа. Но чтобы функционал был на уровне основного.
Кстати, не вижу причин, почему, якобы, стало бы трудно обеспечить мультиязычность если у нас не будет отдельной папки с описанием выводимого текста, а будут только конкретные модули с этим текстом внутри. Ведь этот текст тоже можно выделить путём, например, печати его на отдельной строке в коде. Тем более что весь этот текст лежит в контексте вывода в конкретном месте кода. Человек, который хочет сделать мультиязычность, открывает соответствующий модуль и просматривая сверху вниз меняет текст. Потом открывает другой модуль.. Ну, надо попробовать, попытка не пытка.
Flat Отправлено: 12 июля 2018 — 10:23 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
Выше в коде небольшая оплошность. В связи с тем, что поменял <?die;?> на <?phpdie;?> нужно изменить цифру 8 на 11 в некоторых местах кода.
Код черновой без логирования ошибок. Большой плюс такого подхода в том, что исключается ситуация с обнулением файлов, что иногда наблюдалось в exbb. Если что случится, то хотя бы останется временный файл с данными.
Flat Отправлено: 11 июля 2018 — 11:27 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
Yamaliya пишет:
Надо бы предусмотреть конвертер туда и обратно.

Согласен. Просто прежде чем говорить о конвертере, необходимо сначала создать новый двиг.
Yamaliya пишет:
двумя руками ЗА.

Всё, значит так и будет. Ха-ха
1Bot пишет:
тогда в функции сохранения можно использовать любой из этих форматов данных.

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

1Bot пишет:
не забывайте, что основной код был написан еще для PHP4 и лишь немного видоизменен для работы с PHP5 на уровне "чтобы не возникало фатальных ошибок

Я прекрасно всё понимаю. Также прекрасно вижу откуда растут ноги многих функций. Первоначальный автор форума, Александр Субханкулов, использовал код IPB форума. И, кстати, правильно делал, ибо зачем городить велосипед если есть хорошие рабочие решения, жизнь-то одна.
Потом, уже после него, форум был изменён, хотя структура осталась практически прежней.
1Bot пишет:
Сейчас же есть возможности как раз использовать средства ООП из новых версий PHP7 и по возможности убирать таким образом функциональные повторы в существующем коде.
Так что полный отказ от ООП будет скорее ошибкой.

Этим и занимается, насколько я понял, ув. WebMaster . Посмотрел код последней версии, там действительно ООП несколько улучшен. Вот эту ветку и следует продолжать делать в том же духе. Это, так сказать, старая песня о главном, и пусть она будет, кому нужно. Мне - нет.. Я хочу иного.. Закатив глазки
ООП ведь это всего лишь попытка эмулировать модульность, а её можно эмулировать и без ООП, хотя в PHP на это есть определённые ограничения.
1Bot пишет:
Каждый модуль вполне себе может быть отдельным сколь угодно сложным объектом, который взаимодействует с классом ядра форума и реализует заданный интерфейс модуля, а также использует все возможности ядра.

Это самое сложное: понять как всё будет функционировать на всех уровнях; каким образом ДОЛЖНО быть устройство модульного движка. Чтобы и безопасность повысить и чтобы он был понятен и прост. Я постоянно об этом думаю. И уже сложилась определённая картина..
1) На самом верхнем уровне находится файл index.php. Это - головной модуль. Через него происходит вся работа. Его задача: инициализировать данные, авторизовать пользователя, провести валидацию имен существующих модулей в системе с именем того модуля, который приходит с запросом пользователя и подключать эти модули. Он ничего не выводит пользователю, а только выполняет эту черновую работу. Валидация имён позволяет легко обеспечить высокую безопасность движка, по принципу: свой - свой. Валидация ключей и значений возлагается на модули верхнего уровня, ибо только они сами знают "своих подопечных".
2) Модули верхнего уровня это: вывод главной страницы, регистрация и пр.
3)Модули нижнего уровня работают через подключение в модулях второго уровня.
Таким образом осуществляется строгая иерархическая система, которая легко понятна. Есть головной модуль, первого уровня, который знает о существовании модулей второго уровня, а модули второго уровня знают о существовании модулей своих подопечных.
В коде всё станет понятней что где и как. Так мне это представляется, и я начал уже потихоньку это осуществлять.
Flat Отправлено: 11 июля 2018 — 10:34 • Тема: ExBB 2.0.0-Pre • Форум: Релизы

Ответов: 138
Просмотров: 81219
А ничего, что на это требуется как минимум в 2 раза больше дискового пространства?
Flat Отправлено: 10 июля 2018 — 14:12 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
8)Вернусь к ООП.
ООП надо делать там, где его не видно: в десктопных приложениях, системах, которые поддерживают ТОЛЬКО разрабы. Для обычных админов, которые знакомы с PHP на среднем уровне, и для которых концепция ООП тёмный лес с чертями, это на фиг ненужно! Мы же делаем форум для пользователей, а не для себя. Хотя некоторые товарищи специально усложняют код, чтобы можно было делать бабки. Ну, это их проблемы.
Flat Отправлено: 10 июля 2018 — 13:47 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
6) Шаблоны.
Свалены в одну папку. Чтобы понять код приходится постоянно лазить по разным папкам, что сильно утомляет. Может быть вообще отказаться от шаблонов. В FluxBB их нет, и код намного легче воспринимается на глаз и более понятен.

7)Языки.
Универсализация, в расчёте, что кто-то(а кто - один два чел.?) когда-то(в 22 веке)захочет сделать свой форум на суахили, приводит к тому, что код становится абсолютно не читаем. А чтобы понять что же здесь в данном конкретном месте выводится приходится лопатить не один десяток файлов. А там поди найди, ибо этих файлов целая куча. Если форум позиционируется как форум для русскоязычного сообщества, то нужно отказаться от языковых алиасов. У зарубежных товарищей существуют десятки форумов, которыми они и пользуются, а вот зачем ради мнимой универсализации усложнять жизнь админам, вообще не представляю. О вкусах не спорят..
Тут я высказываю то, что хотел бы видеть в своём собственном форуме.
Когда понимаешь что придётся переделывать почти всё, то это будет уже другой форум, хотя местами и с включением старого кода..
В общем, exbb является крайне не дружелюбен к простым админам, что необходимо срочно исправлять. К сожалению его эволюция почему-то двигается по пути усложнения кода. Код должен быть простой и ясный, только тогда он будет безопасен. Без выкрутасов, типа, "я и так ещё могу". Да я могу круче, но не буду из принципа.
Flat Отправлено: 10 июля 2018 — 09:01 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

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

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

2)Из рук вон плохо поддерживается модульность, коей, по большому счёту вообще не видно.

3)Папка members содержит файлы с некоторой информацией о пользователях. Другая информация о данных пользователях разбросана по другим папкам. Например те же аватарки и т.п. Имело бы смысл каждому пользователю дать отдельную папку и сбрасывать туда все файлы которые его касаются.

4)В скрипте используются сессии. Сессии полезны, например в том случае, если пользователь отключил куки. В этом случае при входе на сайт он будет залогинен пока есть сессия, то есть, пока не закрыт его браузер.
Теперь попробуйте заблокировать куки с данного форума, и вы увидите, что при попытке захода на форум не происходит авторизации. Это серьёзное упущение. Тогда зачем нужны сессии? Детство какое-то..

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

Пока всё.
Flat Отправлено: 10 июля 2018 — 08:27 • Тема: ExBB 2.0.0-Pre • Форум: Релизы

Ответов: 138
Просмотров: 81219
Yamaliya пишет:
Но под XP он не работает.

У меня работает. Просто надо установить версию 5.2.8
---------------
Вопрос к топикстартёру:
В новой версии в файлах базы данных информация сохраняется в utf-8?
Flat Отправлено: 9 июля 2018 — 12:34 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
Текстовая база предполагается будет иметь такой вид:
<?die;?>$arr=array (
'id' => 1,
'name' => 'admin',
'pass' => 'jfjdkfvslklak84j4wyff7dhe7dhe'
'mail' => 'hhhhh@mail.ru',
array (
0 => 1
),
);
Это гораздо читабельней чем:
a:4:{s:2:"id";i:1;s:5:"name";s:8:"admin";s:4:"pass";s:29:"jfjdkfvslklak84j4wyff7dhe7dhe";s:4:"mail";s:13:"hhhhh@mail.ru"}
Flat Отправлено: 8 июля 2018 — 11:18 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 37868
Добавлю. Это я сделаю сам, тут делов на пол часа.
Сейчас курю тему "Перспективы дальнейшего развития". Там yura3d сказал такую фразу: "Перспективы файловой версии - раз и навсегда кануть в лету. Это случится рано или поздно, более того, это уже сейчас происходит. "
Он там усиленно продавливал тему изменения базы данных с файлов последовательного доступа к файлам прямого доступа, как в СУБД. И говорил, что это раз в 50 ускоряет работу форума.
Я согласен с ним, что ускоряет, тем более, что сам написал и тестировал функцию бинарного поиска по файловой базе прямого доступа, и скорость оказалась просто КОСМИЧЕСКОЙ)). А ведь можно сделать и прямую выборку.. Но всё это сильно усложнит двиг форума.
Но я не согласен, с yura3d в том, что исчерпан потенциал данного движка.
Не исчерпан. Просто не там искали..
Например: зачем качать всю тему целиком, если мы выводим всего например два десятка сообщений? Это имеет смысл делать если мы осуществляем поиск по теме. А в обычном случае этого не требуется. И если тема разрастётся, то скорость форума упадёт. Хотя, я тестил: 4 мегабайтная тема грузится у меня за 0,2 сек.
Например: мы можем делить тему на несколько отдельных файлов, тогда загрузка страниц будет линейной константой..
Можно упростить форум сделав его с постоянным числом сообщений на страницу, зато скорость будет приличной.
Конечно можно оставить и в этом случае выбор за пользователем, хотя логика работы форума несколько усложнится.
Малое количество сообщений на страницу тоже плохо, так как пользователь всё равно просматривает предыдущие страницы если тема имеет большой процент новых сообщений. Тогда можно сделать 50 сообщений на страницу либо константой либо оставить выбор пользователям. Или сделать например по 100 сообщений на файл, тогда, к тому же, нагрузка на сервер уменьшится и количество файлов будет приемлемым.
Как считаете? Для меня важно мнение простых и не простых пользователей.

Страниц (13): В начало « ... 5 6 7 8 9 10 11 [12] 13 »

Яндекс.Метрика   

Powered by ExBB
ExBB FM 1.0 RC1 by TvoyWeb.ru
InvisionExBB Style converted by Markus®

[Script Execution time: 0.0562]     [ ]