вадяв приведённом шаблоне имеется раскраска текста. Это будет если для написания такого шаблона использовать специализированный редактор.
Это общераспространенная практика IDE поддерживать шаблоны. IntelliJ IDEA умеет все наиболее популярные в Java.
Например поддержка Velocity была уже лет 15 назад в популярном на то время HTML дизайнере (имя забыл).

вадяЕсли этот шаблон поместить в код java – эта раскраска пропадёт
Если на ламборджини вылить ушат помоев, то будет вонять. Вывод - машина говно. Что значит "поместить шаблон в код Java"? Кроме тебя в литералы никто никакой логики не пишет уже лет 20. Всё только борятся с таким. Например до сих нужно свойства в JPA/Hibernate в литералах писать. Это плохо.

вадяЕсть вариант — подготавливаем шаблон в отдельном редакторе с раскраской и переносим в код java -это куча действий, но только один раз, при создании, при исправлении — мало кто захочет этот путь повторять.
Няня, я у них поел. Вопрос остаётся открытым - зачем шаблон в Java коде, а не в ресурсах проекта.

вадяХраним шаблон в отдельном файле — редактируем спецредактором — наглядность , раскрашеность. Что с ним делать?

То же что и все. Редактируем в IntelliJ IDEA.

вадяВ коде, где нужно его применить читаем файл. Файл текстовый прочитаем в StringBuilder, начнем менять «спецвставки» на нужные, т. е. начнём работать со строками, работа со строками, даже StringBuilder (поиск,вставка, замена) операция очень не быстрая — огромная потеря времени, если учесть что такой шаблон будет вызван 500+ раз… Пагинация сокращает до 50+ раз, но в любом случае необходим вариант полного отображения данных, т. е. вызов 500+ раз.
Блин. Что за бред. Любой шаблонизатор идёт с API. Загрузить шаблон. Скормить ему данныее. Получить результат. 3 простых шага - три метода.

вадяЕсть вариант использовать Singleton загрузить этот файл один раз, в рантайме при старте вызвать компилятор , сформировать из этого шаблона класс, скомпилировать класс , загрузить его и вызывать… Оно того стоит? А если таких шаблонов по 5+ на каждую страницу?
Это всё за тебя делает библиотека. Что за цифры с потолка. 500, 5? В любом случае говнокода будет меньше.

вадяПусть будет отдельный файл/ы. Первоначально он обработан/ы в Singleton. Простому пользователю приспичило его править — т. е. мы даём права «простому пользователю» на доступ в папку сервера?
Ты зачем приплетаешь вопросы к теме не относящиеся. У тебя простые пользователи и Java код на сервере правят? Или что? Уже давно практика показала что пользователям нельзя давать ничего редактировать, если ты не CMS - то есть целенаправленный редактор.

вадяХорошо, не «простой пользователь» - а программист, он правит шаблон. Значит в проекте должен появиться механизм отслеживающий изменения версий шаблонов, что бы при изменении подхватить и скомпилировать. Оно того стоит?
Velocity умеет. JSP умеет. А ты Java код тоже на горячуе меняешь и сразу через JRebel публикуешь на сервер?

вадяБерём вариант текстовая строка в коде. Закрываем глаза на неудобство связанное с не раскрашенным текстом, используем предкомпилятор, который перед компиляцией сделает нужное. Ну будет работать быстро? Возможно, не известно что сгенерирует предкомпилятор… Есть выйгрыш? В чем? В читаемости? Маловероятный.
Очень субъективное ничем не обоснованое утверждение. Да, шаблон отдельно, код отдельно. Править удобнее когда всё отдельно, а не намешено в кучу, потому что в когда у тебя всё вперемешку и надо вдруг поменять layout HTML страницы, то тебе не только твой HTML нужно менять, но и кучу говнокода, чтобы склеить его в другом порядке. А с шаблонами такой проблемы нет.

