101 (02.04.2015 05:22 отредактировано Otto.Zukamoto)

Re: Предложение к будущей версии :)

hcs пишет:

Я могу предложить отказ от совместимости вообще. В целом твоя идея выглядит неплохо, но очень режут глаза глобальные переменные.  По поломанным расширениям -  уменя среди неполного их количества, которое лежит в тестовом проекте, примерно 5-8 штук использует 3 хука из тех что ты удалил. Я не ставил задачу составить список, только проверил что хуки кем-то использовались.
Не считаю необходимым сейчас пушить в мастер, могу создать под это дело ветку, предложите кодовое название.
Ещё есть замечание по внедрению сторонних библиотек, в данном случае twig. Надо как-то решить вопрос с зависимостями, чтобы не включать эти библиотеки в свой код, лучше через composer и договориться в дальнейшем использовать его.

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

2) twig в том то и дело - не тащится в код форума и это не нужно.
там пример реализован как обычная тема модифицированная. которая может использовать любой шаблонизатор.
twig - взят как наиболее популярный и поддерживаемый. смотрел еще смарти - оно 2014 года. других не знаю просто.
я подумал что это лучше чем экстеншен какойто делать еще.
скорее всего останется только один дополнительный файл render.php в теме - в котором реализуется вывод хелперов и прочего.
шаблоны вообще как вздумается можно сделать. тема может быть и без render.php использовать стандартные шаблоны php, просто переопределять шаблоны.
т.е. я считаю совместимость между темами не особо нужна.

3) перепись расширений могу сделать. но только те которые мне нужны, пока не определился какие нужны.

4) проблема с композером - он требует php 5.3 насколько важна поддержка 5.2 ?
я бы для начала свой vendor/autoload.php сделал для совместимости. перенести туда подключаемые библиотеки.
потом видно будет. нужен ли он.

но тут был бы такой плюс - заюзать композер для подключения расширений.
т.е. выпиливается менеджер расширений в админке.
а все расширения делаются в виде модулей и устанавливаются через композер.
в композере есть возможность и исполнять скрипты по установке/удалению модуля
обновление и т.п.
или не выпиливается а делается просто морда в админке к композеру. возможно что даже есть.

wordpress и joomla на такую схему вроде перешли - реализацию еще надо посмотреть.

Добавлено спустя 21 минуту 41 секунду:

глобальные переменные - это наследие форума.
когда более менее сложится структура шаблонов и определимся с расширениями.
можно будет думать о рефакторинге и вычленении переменных. потомучто в хуки надо тоже както их передавать будет.
там еще покачто во шаблонах часть логики работы с бд - тож надо будет вытащить.

Сайт Otto.Zukamoto

Поделиться

102

Re: Предложение к будущей версии :)

1) переписывание расширений выглядит легким сейчас, а когда будут убраны глобальные переменные, внедрены шаблоны и тд и тп, то переписывание будет выглядеть по другому и я уверен, что это не будет легкая задача. поэтому на данном этапе стремление сохранить совместимость только отвлекает.
2) я имел в виду что twig должен быть описан в зависимостях у шаблона, который по сути является расширением
3)вот мы уже отвлекаемся на расширения, которых сотня, не меньше, многие из которых настолько неудачны и базируются на ужасной архитектуре, что проще о них забыть, как например об официальном pun_approval
4) какая проблема с отказом от 5.2? форум прекрасно работает и на 5.4. такая забота о совместимости приведет к написанию велосипедов и отказу  от готовых  удачных решений. вместо развития движка будет тратиться время на развиватие инструментов, в которых нет недостатка. без композера жить можно, но это будет тяжелая жизнь без единомышленников smile

глоабльные переменные, как и другое наследие форума требует рефакторинга, но на пути стоит забота о совместимости с расширениями. совместимость не нужна, иначе развития не получится.

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

103 (02.04.2015 21:02 отредактировано Otto.Zukamoto)

Re: Предложение к будущей версии :)

