EO
вот на текущий момент у меня under the hood всё сделано, сейчас делаю фасады
и на данный момент это выглядит вот так
и на данный момент это выглядит вот так
Size: a a a
2020 March 27
EO
теперь немного workflow, как я это вижу
EO
пользователь крафтит у себя с помощью DSL свои слайды, описывает их как он их видит
мой парсер парсит DSL и из него генерирует вот такой большой JSON, который я могу прокинуть в Deck, чтобы он десериализовался и запустил презентацию
мой парсер парсит DSL и из него генерирует вот такой большой JSON, который я могу прокинуть в Deck, чтобы он десериализовался и запустил презентацию
AT
Собственно, да, неясно, почему бы не создавать инстансы соответствующих классов прямо по месту - зачем там вообще JSON в этом месте?
EO
потому что я хочу сказать пользователям, что вот смотрите, вы можете не только API использовать, а и декларативно описывать состояние
AT
Сейчас самый популярный пользовательский DSL для сладов - Markdown.
EO
как Markdown натянуть на JSON?
AT
потому что я хочу сказать пользователям, что вот смотрите, вы можете не только API использовать, а и декларативно описывать состояние
Тут два варианта (которые можно поддержать оба):
1. Пользователи пользуются Вашим декларативным DSL, который может быть тупо удобными конструкторами классов как во Flutter и прочих Swift UI.
2. Пользователь генерирует JSON нужной формы любым удобным для него способом - в этом случае это не Ваша проблема.
1. Пользователи пользуются Вашим декларативным DSL, который может быть тупо удобными конструкторами классов как во Flutter и прочих Swift UI.
2. Пользователь генерирует JSON нужной формы любым удобным для него способом - в этом случае это не Ваша проблема.
AT
как Markdown натянуть на JSON?
Распарсить и сконвертировать. Ещё лучше - распарсить и сконвертировать сразу в Ваши модели, без JSON.
EO
Тут два варианта (которые можно поддержать оба):
1. Пользователи пользуются Вашим декларативным DSL, который может быть тупо удобными конструкторами классов как во Flutter и прочих Swift UI.
2. Пользователь генерирует JSON нужной формы любым удобным для него способом - в этом случае это не Ваша проблема.
1. Пользователи пользуются Вашим декларативным DSL, который может быть тупо удобными конструкторами классов как во Flutter и прочих Swift UI.
2. Пользователь генерирует JSON нужной формы любым удобным для него способом - в этом случае это не Ваша проблема.
вариантов пользования масса
1) Он может выкачать все мои пакеты и крафтить через API себе слайды, хоть заменять реализации - это сделано
2) Он может выкачать фасадный пакет Deck, прокинуть ему в конструктор JSON и получить то же самое - это сделано
3) Вариант с DSL конструкторами классов - возможно это то что нужно, варианты?
1) Он может выкачать все мои пакеты и крафтить через API себе слайды, хоть заменять реализации - это сделано
2) Он может выкачать фасадный пакет Deck, прокинуть ему в конструктор JSON и получить то же самое - это сделано
3) Вариант с DSL конструкторами классов - возможно это то что нужно, варианты?
EO
ну и второй вариант да, если пользователь хочет сам крафтить JSON и ему это нравится - это его проблеа
EO
все фигуры доступны как отдельные пакеты и они предоставляют классический new Shape() и делай с ним что хочешь
AZ
потому что я хочу сказать пользователям, что вот смотрите, вы можете не только API использовать, а и декларативно описывать состояние
Если *json* подходит, но хочется всё же более читаемого, почему бы *yaml* не использовать?
DP
предполагая, что часть данных слайда — исполняемые (интерпретируемые, чтобы не уходить в оффтопик), а в каком виде хотелось бы язык описания видеть?
у работодателя в списке потенциальных проектов делать инфографику с анимацией, которая должна из СУБД дергать параметры, и рендерить анигифки или кусочки видео
у работодателя в списке потенциальных проектов делать инфографику с анимацией, которая должна из СУБД дергать параметры, и рендерить анигифки или кусочки видео
AT
вариантов пользования масса
1) Он может выкачать все мои пакеты и крафтить через API себе слайды, хоть заменять реализации - это сделано
2) Он может выкачать фасадный пакет Deck, прокинуть ему в конструктор JSON и получить то же самое - это сделано
3) Вариант с DSL конструкторами классов - возможно это то что нужно, варианты?
1) Он может выкачать все мои пакеты и крафтить через API себе слайды, хоть заменять реализации - это сделано
2) Он может выкачать фасадный пакет Deck, прокинуть ему в конструктор JSON и получить то же самое - это сделано
3) Вариант с DSL конструкторами классов - возможно это то что нужно, варианты?
А какие нужны варианты для 3?
AT
Если *json* подходит, но хочется всё же более читаемого, почему бы *yaml* не использовать?
Или Toml, или... Markdown?! 😂
AT
Крайний раз делал слайды на Racket - вообще жара! 😃
DP
Dmitry Ponyatov
предполагая, что часть данных слайда — исполняемые (интерпретируемые, чтобы не уходить в оффтопик), а в каком виде хотелось бы язык описания видеть?
у работодателя в списке потенциальных проектов делать инфографику с анимацией, которая должна из СУБД дергать параметры, и рендерить анигифки или кусочки видео
у работодателя в списке потенциальных проектов делать инфографику с анимацией, которая должна из СУБД дергать параметры, и рендерить анигифки или кусочки видео
пока думаю делать граф объектов-трасформаторов данных, и редактировать этот граф командным языком
DP
зы, а где можно почитать буквари по реализации dataflow языков?
EO
Если *json* подходит, но хочется всё же более читаемого, почему бы *yaml* не использовать?
yaml тоже можно