вадяВ отладке? Если в чистом варианте ide сразу показывает все описки синтаксисе, то это же мы сможем понять только при запуске компиляции при работе предкомпилятора. Это увеличение времени разработки , да и при изменении/правки — тоже не мало времени уйдет. Вместо того чтоб исправлять ошибки при наборе — многократно запускать компиляцию. Опять таки «простой пользователь» не при делах.
Какой ещё "предкомпилятор". Ты столько всего мешаешь в одну кучу, что обозначить одну проблему не возможно.
Ты всё ещё забываешь, что железо стоит на много дешевле работы программиста. Тебе, как программисту, конечно же, выгодно плодить говнокод, чтобы потом долго и упорно его поддерживать. Но бизнесу это не выгодно. Ему выгодно купить железку и запускать на ней простой код, который может быть на пару процентов и медленее твоего (что ещё нужно доказать).

вадяАргумент — простой пользователь может изменять шаблон.

Не аргумент. Либо мы пишем CMS, либо простой пользователь не может. Без вариантов.

вадяДа и «простой пользователь» который, который будет разбираться в sql коде и коде java - это уже программист.

Всё верно. Одно только не могу понять. У тебя "простые пользователи" конкатенацию правят? Если нет, то к чему вообще этот аргумент?

вадяЕсли я что-то пропустил — прошу разъяснить.
Это не критика использования шаблонов, это попытка разобраться.
Классы. Абстракные слои. MVC. Микросервисы. Уже десятки лет индустрия борется за то чтобы разделять всё что можно разделить. И причина на то одна единственная - инкапсуляция. Строгий юнит, имеющий один стиль и одну задачу просто редактировать.

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

Petro123Во какой у тебя спитч без абзацев, такой и код со склейкой строк.
Может там были абзацы, а говнопарсер съел? Лучше выделять их, пустой строкой, а не отступом.
И я бы попросил вопросы писать в конце абзаца отдельно. Трудно их выуживать в середине текста, когда текста много.

вадяно это не повод говорить что это говнокод.
Мне больно представить как с вашим не говнокодом можно решать задачи рефакторинга HTML и редизайна сайта.
Особенно если HTML дизайнер тоже кодер так себе. В то время как в шаблоне вы можете взять любой говно-html и просто добавить ссылки на объекты и циклы. То с литералами придётся весь говнокод вставлять в строки и мучительно экранировать кавычки.

Ну, или вот навигацию взять. Как ты из тэга в css класс переходишь? А в javascript функцию?

вадяразжуй для меня этот вопрос, я не очень понял его
В IntelliJ IDEA. Я нажимаю Ctrl+B или Сtrl+Mouse1 на имени класса в теге:


И попадаю в CSS файл где у меня эти классы описаны. Работает для кучи разных шаблонов от JSP до Angular.
Ты как это решаешь? Копируешь имя в буфер - идешь в каталог с css и делаешь поиск по всем файлам?
Даже копирование в буфер в будет мучением. Умный выбор, ведь, не работает, если вдруг IDEA не догадалась что у тебя HTML в строках.

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


При этом работает разбиение на строки



И я даже могу обернуть перенесенный div в другой тег одним хоткеем.

Не знаю будет ли работать со StringBuilder-ом. С другой стороны, он нужнен только в циклах. В твоём чудокоде можно было бы и + использовать без потери производительности.

вадяи там не много css классов. и для меня такой проблемы не существует
Ну, вот каждый разговор с тобой к этому и сводится. Работаю один, мой код никто не ковыряет, чужой код сам не ковыряю, массштабы проекта "написал сам". И почему-то свой субъективный опыт программиста-одиночки ты считаешь единственно верным и экстраполируемым на проект любого масштаба.

Утрируя: если ты пишешь крестики-нолики то и впаривать тебе абстрактные слои не обязательно. Но и говорить, что у меня в крестиках-ноликах используется копи-паста и всё работает, ребзя, не ругайте копи-пасту. Тоже не стоит.

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

вадяэто ж во сколько раз всё медленнее будет? даже если шаблон из базы вытащить...
Померяй и удиви нас. А то всё у тебя субъективно медленне, чиста по личным предположениям.