шаблонизатор twig - это пока не так важно - просто демонстрационный пример. можно переделать потом как лучше.

у меня пока такие идеи:

в первую очередь
- сначала допилить шаблоны, выделить логику - оставить чистые шаблоны, возможность подмены макета через расширения
- добавить поддержку composer - если поддержка 5.2 не нужна - отлично.
чем я собираюсь занятся.

- потом доработать идеологию расширений
- добавить "нормальную" поддержку событий
- остальное постепенно дополнять, не хочется все переделывать сразу.
- добавить рендер в json
- может добавить неймспейс - думаю хватит одного punbb для форума - тут надо посмотреть нужно ли оно вообще,
определится как хранить переменные общие, может в функцию forum('name', 'value'), а может может просто переменную $forum - или те же оставить, как проще всего будет.
- орм laravel или какая самая поддерживаемая, или чтото свое запилить.
не хочется тащить ООП.

- и на последок уже рассмотреть портирование расширений.

- неймспейс для javascript punbb, может избавится от инлайн скриптов и стилей.
добавить возможность вставки скриптов в хедер или футер, поддержка fullajax или подобного
https://github.com/Fedik/FullAJAX (подгрузка контента без перезагрузки страниц)


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

с помощью расширений например модифицировать в блог, статические разделы (страницы) или "аналог livestreet cms"

- и дополнительно:
чтоб потом легко было допилить для запуска на hhvm (ни один фреймворк кроме codeigniter сейчас не запустить судя по инфе)
и альтернативных платформах.

Сайт Otto.Zukamoto

Поделиться

104

Re: Предложение к будущей версии :)

Такой порядок разумен. Без ООП  будет трудно, это не дань моде, это насущная необходимость. Для примера вопрос: где будут все функции ядра, функции парсеров, мыла и прочее? Как решить вопрос именования функций и их возможного дублирования, с учетом расширений? Ну, я не вижу других вариантов кроме неймспейсов и классов, к примеру CoreFunction class со статическими функциями, преобразованный из functions.php. Этот класс будет загружать автозагрузчик, таким образом мы убираем include и require "FORUM_ROOT.'include/functions.php", а рефакторинг сводится к find/replace. Для общих переменных можно конечно написать функцию, а можно взять готовый Dependency Injection Container, который уже готов, который не придётся переписывать и пригодный как для хранения ныне существующих глобальных переменных, так и для фабрик, сервисов и инъекций зависимостей, необходимость в которых нельзя недооценивать.

Добавлено спустя 11 минут 8 секунд:

- и дополнительно:
чтоб потом легко было допилить для запуска на hhvm

Завтра zend выпустит php 7 с компилятором из коробки, без требований что-то допиливать и что тогда?

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

105 (04.04.2015 04:38 отредактировано Otto.Zukamoto)

Re: Предложение к будущей версии :)

- запуск на hhvm это не обязательно и видно будет потом. но этого легко достичь если не тащить много стороннего.

- неймспейсы - я бы предложил просто добавить в файлы входных точек index.php, viewtopic.php и т.п.

namespace punbb;

по идее работать должно и этого достаточно т.к. проблему решит c конфликтом имен.
как уже говорил раньше не хочется тащить DI и ооп покрайней мере на начальном этапе.
одна переменная массив и конфигурацию через php код.

global $_PUNBB; // для хранения данных форума (типа патерн Registry)

function db() { // типа паттерн Фабрика

if (empty($_PUNBB['db'])) {
require подключаем функции для бд если на функциях, для классов просто используем автолоад
// инициализация объекта для работы с БД
}
else {
  $db = $_PUNBB['db'];
}
return $db;
}

function mail($params = array()) {

// тут можео исопльзовать инстанс с разными параметрами
if (!empty($_PUNBB['mail'][serialize($params)])) {
return $_PUNBB['mail'][serialize($params)];
}

if (empty($params)) { 
// инициализрируем с параметрами по умолчанию
$params = include 'config/mail.php'
}

require подключаем функции для почты если на функциях, для классов просто используем автолоад
$mail = ...

return $_PUNBB['mail'][serialize($params)] = $mail;
}

