Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Самопис для форума
Форумы портала PHP.SU » Разное » Колонка администратора » Самопис для форума

Страниц (14): [1] 2 3 4 5 6 7 8 9 ... » В конец
 

1. DeepVarvar - 13 Декабря, 2014 - 16:16:38 - перейти к сообщению
Думаю что уже пора бы и выложить

Вот исходники: https://github[dot]com/Romandry/phpsu

Обсуждение можем продолжать в этой же теме.
Все просьбы добавить кого-либо в контрибьюторы - к RomAndry.
Во всем остальном - обсуждаемо между всеми.

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


-------------------------------- -------------------------
Ниже идет текст который был написан до публикации ссылки на репозиторий с исходниками.
-------------------------------- -------------------------

esterio пишет:
я уже смотрел код твоей ЦМС там неплохое качество

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


Кхмм... ))
Тем не менее - я прям щас не буду выкладывать.
Уже совсем скоро, стервятники вы мои )) накинетесь на свежатинку.
Критика всегда уместна, тем более - ваша.

С чего вдруг самопис то?

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

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

Готово:

1) Все добавляемые компоненты комментируются и форматируются по PSR1 (гоняю кодснифера).
2) Предусмотрена возможность горизонтального масштабирования.
3) Предусмотрен отдельный поддомен для статики.
4) Предусмотрен отдельный поддомен для аттачей и аплоада.
5) Поддержка CLI-режима в виде:
CODE (bash):
скопировать код в буфер обмена
  1. ~$ /usr/bin/php /path/do/htdocs/index.php --request /cronjobs/jobN?par1=1&par2=2

6) Конфиги в JSON с возможностью комментирования.
7) Логгирование любых действий, складывает в файлы, ротирует автоматом, формат - JSON.
8) Сессионный Storage.
9) Контексты (представления) вывода меняемые на лету - html, xml, json, txt.

Надо определиться с:

1) Правилами автолоада (сейчас, либо без неймспейса через include_path, либо с неймспейсом ака полный путь от корня ФС).
2) Роутингом (я склоняюсь к полностью автоматическому роуту, без создания правил, но это обсуждаемо).
3) Репликациями (да, они нужны, просто хотел обсудить интерфейс и все такое).
4) Моделями (в моем велике их не было, ну во всяком случае в классическом виде).
5) Шаблонизатор (я против каких либо шаблонизаторов).
6) Генерация контента. Тут нужно объяснить. Дело в том, что в текущей реализации рендера можно совершенно легко дернуть какой-либо компонент прямо в шаблоне, и, даже если этот компонент бросает исключение - ничего страшного, система поймет, очистит вывод и нарисует страницу ошибки. В кратце - у меня есть т.н. "render tries" т.е. попытки отрендерится. Суть - устраивает или нет такой подход? Выкинув этот подход, еще уменьшим потребление ресурсов и скорость генерации.

Личный (и вообще) концепт:

1) Это совсем не тот движок, который Deep-CMS. Да, многие вещи взяты (скопипащщены) отуда.
2) Ненавижу ООП ради ООП, ненавижу многоуровневое наследование, использую все эти ваши паттерны только там, где уместно, а не везде. Именно поэтому архитектура, котрую вы увидете не будет классической, однако она проста как два пальца.
3) Первичный критерий - скорость работы и нетребовательность к ресурсам. Пункт номер два этому очень способствует.
4) Возможность в будущем предоставлять готовое решение (e.g. PhpSu-Engine) для обычного потребителя - поставил двиг форума, настроил, пользуешься. Именно поэтому не нужно разгоняться на всякие пхп 5.5, обязательный мемкеш, выделенный сервер и пр. Двиг должен взлетать и на простом хостинге.
2. Viper - 13 Декабря, 2014 - 17:10:04 - перейти к сообщению
5. Тоже против шаблонизаторов.
6. Выкинуть.
3. Мелкий - 13 Декабря, 2014 - 18:06:59 - перейти к сообщению
DeepVarvar пишет:
Там страх и ненависть в Лас-Вегасе ))
К тому же - годичной давности.

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

DeepVarvar пишет:
2) Предусмотрена возможность горизонтального масштабирования.

Зачем делать то, что не нужно?
PHP архитектурно stateless, изолирован и масштабируется на любое число хостов.
session.save_handler в redis или memcache решают оставшуюся потребность в сессии силами самого php. И хоть тупой round-robin на балансере поставить.
И это не противоречит пожеланию работать и на шаредах - клиентский код об этом просто не знает.

DeepVarvar пишет:
6) Конфиги в JSON с возможностью комментирования.

Своё или что-то известное?

DeepVarvar пишет:
8) Сессионный Storage.

Подробнее, пожалуйста. Это о чём?

DeepVarvar пишет:
9) Контексты (представления) вывода меняемые на лету - html, xml, json, txt.

