Блог платформы

Скрипты - один из самых распространенных способов сделать приложение более гибким, с возможностью поправить что-то прямо на ходу. Конечно же, у этого подхода есть и недостатки, нужно всегда помнить про баланс между гибкостью и управляемостью. Но в этой статье мы не будем рассуждать “в общем” по поводу плюсов и минусов использования скриптов, мы рассмотрим практические способы реализации этого подхода, а также представим библиотеку, которая предоставляет удобную инфраструктуру для добавления скриптов в приложения, написанные на Spring Framework.

Как известно, HTTP 1.1 - это текстовой протокол передачи данных. HTTP сообщения закодированы, используя ISO-8859-1 (которую условно можно считать расширенной версией ASCII, содержащей умляуты, диакритику и другие символы, используемые в западноевропейских языках). При этом в теле сообщений можно использовать другую кодировку, которая должна быть обозначена в заголовке "Content-Type". Но что делать, если нам необходимо задать non-ASCII символы не в теле сообщения, а в самих заголовках? Наверное, самый распространенный кейс - это проставление имени файла в "Content-Disposition" заголовке. Это, казалось бы, довольно распространенная задача, но ее реализация не так очевидна.

TL;DR: Используйте кодировку, описанную в RFC 6266, для "Content-Disposition" и преобразуйте текст в латиницу (транслит) в остальных случаях.

Прошло уже целых полгода с того дня, как мы запустили Marketplace на нашем англоязычном сайте и чуть больше месяца со времени запуска каталога компонентов на русском. За это время в развитии каталога участвовали не только члены нашей команды, но и сообщество CUBA, и мы рассчитываем, что сможем продолжать развитие наших продуктов и сервисов в том же темпе.

Вам знакомо то чувство, когда обновление того или иного фреймворка на давнем и стабильном проекте взрывает код и превращает его в красно-перечеркнутое месиво? Будучи разработчиками платформы CUBA нам до боли это знакомо. Так за время существования платформы, она поменяла под собой 3 ORM-а, 3 мажорных версии Vaadin, не говоря уже о Spring Framework. При этом, одной из задач, решаемых платформой, является именно сохранение стабильного API, чтобы наши пользователи не страдали от выше обозначенной проблемы и мигрировали на последние версии всех используемых в платформе библиотек. В этом выступлении мы делимся своим опытом построения API, а также приемами, которые позволяют нам решать проблемы с переездом решений на базе CUBA на up-to-date стек.