использование где-то в неймспейсе punbb

$db = db();

$mail = mailer(...);

....
этим обеспечивается ленивость инициализации.


в неймспесйе расширения или где то еще

$db = punbb\db();

$mail = punbb\mailer(...);

...


иначе код усложняется и теряется смысл использования форума, т.к. есть аналоги c "увесистой архитектурой".

- насчет орм
я бы просто генератор sql приделал для начала. его просто прикрутить к текущей прослойке БД форума
https://github.com/rivetweb/php-sql
и облегчить код за счет дополнительных конструкций под форум

join_forums(),
    join_user_perms($forum_user['g_id']),

и читабельность.

что думаешь?

Сайт Otto.Zukamoto

Поделиться

106

Re: Предложение к будущей версии :)

Думаю, что ООП не усложняет код, а наоборот упрощает, естественно в разумных пределах. Пример сложного кода без ООП - punbb. smile Генератор, я считаю, только отнимет время, но не даст выигрыша. Я понимаю, что орм несколько тяжелее, но это готовый инструментарий и на порядок выше. Даже если все это приблизит punbb  к "увесистым" аналогам, то мы постараемся чтобы это приближение было только в функциональности.
Кстати, Pimple может быть установлен как расширение php, это я к тому, что если думать о hhvm, то можно учитывать такой фактор.
И кстати по поводу входных точек, если уж у нас есть rewrite.php, который не используется за очень редким исключением, то его наконец-то можно сделать основной и единственной точкой входа. Тогда все остальные можно будет вынести в папку верхнего уровня, эдакие псевдоконтроллеры.

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

107

Re: Предложение к будущей версии :)

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

2) вроде все основное вынес. "вьюхи" без sql запросов.

3) неймспейс для форума предлагаю один - punbb;
далее только функции и классы - и больше не фрагментировать по типу punbb/какойто-модуль1/ punbb/какойто-модуль2/ - только усложняет использование и заставляет использовать use ....

варианты неймспейса для расширений

https://github.com/rivetweb/php-sql/blo … ension.php

1 - в том же пространстве что и форум что опять же позволяет использовать функции и классы форума без use
- автор расширения добавляетс префикс для классов и функций myextension_
где имя совпадает с названием папки /extensions/myextension
работает на любых версиях начиная от php 5.3, выглядит просто.
если сторонние классы юзает должен озаботится чтобы конфликтов не было. но обычно все сторонние классы сейчас используют свои неймспейсы.

https://github.com/rivetweb/php-sql/blo … nsion2.php
добавляется свое подпространство.
при этом придется использовать или префикс неймспейса для punbb или импортировать функции
(импорт  функций работает только начиная с 5.6)

5) у JS пусть остается PUNBB

6) а в чем фишка сделать одну точку входа?

Сайт Otto.Zukamoto

Поделиться

108

Re: Предложение к будущей версии :)

6) Первое что приходит в голову - управление доступом в одном месте, второе - станадартизация входа в приложение для расширений, они тоже часто хотятт иметь свои точки входа. Но судя по всему в рамках твоей концепции это не имеет никакого значения, кроме того это ломает совместимость.

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

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

109

Re: Предложение к будущей версии :)

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

Добавлено спустя 5 минут 52 секунды:

5.6 это слишком высокое требование, к примеру здесь форум работает на 5.4

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

110 (07.04.2015 23:13 отредактировано Otto.Zukamoto)

Re: Предложение к будущей версии :)

пусть тогда будет ООП.
и тогда будут нормальные неймспейсы. как во втором варианте.
раз не будет генератора sql как я предлагал. то и ничего страшного если будут прописывать для функций форума префиксы. а если классы - можно нормально через use прописывать alias.
но тут нужен какойто вменяемый ORM - но чтобы можно было запрос менять как это сейчас делается через хуки.
и чтобы можно было использовать nosql/newsql движки - раз уж прикручиваем новое.
пока я хотел бы оставить функции форума. чтобы все не ломать.
делать постепенно.

