разве это не просто сайт издательства

Эм... ещё чуууть-чуть оффтопика. Там ведь можно спокойно читать эту книгу, разве нет?

Эм... ещё чуууть-чуть оффтопика. Там ведь можно спокойно читать эту книгу, разве нет?

Там можно её спокойно купить

Эм... ещё чуууть-чуть оффтопика. Там ведь можно спокойно читать эту книгу, разве нет?

да, но я так понял с ограничениями

Всё, разобрался. Хитрый сайт, оказывается, делает вид, что можно читать бесплатно, а со второй главы начинает "шифровать" часть текста. А то я никак не мог понять как можно пиратить бесплатное.

разве это не просто сайт издательства

А. Ну значит и их накрыло.

А кто какие варианты чекстайла сейчас использует?

И как их дружите с джавовыми, если проект смешанный

Ктлинт

Обычно дружится

Можно пакеты джавовые игнорить

внезапно встал вопрос, не знаю, задавали его или нет

Как в top-definition функции получить ресурс как от класса? Как в джаве this.getClass().getResource(...) только в Котлине

Хотя top-definition функция подразумевается чистой, но тут речь идет о точку входа в программу

Как в top-definition функции получить ресурс как от класса? Как в джаве this.getClass().getResource(...) только в Котлине

Как вариант, взять класс от object { }

Можно взять любой другой класс, который сущестует в данном ClassLoader-е. Например String. Для гарантии лучше использовать что-то, что определено в импортах данного файла.

Можно еще взять Thread.currentThread().contextClassLoader.getResource(...), только надо понмнить о том, что там в одном случае надо ставить `/`перед путем, в другом нет (я все время путаю, где надо, а где нет)

Спасибо, сейчас попробую

Как вариант, взять класс от object { }

Можно еще взять Thread.currentThread().contextClassLoader.getResource(...), только надо понмнить о том, что там в одном случае надо ставить `/`перед путем, в другом нет (я все время путаю, где надо, а где нет)

Можно взять любой другой класс, который сущестует в данном ClassLoader-е. Например String. Для гарантии лучше использовать что-то, что определено в импортах данного файла.

А вот это... Я не знаю, выглядит как потенциальный источник неопределенного поведения

Хотя я в спецификации честно говоря не разбираюсь

Ничего неопределенного тут нет. У каждого ClassLoader-а есть свой набор ресурсов. Если в программе везде используется один и тот же ClassLoader, никакой проблемы нет. Если поведение более сложное, то я бы вообще рекомендовал его прописывать явно. В любом случае, второй вариант с Thread точно ведет себя однозначно (результат будет в теории разным в зависимости от того, откуда метод вызывается, но это же точка входа...).

Понял, спасибо

Кто-то может подсказать, существуют ли либы для того, что бы получать KDoc из кода?

Кто-то может подсказать, существуют ли либы для того, что бы получать KDoc из кода?

Dokka. Или AST Котлина.

Dokka. Или AST Котлина.

разве докку можно юзать так: val doc = Dokka("SomeCode.kt").getMethod("foo").getDocumentation()?

разве докку можно юзать так: val doc = Dokka("SomeCode.kt").getMethod("foo").getDocumentation()?

Можно посмотреть её исходники

Считается ли вредным тоном писать web приложение на ktor без использования html файлов, а только через dsl ?

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

Я думаю, что это как раз хороший вариант. Работать должно быстрее, чем с html шаблонами. Плюс гибкость (наследование и прочие радости), плюс строгая типизация. Если есть возможность, я бы предложил так и делать.

Делаю так, нравится.

