ExBB Community :: Версия для печати :: Доработки и исправления в ExBB [4]

46. Yamaliya - 18 августа 2018 — 00:32 - перейти к сообщению

Flat ,

Цитата:

традиционный подход - один файл-один пользователь.

Оставьте такой вариант. Порой наглядность важнее эффектности.

47. Flat - 18 августа 2018 — 11:19 - перейти к сообщению

Yamaliya пишет:

Порой наглядность важнее эффектности.

Оставим. Кстати, принцип - один файл один пользователь достаточно эффективен по скорости. Единственный минус, если файлы маленькие то будет перерасход дисковой памяти. Например, если файл пользователя весит 1 килобайт(обычно так и есть) то на диске он займёт 4 килобайта, так уж устроены современные ОС. Есть ещё вариант сохранять пользователей по ~50 на файл..

Меня вот интересует ещё такой вопрос, на который пока не нахожу ответа. Может кто выскажет свои соображения. Количество сообщений на страницу. Часто ли вы сами пользуетесь такой возможностью в своём профиле? Так уж ли необходима такая фича? Например, предположим, мы имеем форум с постоянным числом сообщений на страницу. Пользователь, который часто просматривает тему помнит: моё или его сообщение вот на такой-то странице, поэтому если что, то его легко найти(часто поиск не помогает), так как страницы постоянны. "С шестой по седьмую страницу была не хилая баталия.. Я помню..". Что сейчас. Имеем форум с "плавающими" страницами. Если у каждого своя пагинация, то появляется разнобой в представлениях.. Форум расплывается и не имеет своего лица, или личика.. Ну, какая к ч...у разница 15 у него сообщений на стр. или 25? Ну, что тебе от этого холодно или жарко? Ну, форум-то мой, пусть у всех будет одно единственное о нём представление.. Это философские размышления.. Что касается реализации, то это позволит:
1) Резко упростить пагинатор.
2) Увеличить скорость загрузки страниц.
3) Скорость загрузки не будет зависеть от обьёма темы, тему не нужно будет дробить на более мелкие темы, как это бывает на других форумах.
Мнения.

48. Yamaliya - 18 августа 2018 — 15:38 - перейти к сообщению

Flat пишет:

Так уж ли необходима такая фича?

Ни разу не пользовалась.

ps. А можно будет ваши наработки использовать в существующем форуме, или это только для новых форумов?

49. Flat - 19 августа 2018 — 08:53 - перейти к сообщению

Yamaliya пишет:

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

Существующий форум можно будет перевести на новый движок путём простой конвертации файловой базы. "И лёгким движением руки, брюки превращаются..))"Юрий неоднократно писал, что нужен новый движок, ну, вот, я его и делаю, только по своему, так, как мне лично представляется движок на файловой базе. Нужно более гибкое ядро, иначе форум развиваться не будет. Да он уже и так остановился в развитии, и потерял все свои ориентиры..
Я знаком с кодом многих форумов, в том числе yabb, fluxbb и т.д. Хотелось бы всё лучшее взять понемногу от идей разных форумов.

Yamaliya пишет:

Ни разу не пользовалась.

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

50. - 19 августа 2018 — 15:12 - перейти к сообщению

Считаю, что кол-во сообщений на странице стоит давать менять только администратору. Остальным оно не надо.

51. Flat - 22 августа 2018 — 12:00 - перейти к сообщению

Zeg пишет:

кол-во сообщений на странице стоит давать менять только администратору.

Согласен. Позиция "шоб було" не универсальная позиция..
----------------------

Итак окончательно определился с форматом файловой базы. Реализовано 9 функций по работе с ней. Это наверно 10-й вариант.. Похоже что окончательный.
Файл с пользовательской информацией будет иметь такую структуру:
1
admin
jfjdkfvslklak84j4wyff7dhe7dhe
hhhhh@mail.ru
и т.д.
На каждой строке одно поле записи. Окончания строк в unix формате - \n
Любой редактор кода показывает строки с их нумерацией. Чтобы вспомнить на какой строке какое поле открываем файл документации, в котором видим описание:

Индексы и описание полей файла с информацией о пользователе.
-------------------------

0) - номер пользователя;
1) - ник(логин) пользователя;
2) - пароль;
3) - электронный адрес почты;

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

52. Flat - 23 августа 2018 — 11:38 - перейти к сообщению

Не хватает ещё вот такой фичи.
Общаясь на разных форумах, я заметил такую вещь. Вот идёт обсуждение какой-то темы. Тут вдруг тема несколько разделилась и обсуждение отклонилось в другую сторону, которая лишь опосредованно касается основной, но всё же к ней относится. Часто в таких случая создают совершенно новую тему и ведут обсуждение уже в ней. Было бы совершенно логично в таких случаях создать ПОДТЕМУ, чтобы было видно что к чему относится. К сожалению я не видел реализацию ПОДтем в других движках..

53. Flat - 2 сентября 2018 — 09:12 - перейти к сообщению