https://github.com/fabpot/Pimple - чтото звезд маловато и даты обновления - год назад
может есть чтото получше

Сайт Otto.Zukamoto

Поделиться

111 (09.04.2015 23:19 отредактировано Otto.Zukamoto)

Re: Предложение к будущей версии :)

возможность конфигурировать объекты динамически - да это хорошо для расширений.
но тут думаю достаточно "контейнера сервисов".

сделал такой вариант в отдельном файле https://github.com/rivetweb/punbb/blob/ … rvices.php
и тогда если не нравится такой, можно заменить своим контейнером или если нужна производительность и не нужна динамическая конфигурация - сделать полностью статические функции, через изменения только в одном файле.

по расширениям такая мысль
расширение - это обычный композер пакет.
темы и языковые файлы - тоже вынести в расширения.

- языковые пакеты добаляют в инициализации пути для загрузки языковых файлов
- темы добавляют пути для своих шаблонов, настраивают шаблонизатор для рендера, применение кеширования блоков
- изменение ЧПУ - тоже через расширение.
- настройка кеширования для запросов БД
...

Сайт Otto.Zukamoto

Поделиться

112

Re: Предложение к будущей версии :)

Не могу запустить, ругается на

require __DIR__ . '/vendor/pautoload.php';

в index.php

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

113

Re: Предложение к будущей версии :)

1) попробуй запустить composer install сделать

2) пока не полноценный установщик.
я на уже установленной копии делаю. предполагается что установщик тоже как то через composer будет
мжет через самораспаковывающийся phar или типа того который из браузера можно запустить тоже или из командной строки
могу просто дампы БД выложить
или можно взять от установленного форума с БД я не делал ничего

3) столкнулся с тем что если делать через композер расширения - выносить языковые файлы и темы и прочее - нельзя задать порядок инициализации.
так что придется использовать какойто класс-контейнер для возможности автозагрузки. pimple мне не нравится - чтоон пытается эмулировать массив.
тогда функцию service занести в класс PUNBB - там же и переменные сервисов и прочего хранить. чтобы глобалы вообще убрать.

Добавлено спустя 9 минут 11 секунд:

hcs пишет:

Не могу запустить, ругается на

require __DIR__ . '/vendor/pautoload.php';

в index.php

сейчас поправил. там временный загрузчик в репозитарий не добавился - сейчас есть.

Сайт Otto.Zukamoto

Поделиться

114

Re: Предложение к будущей версии :)

pimple мне не нравится - чтоон пытается эмулировать массив.


Pimple использует массив потому что ключ массива можно назвать - punbb.language.russian, а свойство объекта - нет.

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

115

Re: Предложение к будущей версии :)

punbb.language.russian
в данном случае получается все хранится в одном массиве и всегда придется использовать такой длинный путь

я пока реализую так что все сущности хранятся как объекты с полями чтобы можно было менять значения.
можно сохранить обект в переменной и обращатся по укороченному названию
https://github.com/rivetweb/punbb/blob/ … rvices.php
можно переписать на Pimple но надо ли? сам контейнер $container получится в глобальной переменной будет хранится?

Добавлено спустя 1 минуту 44 секунды:

Otto.Zukamoto пишет:

punbb.language.russian
в данном случае получается все хранится в одном массиве и всегда придется использовать такой длинный путь

я пока реализую так что все сущности хранятся как объекты с полями чтобы можно было менять значения.
можно сохранить обект в переменной и обращатся по укороченному названию
https://github.com/rivetweb/punbb/blob/ … rvices.php
можно переписать на Pimple но надо ли? сам контейнер $container получится в глобальной переменной будет хранится?

c выделением user какой то трабл - у меня не получилось вытащить. там как то завязано на cookie_login и еще где то инициализации размазаны.

Сайт Otto.Zukamoto

