Обсуждение можем продолжать в этой же теме.
Все просьбы добавить кого-либо в контрибьюторы - к RomAndry.
Во всем остальном - обсуждаемо между всеми.
На момент публикации ссылки на репо, в этот самый репо добавлены еще не все ядерные сущности.
Однако общая картина уже должна прослеживаться.
Немногим позже добавлю больше примеров использования.
-------------------------------- -------------------------
Ниже идет текст который был написан до публикации ссылки на репозиторий с исходниками.
-------------------------------- -------------------------
esterio пишет:
я уже смотрел код твоей ЦМС там неплохое качество
Там страх и ненависть в Лас-Вегасе ))
К тому же - годичной давности.
esterio пишет:
да коментируй не коментируй все равно говнокод будет ))) шутка.
викладивай давай, а мы посмотрим. и еще здесь не заказчики сидят и думаю все понимаютчто наброскы не всегда отличаються височайшимкачеством
Кхмм... ))
Тем не менее - я прям щас не буду выкладывать.
Уже совсем скоро, стервятники вы мои )) накинетесь на свежатинку.
Критика всегда уместна, тем более - ваша.
С чего вдруг самопис то?
У меня есть готовая наработка форума.
Я её кстати слизывал с нашего родного.
Именно эту наработку я и портирую.
Реализована она в качестве отдельного модуля, кода там - кот наплакал.
Это таки жирный плюс - начинать не с нуля, кода мало, можно сразу начинать навешивать плюшки.
А сейчас я напишу что сделано к текущему моменту, а так же хочу прояснить некоторые архитектурные вопросы.
Естественно в основном все про ядерные компоненты.
Готово:
1) Все добавляемые компоненты комментируются и форматируются по PSR1 (гоняю кодснифера).
2) Предусмотрена возможность горизонтальногомасштабирования.
3) Предусмотрен отдельный поддомен для статики.
4) Предусмотрен отдельный поддомен для аттачей и аплоада.
5) Поддержка CLI-режима в виде:
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, обязательный мемкеш, выделенный сервер и пр. Двиг должен взлетать и на простом хостинге.
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
DeepVarvar пишет:
Там страх и ненависть в Лас-Вегасе ))
К тому же - годичной давности.
Собственно, эти два выражения есть одна и та же суть и закономерность нормального программиста.
DeepVarvar пишет:
2) Предусмотрена возможность горизонтального масштабирования.
Зачем делать то, что не нужно?
PHP архитектурно stateless, изолирован и масштабируется на любое число хостов.
session.save_handler в redis или memcache решают оставшуюся потребность в сессии силами самого php. И хоть тупой round-robin на балансере поставить.
И это не противоречит пожеланию работать и на шаредах - клиентский код об этом просто не знает.
Личное отношение - негативно. KISS, YAGNI. Нужно что-то машиночитаемое предоставить - добро пожаловать в api, часто являющееся лишь отражением внутреннего api.
DeepVarvar пишет:
Надо определиться с:
1) полный путь, только полный путь. Вообще без каких-то штатных альтернатив. Полное имя класса должно всегда однозначно указывать на конкретный файл без всякой магии "а давайте поищем где-нибудь и возьмём что найдём"
2) по-умолчанию - да. Поддержка кастомных роутов понадобится, но как исключение.
3) реплика СУБД?
4) что подразумеваем под моделью? С точки зрения MVC это то, что делает всё, не отвлекаясь только на отображение и контроллеры - вся бизнес-логика именно в моделях. Или то, что под этим именем часто имеют в виду фреймворки - т.е. тонкие модели со всякими activerecord?
5) native php
6) hmvc? Полезность-бесполезность зависит от конкретной реализации.
----- PostgreSQL DBA
DeepVarvar
Отправлено: 13 Декабря, 2014 - 18:23:22
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
Мелкий пишет:
Зачем делать то, что не нужно?
В кратце можно про уазанный подход? Я то имел ввиду просто стики-кукис средствами фронт-сервера.
Мелкий пишет:
Своё или что-то известное?
Свое, там пара строк - регулярка отрезает комментарии по /*...*/ и //...EOL и стандартный json_decode в объект конфига.
То же самое для JSON и txt, а html требует подключенного лейаута.
Мелкий пишет:
1) полный путь, только полный путь.
Принято, даже легче будет реализация.
Мелкий пишет:
2) по-умолчанию - да. Поддержка кастомных роутов понадобится, но как исключение.
Хм, тогда всеравно сразу впиливать кастомную возможность.
Мелкий пишет:
3) реплика СУБД?
Да. Но больше интересует в самом приложении, как удобнее обращаться будет и все такое.
Мелкий пишет:
т.е. тонкие модели со всякими activerecord?
Да, и сейчас их нет совсем.
Мелкий пишет:
6) hmvc?
Нет, просто две попытки рендера, если первая не удалась, то показывает страницу ошибки, если кто-то на странице ошибки тоже бросает исключение, то склеиваем ласты.
Покинул форум
Сообщений всего: 5025
Дата рег-ции: Нояб. 2012 Откуда: Украина, Львов
Помог: 127 раз(а)
DeepVarvar пишет:
1) Правилами автолоада (сейчас, либо без неймспейса через include_path, либо с неймспейсом ака полный путь от корня ФС).
2) Роутингом (я склоняюсь к полностью автоматическому роуту, без создания правил, но это обсуждаемо).
3) Репликациями (да, они нужны, просто хотел обсудить интерфейс и все такое).
4) Моделями (в моем велике их не было, ну во всяком случае в классическом виде).
5) Шаблонизатор (я против каких либо шаблонизаторов).
6) Генерация контента. Тут нужно объяснить. Дело в том, что в текущей реализации рендера можно совершенно легко дернуть какой-либо компонент прямо в шаблоне, и, даже если этот компонент бросает исключение - ничего страшного, система поймет, очистит вывод и нарисует страницу ошибки. В кратце - у меня есть т.н. "render tries" т.е. попытки отрендерится. Суть - устраивает или нет такой подход? Выкинув этот подход, еще уменьшим потребление ресурсов и скорость генерации.
1. только явный абсолютный путь
2. правила могут пригодиться. но и на том ездить можно
4. ну какой-то базовый класс надеюсь есть
5. только натив
7. в дев режиме круто, но продакшн випилить (отключить)
DeepVarvar
Отправлено: 13 Декабря, 2014 - 18:49:07
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
esterio пишет:
4. ну какой-то базовый класс надеюсь есть
Нету )) (Добавление)
esterio пишет:
в дев режиме круто, но продакшн випилить (отключить)
Не совсем в тютельку. Дело в том что в независимости от режима система логгирует все очень подробно в пплоть до стектрейса. Единственное что, в продакшн-режиме пользак увидит 404, а в дебаге будет все, включая стектрейс. Т.е. даже если жопка случилась в продакшне, в логах это будет записано как будто был дебаг-режим.
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
DeepVarvar пишет:
В кратце можно про уазанный подход? Я то имел ввиду просто стики-кукис средствами фронт-сервера.
PHP изначально изолирует каждый поступающий запрос от других. Не надо привязывать выполнение всех запросов конкретного пользователя к конкретному серверу, это ничего не изменит в лучшую сторону, не решит никаких принципиальных проблем, но зато заметно ухудшит балансировку нагрузки.
Запрос должен уметь обработать любой сервер кластера. Вопросы с разделяемыми ресурсами между серверами приложения:
- БД. Без вопросов, хост в конфиге приложения поменять. (но начинаются эпичные проблемы, если не справляется субд и надо масштабировать её. Как говорит один сильный DBA: если можете не масштабировать субд - не делайте этого. Если уж весь stackoverflow живёт на двух серверах БД - то мы уж подавно уместимся в один http://habrahabr[dot]ru/post/203406/ )
- Нужны сессии. Вопрос решается переносом хранения сессий из файловой системы конкретного сервера в пул memcache или redis вполне себе штатными средствами php - и всё, больше не нужно отслеживать, где был пользователь до того и куда этот запрос надо отправлять. Любая машина сможет обработать запрос этой сессии.
DeepVarvar пишет:
Да. Но больше интересует в самом приложении, как удобнее обращаться будет и все такое.
В сущности, ответил выше.
Предусмотреть, конечно, можно. toplevel API - "дай мне объект dbapi для записи" и "дай мне dbapi для чтения", возвращающие объекты одно и того же класса, но подключённые к разным хостам БД, конкретная реализация под капотом изменяется потом под конкретные нужды. При разработке помнить о, обычно небольшом, лаге между мастером и слейвом. Самым популярным вызовом будет dbapi для чтения - фактически весь рендер страницы. И только когда надо что-то записать - дёргаем коннект на запись. Просто, надёжно.
DeepVarvar пишет:
Да, и сейчас их нет совсем.
И это замечательно. Меня они откровенно раздражают.
DeepVarvar пишет:
Нет, просто две попытки рендера, если первая не удалась, то показывает страницу ошибки, если кто-то на странице ошибки тоже бросает исключение, то склеиваем ласты.
Эмм, а есть другие варианты?
Вроде бы так всегда и делается.
----- PostgreSQL DBA
DeepVarvar
Отправлено: 13 Декабря, 2014 - 19:40:49
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
Мелкий пишет:
Эмм, а есть другие варианты?
Как минимум могу легко увеличить кол-во попыток, поменяв циферку.
А вообще - можно совсем выкинуть эти а-ля GOTO, ведь шаблон это уже только вывод, т.е. в шаблоне сделать только вывод набитых данных и точка.
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
DeepVarvar, погоди ты, дай народу хотя бы один вечер. Я, например, только сейчас до компа добрался впервые с прошлого вечера.
----- PostgreSQL DBA
esterio
Отправлено: 15 Декабря, 2014 - 17:50:20
Активный участник
Покинул форум
Сообщений всего: 5025
Дата рег-ции: Нояб. 2012 Откуда: Украина, Львов
Помог: 127 раз(а)
да и правда погоди. я только ближе к ночи доберусь (Добавление)
ну и еще нужно определиться кто чем занимаеться.
и еще со временем. я не могу обещать приделять более 6-9 часов в неделю (особенно перед НГ)
DeepVarvar
Отправлено: 15 Декабря, 2014 - 18:07:08
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
Ну а шо тут думать кто чем?
Кто на жс петрит по полной или душа лежит - те идут на фронт.
Кто в бекенде силен или нравится - тот бекенд.
По сути - любой из участвующих может указать на касяк хоть на беке, хоть на фронте.
Затрачиваемое время?
Никто не декларирует, вот у меня пока есть немножко, я запиливаю.
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.