Личное отношение - негативно. KISS, YAGNI. Нужно что-то машиночитаемое предоставить - добро пожаловать в api, часто являющееся лишь отражением внутреннего api.

DeepVarvar пишет:
Надо определиться с:

1) полный путь, только полный путь. Вообще без каких-то штатных альтернатив. Полное имя класса должно всегда однозначно указывать на конкретный файл без всякой магии "а давайте поищем где-нибудь и возьмём что найдём"
2) по-умолчанию - да. Поддержка кастомных роутов понадобится, но как исключение.
3) реплика СУБД?
4) что подразумеваем под моделью? С точки зрения MVC это то, что делает всё, не отвлекаясь только на отображение и контроллеры - вся бизнес-логика именно в моделях. Или то, что под этим именем часто имеют в виду фреймворки - т.е. тонкие модели со всякими activerecord?
5) native php
6) hmvc? Полезность-бесполезность зависит от конкретной реализации.
4. DeepVarvar - 13 Декабря, 2014 - 18:23:22 - перейти к сообщению
Мелкий пишет:
Зачем делать то, что не нужно?
В кратце можно про уазанный подход? Я то имел ввиду просто стики-кукис средствами фронт-сервера.
Мелкий пишет:
Своё или что-то известное?
Свое, там пара строк - регулярка отрезает комментарии по /*...*/ и //...EOL и стандартный json_decode в объект конфига.
Мелкий пишет:
Подробнее, пожалуйста. Это о чём?
Обертка над $_SESSION.
Мелкий пишет:
KISS, YAGNI
Нативный пример генерации карты сайта:
PHP:
скопировать код в буфер обмена
  1.  
  2.         View::setOutputContext('xml');
  3.         View::lockOutputContext();
  4.         View::assign('urlset', query('SELECT lastmod, changefreq, loc, priority'));
  5.         View::setXSDSchema(
  6.             array(
  7.                 'name'       => 'urlset',
  8.                 'attributes' => array(
  9.                     array(
  10.                         'name'  => 'xmlns',
  11.                         'value' => 'http://www.sitemaps.org/schemas/sitemap/0.9'
  12.                     )
  13.                 ),
  14.                 'children' => array(
  15.                     array(
  16.                         'name'     => 'url',
  17.                         'children' => array(
  18.                             array('name' => 'lastmod'),
  19.                             array('name' => 'changefreq'),
  20.                             array('name' => 'loc'),
  21.                             array('name' => 'priority')
  22.                         )
  23.                     )
  24.                 )
  25.             )
  26.         );
То же самое для JSON и txt, а html требует подключенного лейаута.
Мелкий пишет:
1) полный путь, только полный путь.
Принято, даже легче будет реализация.
Мелкий пишет:
2) по-умолчанию - да. Поддержка кастомных роутов понадобится, но как исключение.
Хм, тогда всеравно сразу впиливать кастомную возможность.
Мелкий пишет:
3) реплика СУБД?
Да. Но больше интересует в самом приложении, как удобнее обращаться будет и все такое.
Мелкий пишет:
т.е. тонкие модели со всякими activerecord?
Да, и сейчас их нет совсем.
Мелкий пишет:
6) hmvc?
Нет, просто две попытки рендера, если первая не удалась, то показывает страницу ошибки, если кто-то на странице ошибки тоже бросает исключение, то склеиваем ласты.
5. esterio - 13 Декабря, 2014 - 18:46:06 - перейти к сообщению
DeepVarvar пишет:
1) Правилами автолоада (сейчас, либо без неймспейса через include_path, либо с неймспейсом ака полный путь от корня ФС).
2) Роутингом (я склоняюсь к полностью автоматическому роуту, без создания правил, но это обсуждаемо).
3) Репликациями (да, они нужны, просто хотел обсудить интерфейс и все такое).
4) Моделями (в моем велике их не было, ну во всяком случае в классическом виде).
5) Шаблонизатор (я против каких либо шаблонизаторов).
6) Генерация контента. Тут нужно объяснить. Дело в том, что в текущей реализации рендера можно совершенно легко дернуть какой-либо компонент прямо в шаблоне, и, даже если этот компонент бросает исключение - ничего страшного, система поймет, очистит вывод и нарисует страницу ошибки. В кратце - у меня есть т.н. "render tries" т.е. попытки отрендерится. Суть - устраивает или нет такой подход? Выкинув этот подход, еще уменьшим потребление ресурсов и скорость генерации.

