Милторг перелогиньтесь )))---------- Добавлено 08.11.2019 в 21:05 ----------ArbNet, вообще, скепсис, это нормальное состояние. Просто 95% проектов загибается, но вдруг вам хватит сил и прилежания дотянуть до рабочего проекта и попасть в те самые 5%
Если будет так, то мы будем только за.
Dreammaker, просто обсуждение разбилось на две ветки )))
_SP_, Вы просто, наверное, никогда не работали с подобными вещами.
Дело в том, что на таких огромных сайтах, как озон, над проектом работает даже не одна команда разработчиков а таких команд может быть 5 или даже больше.
Например вывод тушки могут писать одни, кабинет другие, систему авторизации третьи и т.д. причем часто эти группы даже не пересекаются. Одни люди уходят, другие приходят. Текучка кадров опять же.
Многим проще написать своё, чем ковыряться в чужом коде , остаются хвосты, брошенные ветки разработки, эксперименты,
Если проект жирный и старый (коим является озон), то этого мусора в коде будет столько, что просто сложно представить. А чтоб начать рефакторинг нужно чтобы произошло что-то экстраординарное, потому, что любой нормальный программист живет по принципу "работает - не трожь"
_SP_, когда пишется какой-то новый функционал, то стили к нему собираются в отдельном файлике. за 8 лет разработки он зело так разожрался.
Понимаете. тут проблема в том, что есть магазин с аж 15 кб стилями, а есть Озон. Так вот. наш сайт, это озон - но только в другой области.---------- Добавлено 08.11.2019 в 13:56 ----------
они не генерятся для каждой страницы. практически все стили сквозняковые. То-есть генерятся один раз и используются на всем сайте. И есть надстройки по разделам, которые много жрут, но редко используются.
edogs, Упоминалось, но ЮМИ сами ушли от этого в последних релизах. сосредоточившись на обычном php, в угоду скорости
Это как генерировать. (в смысле методика)
если на лету, то конечно да, результат будет печальным. Очень печальным.
Мы же один раз, в релиз, собираем цсс-хи и кладем их в кэш, после чего из кэша и берем.
стили разбиты по назначению:
1. Ядро /базовая сетка/ - они тянутся прямо в голову
2. Базовые стили, которые не влияют на стартовый рендеринг, но использование которых необходимо. они идут сквозняком через весь сайт.
3. Всякий шлак, который применяется время от времени, но его нельзя выгрузить в специфические стили раздела. (например стили для отдельных блоков, которые редакторы могут включать/выключать по желанию/необходимости )
4. специфические стили. (например обстил раздела новости/статьи или раздела с законами/нормами/правилами )
---
1. как я сказал грузится в голове (один раз, потом страница тоже кэшируется)
2. грузится обычным способом.
3 и 4 вынесены вниз документа
подобная структура создана для того, чтобы увеличить скорость загрузки и для получения большего кол-ва "попугаев" в google pagespeed
Если всё собрать в один файл, то гугл снижает рейтинг из-за большого кол-ва неиспользуемых стилей, загружаемых в начале. (сайты огромны, обстил за годы разработки набрался очень тяжелый, рефакторить в ближайшие года 3-4 тоже вряд ли кто будет) Вот поэтому и пошли путем сборки боевых цсс-ок из пары сотен мелких кусочков перед релизом
О майн Гот!
Sly32, корочки нужны, когда потенциальный джун только из института выписался. (и то, скорее можно тестовое задание получить в стиле "hello world" ) После. разумеется, смотрят только на опыт
ArbNet, А вам не кажется, что "стандартизированный" HTML куда проще в изучении и запоминании, чем "гибкий" XML
и еще почему-то мне кажется, что загрузть новость в шаблоне как
<?= $this->widget->place('module/conroller/method', $params) ?> или же используя smarty/Fenom синтаксис гораздо проще и дешевле в плане производительности, чем xslt (ведь по своей сути, ваш движок, это частный случай XSLT шаблонизатора, который, как известно, использовался как основной в таких цмс-инах как umi-cms и amiro-cms и по-сути является (вернее являлся) тормозом в развитии этих систем )---------- Добавлено 06.11.2019 в 16:53 ----------
Считать их начинаешь, когда входной документ мегабайт на 100 )))
вот там уже прям хорошо так считаешь
может мне кто-нибудь объяснит, зачем нужен в данном случае XML?
только потеря машинного времени на перегонку данных тудой-сюдой.
ведь сами по себе xml парсеры мягко говоря производительностью не отличаются
а ведь помимо МVC есть еще HMVC, только тсс.. Надо дождаться того момента, когда тс сам придет к этому, наскакавшись при этом по детским граблям.