Есть только один минус у всей этой системы шаблоны должны быть в коде, поэтому довольно сложно построить готовый код, который бы просто подсасывал внешние файлы в `kt`формате. Надо таскать с собой компиллятор, а его API какой-то еще очень сырой (не говоря уже о размере). Я сейчас вожусь с [Orchid](https://orchid.netlify.com/). На мой взгляд, очень перспективный проект. Но Pebble бесит. Я бы с радостью использовал котлиновский dsl вместо него, но не могу придумать как (без очень сильных граблей).

Добрый день! Какие библиотеки можно посмотреть для работы из котлина с интернетом как с клиентом? Планируются GET/POST для HTTP/HTTPS

Есть только один минус у всей этой системы шаблоны должны быть в коде, поэтому довольно сложно построить готовый код, который бы просто подсасывал внешние файлы в `kt`формате. Надо таскать с собой компиллятор, а его API какой-то еще очень сырой (не говоря уже о размере). Я сейчас вожусь с [Orchid](https://orchid.netlify.com/). На мой взгляд, очень перспективный проект. Но Pebble бесит. Я бы с радостью использовал котлиновский dsl вместо него, но не могу придумать как (без очень сильных граблей).

можно сделать gradle таск и компилить шаблоны на котлине в html отдельно от основного проекта =) Но это наверное не совсем что тебе нужно

Есть только один минус у всей этой системы шаблоны должны быть в коде, поэтому довольно сложно построить готовый код, который бы просто подсасывал внешние файлы в `kt`формате. Надо таскать с собой компиллятор, а его API какой-то еще очень сырой (не говоря уже о размере). Я сейчас вожусь с [Orchid](https://orchid.netlify.com/). На мой взгляд, очень перспективный проект. Но Pebble бесит. Я бы с радостью использовал котлиновский dsl вместо него, но не могу придумать как (без очень сильных граблей).

А зачем внешние файлы подтягивать?

Я смотрю сейчас khttp (но может ли он в https?) и networkinkt (насколько он common, то есть не андроидоориентированный?)

Добрый день! Какие библиотеки можно посмотреть для работы из котлина с интернетом как с клиентом? Планируются GET/POST для HTTP/HTTPS

retrofit?

можно сделать gradle таск и компилить шаблоны на котлине в html отдельно от основного проекта =) Но это наверное не совсем что тебе нужно

Это я и называю большими граблями.

А зачем внешние файлы подтягивать?

Статический или квази-статический генератор страниц.

Это я и называю большими граблями.

ну это так, маленькие десткий пластиковые грабельки для песочницы =)

Статический или квази-статический генератор страниц.

Без редеплоя приложения?

Я понимаю, что бывает больше, но того не стоит. Проще разобраться с Pebble. Но помечтать не вредно. Вон в Груви все это отлично работает, почему бы и в котлине не работать?

retrofit?

А у него есть какие-то экстеншены для котлина? Там не сильно много оверхеда по сравнению с khttp и networkinkt?

Там же рефлексия вроде вовсю

Без редеплоя приложения?

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

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

Чтобы шиблоны можно было динамически загружать?

По данные и код в кучу не понял

Если ты разделяешь контроллер от шаблона, то где же тут куча?

С точки зрения генератора есть код - то есть котлиновский или явовский код, который всасывает файлы из директории и генерит из них сайт и есть сама директория с данными. Если в этой директории с данными есть код, который надо докомпилировать, то получается идейный и практический монстр. Там начинается всякая веселуха с класслоадерами и прочим. Груви с этим справляется, но он на то и скриптовый язык. В принципе, можно сказать, что тема, то есть шаблоны страницы являются куском программы, генерятся при компилляции и не имеют отношения к данным, но тогда не понятно, как параметры в страницы подставлять. Надо опять же какой-то язык шаблонов использовать.

Груви в этом смысле един в двух лицах, они и язык и формат шаблонов. С котлин такое, боюсь, не пройдет.

Если без детальных дебрей хочется чего-то вроде http://docs.groovy-lang.org/next/html/documentation/template-engines.html в котлине.

С точки зрения генератора есть код - то есть котлиновский или явовский код, который всасывает файлы из директории и генерит из них сайт и есть сама директория с данными. Если в этой директории с данными есть код, который надо докомпилировать, то получается идейный и практический монстр. Там начинается всякая веселуха с класслоадерами и прочим. Груви с этим справляется, но он на то и скриптовый язык. В принципе, можно сказать, что тема, то есть шаблоны страницы являются куском программы, генерятся при компилляции и не имеют отношения к данным, но тогда не понятно, как параметры в страницы подставлять. Надо опять же какой-то язык шаблонов использовать.

Шаблон это просто функция которая на вход принимает набор каких-то параметров и возвращает стринг

Компилить с приложением очень удобно

Подгружать динамически мало масла

можно вроде депенденси инжекшена сделать, но сильно удобство теряется

Да кто спорит? Но вот теперь у меня есть маркдаун файл, с контентом. Как туда внутрь параметры передать? Даже для банального ${param} надо чего-то городить, а мы-то хотим, чтобы можо было туда внутрь вычисляемое выражение подставить. Без динамической компиляции вообще никак.