Сейчас делаю регистрацию. Первый вариант сделал на сессиях и куках, а второй более простой только на куках. Какой оставить время покажет, но мне больше нравится последний.
Главное сделать ядро с основными функциями: регистрация, авторизация, вход/выход, добавление тем/сообщений, админские функции, а там постепенно можно будет наворачивать форум разными плюшками.
Что меня ещё неустраивает или настораживает в exbb? Я постоянно читаю и знакомлюсь с его кодом. Вот возьмём файл с инфо о пользователе. При каждом заходе пользователя на сайт, происходит полная перезапись этого файла. И так по каждому зашедшему зарегистрированному пользователю. Это не есть хорошо по разным причинам, которые понятны только специалистам. Лучше бы его не трогать вообще, а если что и менять, то через редактирование своего профиля пользователем или админом. Так как это редкая процедура то опасность запороть файл снижается до 0.. Но, как быть например с информацией о последнем посещении? Так сперва нужно понять а где она вообще требуется? Для статистики. А для статистики у нас есть отдельный файл статистики. По зашедшим пользователям в этот день там и надо всё это отслеживать. Этот файл пусть постоянно обновляется и перезаписывается, его не страшно потерять если что, так как инфо в нём обновляется ежедневно. При этом файлы с пользователями в основном будут только читаться..
То же самое и с работой с кукисами. При каждом заходе на сайт куки обновляются. Кто-то уже указывал на проблему переполнения куки, хотя я и смутно представляю себе что могло у него случится. Однако глядя на код видно что тут используется не одна кука, а их целых 10 штук! Не многовато ли? Тем более существует определённый лимит на количество кук с одного сайта. Лучше иметь одну куку, чем 10. Её легко отслеживать. Далее зачем с каждым заходом пользователя обновлять куки? Это существенная нагрузка на трафик, да и не безопасно, в виду существования различных "снифферов". Лучше всего указать время истечения куки, например 1 год, и например, ждём когда она истечёт и пользователь снова не залогинится, что позволит ему хотябы свой пароль не забыть, или когда истекут 11 месяцев то обновляем куку. Ладно, слишком много понаписал..

54. Flat - 10 сентября 2018 — 09:48 - перейти к сообщению

Что-то, замер наш форум..
Эх, по-моему я не в ту степь кинулся.. Начал делать совсем другой движок, который к этому ну, ни каким боком.. Там всё по новому: файловая база, модули и пр. Это новый форум. И дело это на ГОДЫ. Дело это хорошее, так как действительно новый движок назрел. Более того: я буду его делать потихоньку. Но, вот лично мне файловый движок нужен уже сейчас, даже не сейчас, а вчера.. Более менее вменяемый у нас только один, и это - exbb.. Я запускал его у себя, но что-то такое выплыло в самый неподходящий момент и от него отказался в пользу других, однако и другие тоже меня не устроили..
По моему выход только один: довести до ума этот..

55. - 10 сентября 2018 — 18:37 - перейти к сообщению

Flat пишет:

довести до ума этот..

В смысле устранить ошибки в текущем движке?

56. - 10 сентября 2018 — 18:43 - перейти к сообщению

Мда... Так я и думал ;о))))))))))))))))

57. - 10 сентября 2018 — 18:58 - перейти к сообщению

Guyver пишет:

Мда... Так я и думал

Ну так это же было естественно. Вы представляете объем работы, который нужно провернуть, что бы написать новый движок. Да ещё и в одиночку. Это просто нереально.

58. 1Bot - 10 сентября 2018 — 21:19 - перейти к сообщению

Чтобы было проще работать с любой из версий, необходимо:

1) декомпозиция по функциональному признаку всех уже существующих данных, свойств и методов их обработки со словесным описанием "доменов" (формирование основных классов, их данных и методов);

2) выделение взаимосвязей "доменов" и словесное описание их характера взаимодействия (создание интерфейсов между классами);

3) описание базовых "доменов" для хранения данных;

4) описание целей и критичности взаимодействия.

Flat , Вы сейчас пробуете свои силы на 3 и 4 этапах, без полного прохождения 1 и 2. Уверена, что это потребует больше сил и мыслительной энергии, чем естественный путь.

59. Flat - 11 сентября 2018 — 03:49 - перейти к сообщению

Guyver пишет:

Мда... Так я и думал ;о))))))))))))))))

Думаете "а мальчик-то слился, не потянул..". Вы ошибаетесь. Новый движок я потяну. Даже в одиночку. Вопрос времени. Около 20 функций я уже реализовал. Полностью: работа с файлами, запись в пользовательский лог, в лог ошибок, вариант авторизации, начал регистрацию, начал функции вывода элементов главной страницы. Просто сейчас процесс несколько застопорился, 2-3 дня не приступал к кодингу, были другие интересы. Написать форум задача далеко не тривиальная, много думать нужно своей головой прежде чем пальцы начнут стучать по клаве.. Мы же хотим уйти от того, чтобы лазить в сырой код при добавлении плагинов-модов. Поэтому тут нужно так всё сделать, чтобы обеспечить такой функционал, при этом сохранить простоту кода.
Насчёт ГОДОВ конечно я погорячился. Если тратить хотя бы по 4-5 часов в день, то ядро можно написать за несколько месяцев.

