Сообщение Re[3]: Number to Integer/Long от 07.01.2022 17:21
Изменено 07.01.2022 17:30 Infernal
Re[3]: Number to Integer/Long
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, rosencrantz, Вы писали:
vsb>>>Хочу не прописывать конкретные типы в JSON-маппингах для большей гибкости. Но в коде, конечно, нужно конвертировать в конкретные типы.
R>>Не помогу, но интересно зачем это нужно. Всегда использовал Jackson для сериализации JSON, всегда хватало.
vsb>И я использую Jackson. Смысл в том, чтобы не прописывать в маппингах (которые по сути контракты) ненужные ограничения.
vsb>Может, конечно, это и плохая идея, не знаю, пока существенных минусов не вижу.
Примерно такую же задачу, решал при помощи аннотаций на поля в классе. Там прописываешь типы, ограничения, названия и прочие метаданные и т.д.
дальше это все в зависимости от аннотаций сериализуешь-десереализуешь из JSON просто по данным из этих аннотаций.
Или что мешает, смотреть на тип поля в вашем классе и в зависимости от него конвертировать?
Задача, которую решал(решаю) — классы описывающие set пропертей любых типов(включая листовые и enum) описываем аннотациями отдаем на json -> UI (Vue) -> отрисовываем -> обратно на сервер -> собираем валидируем по аннотациям -> дальше эта вся хрень храниться в Hazelcast/infinispan/базе/где угодно и подключается в качестве источника к Quarkus/Spring приложениям вместо properties файлов.
vsb>Здравствуйте, rosencrantz, Вы писали:
vsb>>>Хочу не прописывать конкретные типы в JSON-маппингах для большей гибкости. Но в коде, конечно, нужно конвертировать в конкретные типы.
R>>Не помогу, но интересно зачем это нужно. Всегда использовал Jackson для сериализации JSON, всегда хватало.
vsb>И я использую Jackson. Смысл в том, чтобы не прописывать в маппингах (которые по сути контракты) ненужные ограничения.
vsb>Может, конечно, это и плохая идея, не знаю, пока существенных минусов не вижу.
Примерно такую же задачу, решал при помощи аннотаций на поля в классе. Там прописываешь типы, ограничения, названия и прочие метаданные и т.д.
дальше это все в зависимости от аннотаций сериализуешь-десереализуешь из JSON просто по данным из этих аннотаций.
Или что мешает, смотреть на тип поля в вашем классе и в зависимости от него конвертировать?
Задача, которую решал(решаю) — классы описывающие set пропертей любых типов(включая листовые и enum) описываем аннотациями отдаем на json -> UI (Vue) -> отрисовываем -> обратно на сервер -> собираем валидируем по аннотациям -> дальше эта вся хрень храниться в Hazelcast/infinispan/базе/где угодно и подключается в качестве источника к Quarkus/Spring приложениям вместо properties файлов.
Re[3]: Number to Integer/Long
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, rosencrantz, Вы писали:
vsb>>>Хочу не прописывать конкретные типы в JSON-маппингах для большей гибкости. Но в коде, конечно, нужно конвертировать в конкретные типы.
R>>Не помогу, но интересно зачем это нужно. Всегда использовал Jackson для сериализации JSON, всегда хватало.
vsb>И я использую Jackson. Смысл в том, чтобы не прописывать в маппингах (которые по сути контракты) ненужные ограничения.
vsb>Может, конечно, это и плохая идея, не знаю, пока существенных минусов не вижу.
Примерно такую же задачу, решал при помощи аннотаций на поля в классе. Там прописываешь типы, ограничения, названия и прочие метаданные и т.д.
дальше это все в зависимости от аннотаций сериализуешь-десереализуешь из JSON просто по данным из этих аннотаций.
Или что мешает, смотреть на тип поля в вашем классе и в зависимости от него конвертировать?
vsb>Здравствуйте, rosencrantz, Вы писали:
vsb>>>Хочу не прописывать конкретные типы в JSON-маппингах для большей гибкости. Но в коде, конечно, нужно конвертировать в конкретные типы.
R>>Не помогу, но интересно зачем это нужно. Всегда использовал Jackson для сериализации JSON, всегда хватало.
vsb>И я использую Jackson. Смысл в том, чтобы не прописывать в маппингах (которые по сути контракты) ненужные ограничения.
vsb>Может, конечно, это и плохая идея, не знаю, пока существенных минусов не вижу.
Примерно такую же задачу, решал при помощи аннотаций на поля в классе. Там прописываешь типы, ограничения, названия и прочие метаданные и т.д.
дальше это все в зависимости от аннотаций сериализуешь-десереализуешь из JSON просто по данным из этих аннотаций.
Или что мешает, смотреть на тип поля в вашем классе и в зависимости от него конвертировать?