1. только явный абсолютный путь
2. правила могут пригодиться. но и на том ездить можно
4. ну какой-то базовый класс надеюсь есть
5. только натив
7. в дев режиме круто, но продакшн випилить (отключить)
6. DeepVarvar - 13 Декабря, 2014 - 18:49:07 - перейти к сообщению
esterio пишет:
4. ну какой-то базовый класс надеюсь есть
Нету ))
(Добавление)
esterio пишет:
в дев режиме круто, но продакшн випилить (отключить)
Не совсем в тютельку. Дело в том что в независимости от режима система логгирует все очень подробно в пплоть до стектрейса. Единственное что, в продакшн-режиме пользак увидит 404, а в дебаге будет все, включая стектрейс. Т.е. даже если жопка случилась в продакшне, в логах это будет записано как будто был дебаг-режим.
7. esterio - 13 Декабря, 2014 - 18:56:07 - перейти к сообщению

DeepVarvar пишет:
Нету ))

сделаем )))

(Добавление)
DeepVarvar пишет:
Единственное что, в продакшн-режиме пользак увидит 404

може 500? 404 не существуещая шибка же. а у нас ога залогирована
8. DeepVarvar - 13 Декабря, 2014 - 19:07:45 - перейти к сообщению
esterio пишет:
може 500?
Ну не знаю, поменять - одну строчку исправить, если понадобится.
9. Мелкий - 13 Декабря, 2014 - 19:19:44 - перейти к сообщению
DeepVarvar пишет:
В кратце можно про уазанный подход? Я то имел ввиду просто стики-кукис средствами фронт-сервера.

PHP изначально изолирует каждый поступающий запрос от других. Не надо привязывать выполнение всех запросов конкретного пользователя к конкретному серверу, это ничего не изменит в лучшую сторону, не решит никаких принципиальных проблем, но зато заметно ухудшит балансировку нагрузки.
Запрос должен уметь обработать любой сервер кластера. Вопросы с разделяемыми ресурсами между серверами приложения:
- БД. Без вопросов, хост в конфиге приложения поменять. (но начинаются эпичные проблемы, если не справляется субд и надо масштабировать её. Как говорит один сильный DBA: если можете не масштабировать субд - не делайте этого. Если уж весь stackoverflow живёт на двух серверах БД - то мы уж подавно уместимся в один http://habrahabr[dot]ru/post/203406/ )
- Нужны сессии. Вопрос решается переносом хранения сессий из файловой системы конкретного сервера в пул memcache или redis вполне себе штатными средствами php - и всё, больше не нужно отслеживать, где был пользователь до того и куда этот запрос надо отправлять. Любая машина сможет обработать запрос этой сессии.

DeepVarvar пишет:
Да. Но больше интересует в самом приложении, как удобнее обращаться будет и все такое.

В сущности, ответил выше.
Предусмотреть, конечно, можно. toplevel API - "дай мне объект dbapi для записи" и "дай мне dbapi для чтения", возвращающие объекты одно и того же класса, но подключённые к разным хостам БД, конкретная реализация под капотом изменяется потом под конкретные нужды. При разработке помнить о, обычно небольшом, лаге между мастером и слейвом. Самым популярным вызовом будет dbapi для чтения - фактически весь рендер страницы. И только когда надо что-то записать - дёргаем коннект на запись. Просто, надёжно.

DeepVarvar пишет:
Да, и сейчас их нет совсем.

И это замечательно. Меня они откровенно раздражают.

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

Эмм, а есть другие варианты?
Вроде бы так всегда и делается.
10. DeepVarvar - 13 Декабря, 2014 - 19:40:49 - перейти к сообщению
Мелкий пишет:
Эмм, а есть другие варианты?
Как минимум могу легко увеличить кол-во попыток, поменяв циферку.
А вообще - можно совсем выкинуть эти а-ля GOTO, ведь шаблон это уже только вывод, т.е. в шаблоне сделать только вывод набитых данных и точка.
11. DeepVarvar - 15 Декабря, 2014 - 01:44:53 - перейти к сообщению
Обновил первое сообщение топика!
Там ссылка на исходнки в репо!
12. DeepVarvar - 15 Декабря, 2014 - 14:41:35 - перейти к сообщению
А что, всех все устраивает?
13. Мелкий - 15 Декабря, 2014 - 16:17:27 - перейти к сообщению
DeepVarvar, погоди ты, дай народу хотя бы один вечер. Я, например, только сейчас до компа добрался впервые с прошлого вечера.
14. esterio - 15 Декабря, 2014 - 17:50:20 - перейти к сообщению
да и правда погоди. я только ближе к ночи доберусь
(Добавление)
ну и еще нужно определиться кто чем занимаеться.
и еще со временем. я не могу обещать приделять более 6-9 часов в неделю (особенно перед НГ)
15. DeepVarvar - 15 Декабря, 2014 - 18:07:08 - перейти к сообщению
Ну а шо тут думать кто чем?
Кто на жс петрит по полной или душа лежит - те идут на фронт.
Кто в бекенде силен или нравится - тот бекенд.
По сути - любой из участвующих может указать на касяк хоть на беке, хоть на фронте.

Затрачиваемое время?
Никто не декларирует, вот у меня пока есть немножко, я запиливаю.

 

Powered by ExBB FM 1.0 RC1