NordWest пишет:

В смысле устранить ошибки в текущем движке?

Таких уж серьёзных ошибок в движке уже и нет, так как за годы множество багов было исправлено. Я имел в виду общую архитектуру. Например вместо 10 кук сделать одну. Изменить работу с файлами, сделав файловую базу более читаемой, примерный код я уже приводил. Подключение модулей сделать через индексный файл. Избавится от ООП он там поверьте вообще ненужен.. Помните был простой движок, потом взяли его усложнили, спрашивается зачем? Усложнение должно было идти в виде усложнения функционала движка, а не его кода..
Вот, вчера написал свои сомнения и мысли, затем опять в тысячный раз открываю код exbb и понимаю: ну тупик же, причём полный.. Опять заниматься приукрашиванием?. Там много моментов, которых по большому счёту просто не должно там быть. Эх, надо засучивать рукава и ПРОДОЛЖАТЬ делать новое ядро! Думаю, к новому году оно будет готово!. То есть ядро уже можно будет запускать. Можно будет добавлять сообщения и создавать темы. Самая сложная часть работа через админцентр, там надо делать по круче, чем сейчас, поэтому голова должна работать трезво и ясно. Часть кода нужно будет оставить от старого exbb потому что я хоть в pHP чувствую себя как рыба в воде, однако в javascript нет. Я им не занимался. Раньше я занимался совсем другими языками: Си и несколько других, которые к вэбу имеют мало отношения. Единственный "родной" это PHP.

1Bot пишет:

1) декомпозиция по функциональному признаку всех уже существующих данных, свойств и методов их обработки со словесным описанием "доменов" (формирование основных классов, их данных и методов);

Всё правильно, так я и хочу. То что отображается лежит в одном месте и т. д. Что касается ООП именно в PHP и именно в данном движке, то я скептик. Лично я понимаю принципы ООП, там для меня нет ничего сложного. Сложности могут возникнуть у пользователей непрограммистов. Скажете: зачем лазить в код? В данном движке без этого не обойтись, а ООП отпугивает. Я вам честно клянусь: никаких преимуществ его применения не было и нет, одни минусы. Можете мне не верить. Всё это лишь мода: если у тебя в коде нет ооп ты отстой, а если есть то ты крут. Эта позиция имеет мало отношения к пользователям которые будут юзать нашу работу. Им нужна стабильная работа движка, а не модные плюшки.

1Bot пишет:

Вы сейчас пробуете свои силы на 3 и 4 этапах, без полного прохождения 1 и 2. Уверена, что это потребует больше сил и мыслительной энергии, чем естественный путь.

Вы очень проницательны! Да, я начинаю с маленьких, иногда совсем не связанных с друг другом вещей. И пока имею лишь смутные очертания этой горы под названием общая АРХИТЕКТУРА . Когда накопятся эти маленькие вещи, то достаточно будет их лишь слепить в месте. А вот как именно, от этого будет зависеть последующая лёгкость или трудность жизни.
Вот пример маленькой вещи, который на днях я накропал. Это логоменю форума - самое верхнее меню с картинками:

CODE:

<?php if (stristr($_SERVER['PHP_SELF'], 'show_logomenu.php') && !defined('EXBB_OK')) {die('Доступ запрещён!');}
function exbb_showLogoMenu()
{
global $ContentBuf, $FunctionsPath, $ModulesPath, $Config;
require_once($FunctionsPath.'get_list.php');
$arr=exbb_getList($ModulesPath.'logomenu/config.php');
$l=count($arr);
$ContentBuf.='
<table width="100%" cellspacing="6" id="logomenu" border="0">
<tr>
<td width="468" align="center" rowspan="2">'.$Banner.'</td>
<td valign="top" align="right"><span style="margin-right:15px;">'.$Config[2].'</span></td>
</tr>
<tr>
<td align="right" valign="bottom" nowrap>
';
for($i=0; $i<$l; ++$i)
{
$ContentBuf.='
<b><a href="modules/logomenu/im/'.$arr[$i][1].'" title="'.$arr[$i][2].'" border="0" alt=""> <a href="index.php?action='.$arr[$i][1].'" title="'.$arr[$i][2].'"><b>'.$arr[$i][2].'</b></a>    
';
}
$ContentBuf.='
</td>
</tr>
</table>
';
}
?>

Описание нашего меню лежит в отдельном data файле, изменять который может сторонний код(преимущества очевидны). Если сейчас чтобы добавить, удалить или перетасовать меню надо лезть в сырой код и там всё это править, то здесь всё можно сделать из админки. В глобальной переменной $ContentBuf копится наша та или иная страничка. А подключается она в главном глобальном файле шаблона.
Вот пока делаю такие маленькие вещи из которых должен сложиться общий пазл..

60. Parapsixolog - 17 сентября 2018 — 18:21 - перейти к сообщению

Flat пишет:

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

И один из таких крупных недостатков это отсутствия возможности включения SMTP.