Поделиться

116

Re: Предложение к будущей версии :)

ок перепишу на Pimple.
я смотрю он и для хранения данных подходит?

$container['cookie_name'] = 'SESSION_ID';

Сайт Otto.Zukamoto

Поделиться

117

Re: Предложение к будущей версии :)

Посмотрел твою работу. Впечатлило.  У генератора кэша мне показалась некорректной структура папок, может вместо include/functions лучше что-то вроде include/cache_functions или cache_generators? Планируется использовать загрузку функций не только для кэша? Продолжаем изучение.

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

118

Re: Предложение к будущей версии :)

пока образовался перерыв из за нехватки времени.

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

я пересмотрел схему модульности

https://github.com/rivetweb/php-module/ … r/init.php
как загрузчик и хранилище модулей

будет более универсально

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

и подумываю сразу уж на php 7 ориентироватся.
пока скрипт превращается в полигон для экспериментов.

Сайт Otto.Zukamoto

Поделиться

119

Re: Предложение к будущей версии :)

рефакторить punbb - это конечно была самая моя тупая идея.

есть пара предложениий по текущей версии

https://github.com/punbb/punbb/issues/131
https://github.com/punbb/punbb/issues/133

Сайт Otto.Zukamoto

Поделиться

120

Re: Предложение к будущей версии :)

Рефакторить punbb это очень хорошая идея, как я и говорил ранее. Другое дело, что тотальное переписывание с сохранением совместимости ожидаемо провалилось, хотя безусловно много там полезных идей и решений.
По №131 вместо 1 include файла кеша всех хуков, мы получим 20 и больше include, часть из которых ещё к тому же будут загружать  пустышку.
Избавление от "eval и склеивания строк в рантайме" ради избавления от eval, по-моему не имеет смысла и будет компенсировано возросшим количеством дисковых операций. Особождение памяти это вообще сферический конь, мегабайтом больше, мегабайтом меньше,  их сейчас никто считает, узким местом это вроде никогда не было, хотя конечно чтобы так утверждать нужны какие-то результаты тестов. Какова практическая ценность изменения механизма хуков?

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

121

Re: Предложение к будущей версии :)

я ж написал  использование опкеша. там джойн строк на каждый хук и запрос.
евал веть в опкеш не ложится насколько я знаю

ладно тогда можно загрыть эту идею.

Добавлено спустя 4 минуты 59 секунд:

по поводу рефакторинга

PHPbb использует симфони и сколько лет переписывания а код там по прежнему практически тот же.
ну и какойтогда смысл smile
https://github.com/phpbb/phpbb/blob/mas … wforum.php

Добавлено спустя 6 минут 35 секунд:

с опкешом просто

include компилит код 1 раз и ложит в кеш
потом это равноценно в лучшем случае вызову функции

Добавлено спустя 7 минут 52 секунды:

вы принимаете пулреквесты в текущую ветку?
есть некоторые другие идеи по улучшению.

просто на уровне оптимизаций и фиксинг багов.

Сайт Otto.Zukamoto

Поделиться

122

Re: Предложение к будущей версии :)

Otto.Zukamoto пишет:

вы принимаете пулреквесты в текущую ветку?
есть некоторые другие идеи по улучшению.

просто на уровне оптимизаций и фиксинг багов.

Без проблем

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

123

Re: Предложение к будущей версии :)

Otto.Zukamoto пишет:

по поводу рефакторинга

PHPbb использует симфони и сколько лет переписывания а код там по прежнему практически тот же.
ну и какойтогда смысл smile

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

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

124

Re: Предложение к будущей версии :)

вопрос по пул реквестам - там можно из мастера прямо пулить
или надо создавать ветку на каждую фичу?

Сайт Otto.Zukamoto

Поделиться

125

Re: Предложение к будущей версии :)

Ветку то зачем, это ты у себя там локально можешь ветвить по своему усмотрению, а в мастер уже слитое отправлять, но естественно нужно как-то обосновать изменения

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться