Самопис для форума

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

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

(Отредактировано автором: 17 Декабря, 2014 - 12:02:28)

Теперь понятно, почему Composer использует json конфиги. Но в той же статье предоставлен хороший вариант с PHP конфигом + сериализацией. И всё же это спички.

Но не отточенным и не объезженным. И "слегка" головатым.

Проснись! Уже 2.0.1 вышел. Так что вполне стабилен.

тут больше не спор а попытка достучаться.
для чиво изначально была создана тема если подумать?
1 - исправить старые проблемы и решить вопрос с тормозами
2 - создать чтото свое-новое, собрать комюнити вместе

так вот и пытался достучаться до всех. делая свое с нуля но такоеже как у других только своими методами.. получите точно такоеже с дырами, костылями и тормозами. на sql.ru только за select * поотрубают руки нахрен. Т.е. пилите очередной аналог phpbb и подобные, итог будет такойже самый. тогда первый пункт вычеркиваем и забываем, просто балуемся.
по второму пункту.. чтобы создать чтото интересное и новое, нужно и думать по новому а не пилить все тоже самое. Простой пример.. кто изучает технологии и тендеции, как я писал выше, сейчас время разделения , и время облака и кластера. Но для этого продукт должен соответствовать критериям. Для примера, отделите базу и ресурсы друг от друга. Отдайте UI клиенут и только выдавайте ему данные по запросы тогоже json или io. Если юзвер нажал NEXT 10 то нафигаж дергать весь сервер целиком со всеми инициализациями и парсингами.. тотже HEADER и FOOTER каждый раз генерить и рендерить с парсингами, дергать базу ради меню и всего остального? Отделите одно от другого, раскидайте по шлюзам.. в случае нагрузки можно разделять и перенагружать узлы. т.е.сделайте все по уму раз пишете с нуля. Иначе теряется и 1 и 2 пункты.. получаем очередной тормоз и не пишем ничего нового, просто клон - тогда просто не вижу смысл всего происходящего.

Такой пример. Код абстрактен. Вьюха:

Bio man
Поддерживаю

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

-----
Just do it

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

(Отредактировано автором: 17 Декабря, 2014 - 13:06:57)

В Yii2 это тоже предусмотрено. Ещё одна плюшка в пользу Yii2. Но всё же форум не будет интернациональным, так что необходимость в i18n отпадает

Он ужасен. Из-за одной правки английской локализации перелопачивать все имеющиеся локализации?!

-----
PostgreSQL DBA

Мелкий
С одной стороны согласен. но если посмотреть со второй: то как часто происходит правка локализаций

имхо локализация должна вводиться уже тогда когда основная версия до конца проработана, но поддержка локализации конечно должна быть архитектурно предусмотрена
(Добавление)
если конечно того требует тз

-----
Just do it

Зачем перелопачивать? Поиск по папке локализаций и готово. Можно даже с автозаменой.

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

Этот "ужасный" подход используется в боготворимом вами линуксе и называется gettext

-----
self-banned