На java для динамического формирования без использования какого-либо сервера над Jasper есть обертка — https://github.com/dynamicreports/dynamicreports. До API самого Jasper спускаюсь только в очень сложных случаях.
А в части интерпретации клиентского языка, который во всех браузерах по умолчанию js, дать возможность писать клиентский код на любом языке, который может интерпретировать сама GraalVM. Таким образом, пользователь сможет открывать как обычные сайты html/js, так и сайты с использованием других клиентских технологий.
Неужто для возможности подмены одного компонента другим? И что будет, если плагину передадим, инапример, кнопку, а он вернёт поле ввода?
Нет, никаких подмен. Код выдернут из контекста. Для рассматриваемой проблемы было бы достаточно void метода.
Почему бы «плагин»(хотя это не плагин, а декоратор) не параметризировать по ноде, чтобы обойтись без проверок на тип и приведения типов?
Декоратор, как правило, реализует тот же интерфейс и дополняет реализацию методов декорируемого объекта. При этом клиент общается именно с декоратором, когда тот хранит внутри себя ссылку на исходный объект. Здесь же предполагается добавление некоторых свойств объекту, при этом клиент общается с самим исходным объектом без посредника.
Типизировать можно, но все мои плагины добавляли общий (например, текст с тремя точками) функционал разным Node (в ячейку таблиц и списков, в поле ввода и подписи), писать при этом на каждую Node отдельный плагин означало бы дублирование.
Также не определено время вызова плагина. Что приводит к следующим вопросам:
— когда вызывать плагин? При инициализации, добавлении на форму, активации? Что будет, если вызвать плагин дважды?
Плагин предполагается быть вызванным во время срабатыванию слушателя на изменение коллекции дочерних Node при формировании графа. Повесите такой слушатель на Root сцены, дальше он сделает все сам.
Команда плагинов по умолчанию срабатывает на одну Node ровно один раз. Это обеспечивается хранением в ее свойствах флага-признака. При необходимости можно явно переприменить определенный плагин, тогда в его реализации должно быть заложено поведение на повторное срабатывание.
для изменения поведения элемента необходимо слушать события. Как на них оформлять подписку и дективировать ее? Лучше бы еще одним параметром передавать и имя события либо состояния (например, «initialize»)
В JavaFX есть Observable коллекции. Например, ObservableList будет уведомлять о добавляемых и удаляемых элементах. В моей реализации предполагалось только прослушка добавления новых Node в граф.
Привык делать так, чтобы не отвлекаться на подобные ситуации. Одно дело, когда только сам используешь для себя, другое дело еще всем коллегам надо помнить о том, что где-то надо что-то подписать. По моему опыту этого никто не помнит, а когда выстреливает, то тратится большое количество времени на решение проблемы.
Возможно, но обмен сериализованными объектами средствами java не вызывает никаких проблем, а главное требует минимум с точки зрения кода — реализацию интерфейса маркера Serializable и, если не ошибаюсь, то конструктор по умолчанию.
JAX-WS и REST не стал использовать, так как в серверном коде требуются дополнительные аннотации на каждый метод, а при сериализации сложных структур еще и на классы передаваемые в качестве аргументов или возвращаемые в качестве результата. Мой подход требует, чтобы ejb (
@Stateless
или
@Singleton
) реализовывал интерфейс и имел определенное имя. Этого достаточно, чтобы его можно было вызвать с клиента через proxy.
Если не ошибаюсь, есть проблема, когда у тебя Date лежит в Map. Приходится что-то дополнительно прописывать, а то он дату сериализует в число, а обратно, не может понять к чему это число привести.
Задачи интеграции с js-клиентом и обменом json не ставилось.
Java-cериализация при необходимости может быть заменена на любой другой способ. Берем тот же Jakson и сериализуем в JSON. На java-сериализацию завязки нет. Просто не было смысла, так как обе стороны java.
Feign, очень интересная библиотека. Надо будет ее подробнее изучить. Спасибо! На момент написания основы библиотеки (~2015г.) про feign не знал, да и если честно не искал. Почему-то был уверен, что подобного никто не пишет. Сейчас бы, наверное, доработал бы его под свои нужды.
Согласен с тем, что, если об этом беспокоится заранее, то переехать можно. Но на практике убедился, что каждая реализация стандарта отходит от него в той или иной степени, создавая полезный функционал, которого в стандарте нет. Если этим полезным функционалом не пользоваться, то при переезде проблемы будут минимальны. А если от него отказаться, то приходится платить временем разработки и тешить себя при этом мыслью о том, что вот если мы будем переезжать… Это уже каждый сам решает, технологии не при чем.
Интересно, что лежит под этой фабрикой в WildFly. В Glassfish/Payara, тоже есть из коробки, правда работает оно по устаревшей RMI-технологии. Увы, но на WildFly переехать в свое время не получилось — слишком много надо было менять в инфраструктуре серверного кода (вот такая вот заменяемость контейнеров в javaee).
То есть, вы предлагаете создать ServerSocket на 80 порту в рамках сервера приложений, и ServerSocket на 443 порту клиента. Реализовать дуплексное общение через две пары сокетов, а также взять на себя всю инфраструктуру сессий, обработки исключительных ситуаций, например, обрыв соединения, работу через прокси сервер и многое другое, что уже есть в готовых решениях с реализацией веб-сокетов. Думаю, что тогда бы мой серверный сокет на 80 порту (если бы он вообще запустился) нарушил бы корректную работу сервера приложений, на котором есть и другие приложения, например, с веб-интерфейсом.
Возможно, если бы я писал высоконагруженное приложение, то отказался бы от javaee и ее серверов приложений, воспользовался бы пакетом java.nio и написал бы еще одну реализацию веб-сокетов, но она была бы лучше.
На стороне java-сервера крутится javaee — сервер приложений, с готовой реализацией веб-сокетов. Библиотека, которую он использует предлагает готовый веб-сокет клиент. В моем случае нецелесообразно было вестись на мнимую производительность собственного кода и обременять себя поддержкой еще и сокетных решений.
Про ярлык и скачивание бинарников клиента к веб-сокетам никакого отношения не имеет — все верно. Это косвенно касается темы статьи про простую поддержку, в которую входит также настройка рабочего места для клиента. Описанный подход позволил эту настройку свести к простому копированию ярлыка и его запуску.
На java для динамического формирования без использования какого-либо сервера над Jasper есть обертка — https://github.com/dynamicreports/dynamicreports. До API самого Jasper спускаюсь только в очень сложных случаях.
А если ПО с открытым кодом на подходящей к комерческому использованию лицензии, а поддержка осуществляется на комерческой основе?
Как только вышла GraalVM, первое что пришло на ум — на ее основе получился бы не плохой полиглот-браузер. Что если ее взять за основу?
Количество поисковых запросов на LGPL 2.2 увеличилось в разы. Сам пошел посмотрел, что же за лицензия такая)
Вы правы, в данном контексте это не имеет смысла.
Нет, никаких подмен. Код выдернут из контекста. Для рассматриваемой проблемы было бы достаточно void метода.
Декоратор, как правило, реализует тот же интерфейс и дополняет реализацию методов декорируемого объекта. При этом клиент общается именно с декоратором, когда тот хранит внутри себя ссылку на исходный объект. Здесь же предполагается добавление некоторых свойств объекту, при этом клиент общается с самим исходным объектом без посредника.
Типизировать можно, но все мои плагины добавляли общий (например, текст с тремя точками) функционал разным Node (в ячейку таблиц и списков, в поле ввода и подписи), писать при этом на каждую Node отдельный плагин означало бы дублирование.
Плагин предполагается быть вызванным во время срабатыванию слушателя на изменение коллекции дочерних Node при формировании графа. Повесите такой слушатель на Root сцены, дальше он сделает все сам.
Команда плагинов по умолчанию срабатывает на одну Node ровно один раз. Это обеспечивается хранением в ее свойствах флага-признака. При необходимости можно явно переприменить определенный плагин, тогда в его реализации должно быть заложено поведение на повторное срабатывание.
В JavaFX есть Observable коллекции. Например, ObservableList будет уведомлять о добавляемых и удаляемых элементах. В моей реализации предполагалось только прослушка добавления новых Node в граф.
Такой DSL аналог JSX и активно используется в React. Я бы использовал его для отдельных компонент, которые бы собирал привычным верстальщику шаблоном.
Привык делать так, чтобы не отвлекаться на подобные ситуации. Одно дело, когда только сам используешь для себя, другое дело еще всем коллегам надо помнить о том, что где-то надо что-то подписать. По моему опыту этого никто не помнит, а когда выстреливает, то тратится большое количество времени на решение проблемы.
Возможно, но обмен сериализованными объектами средствами java не вызывает никаких проблем, а главное требует минимум с точки зрения кода — реализацию интерфейса маркера
Serializableи, если не ошибаюсь, то конструктор по умолчанию.Задачи интеграции с js-клиентом и обменом json не ставилось.
Возможно, если бы я писал высоконагруженное приложение, то отказался бы от javaee и ее серверов приложений, воспользовался бы пакетом java.nio и написал бы еще одну реализацию веб-сокетов, но она была бы лучше.
На стороне java-сервера крутится javaee — сервер приложений, с готовой реализацией веб-сокетов. Библиотека, которую он использует предлагает готовый веб-сокет клиент. В моем случае нецелесообразно было вестись на мнимую производительность собственного кода и обременять себя поддержкой еще и сокетных решений.
Про ярлык и скачивание бинарников клиента к веб-сокетам никакого отношения не имеет — все верно. Это косвенно касается темы статьи про простую поддержку, в которую входит также настройка рабочего места для клиента. Описанный подход позволил эту настройку свести к простому копированию ярлыка и его запуску.