Если без детальных дебрей хочется чего-то вроде http://docs.groovy-lang.org/next/html/documentation/template-engines.html в котлине.

Это не для строгой типизиции

Статической

Да кто спорит? Но вот теперь у меня есть маркдаун файл, с контентом. Как туда внутрь параметры передать? Даже для банального ${param} надо чего-то городить, а мы-то хотим, чтобы можо было туда внутрь вычисляемое выражение подставить. Без динамической компиляции вообще никак.

Не понимаю, если шаблон это функция, то поставить параметры очень просто и ещё типобезопасно

Если без детальных дебрей хочется чего-то вроде http://docs.groovy-lang.org/next/html/documentation/template-engines.html в котлине.

Чет не понимаю какие приемущества по сравнению с тем же freemarker?

Если какой-то там файл, то да, это сложно и смысл теряется

Типизация тут не при чем. Она вполне может быть статической. Вопрос в том, когда компилляция выполняется. В котлине вроде сейчас появилась поддержка JSR223.

ну как, ты конечно можешь связять динамически два статически скомпилированных куска

Чет не понимаю какие приемущества по сравнению с тем же freemarker?

У чего, у Груви? Идейно никаких, и там и там собственный язык. На практике, разумеется у Груви возможности существенно шире. Можно спокойно в коде свои классы сделать и потом их использовать.

только из за этого сильно теряется смысл таких шаблонов

Я не спорю. Вопрос эстатики. Хочется, чтобы все было на котлине или котлино-подобном коде. А так приходится использовать один язык для кода и другой для шаблонизации контента.

Ну в общем-то в спринге нам же показывали рабочие темплейты на kotlin script уже больше года назад. я использую для конфига котлин скрипты. что мешает юзать их вместе kotlinx.html?

https://github.com/sdeleuze/kotlin-script-templating вот например

Я со спрингом не работаю, так что не в курсе. Спасибо за ссылку.

https://spring.io/blog/2017/01/04/introducing-kotlin-support-in-spring-framework-5-0 вот анонс был даже

Симпатишно. Это примерно то, чего я хотел

Я не спорю. Вопрос эстатики. Хочется, чтобы все было на котлине или котлино-подобном коде. А так приходится использовать один язык для кода и другой для шаблонизации контента.

ну так вроде это не так уж сложно сделать, просто связанный на этапе компиляции проще, надежнее и проверяется на уровне компиляции. Если обязательно нужно динамически это делать, ну, значит надежность упадет, но в остальном почти тоже самое.. только еще рефлекшена придется прикуть пачку

И получится Груви :)

Ну тащить с собой компилятор, а это десяток мегабайт зависимостей пока

типа груви, если строковый генератор и совсем не, если дсл

Ну тащить с собой компилятор, а это десяток мегабайт зависимостей пока

Я с этого и начал. компилятор сильно не портативный и без человеческого API был в последний раз, когда я проверял.

так его же в режиме скрипта можно использовать, там API устоявшийся

там создаешь scripting engine ~ 1 строчка и испольуешь его ~ 1 строчка не уверен зачем для скриптов еще какой-то api компилятора использовать причем компилятор ты совсем не трогаешь в этих местах

вот да

Вот пример https://github.com/bootique/bootique-kotlin/blob/master/bootique-kotlin-config/src/main/java/io/bootique/kotlin/config/KotlinScriptCompiler.kt#L16-L24

тем более, что там уже написана динамическая прослойка

Ну компилятор-то все равно тащить надо. К тому же, там проблема передачи параметров в скрипт. Я честно говоря не пробовал. Последний раз в этом направлении тыкался полгода назад. Искал аналог GroovyShell

там как раз проблем нету

с передачей параметров

в мапу кладешь и наслаждаешься

Надо будет потыкаться. У меня в другом проекте коммандная стока на груви и он меня переодически бесит

Надо будет потыкаться. У меня в другом проекте коммандная стока на груви и он меня переодически бесит

ай ноу зис фил, бро

еще бы Jenkinsfile поддерживал котлин

еще бы Jenkinsfile поддерживал котлин

Это было бы слишком хорошо

Хотя вообще я думаю было бы нет так уж сложно прикрутить туда котлин

Как же я вас люблю ))

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

Я думаю, что это как раз хороший вариант. Работать должно быстрее, чем с html шаблонами. Плюс гибкость (наследование и прочие радости), плюс строгая типизация. Если есть возможность, я бы предложил так и делать.

Делаю так, нравится.