Комментарии 12
А так, для прикладушки на коленках, даже jsp+Spring MVC можно использовать.
Для jsf — есть проект JoinFaces
Я работал также с Vaadin 8, он еще основан на GWT. И я очень быстро собрал сложный интерфейс с кучей форм и гридов без написания CSS и JavaScript. Также много готовых компонентов написало сообщество разработчиков. В ситуации с Vaadin 14 все происходит иначе. Разработчик данного фреймворка начиная с версии 10 решил отказаться от использования GWT, поскольку проект старый и не развивается.
Разработчики Vaadin написали свой Vaadin Flow с использованием Polymer WebComponents. Фреймворк стал гибче.
Но при написании своего Polymer компонента и внедрения в него других JS библиотек возникают проблемы с конфликтом версий в npm.
Babel для сборки Vaadin компонентов имеет старую версию, и если ваша библиотека не может быть собрана с этой версией, а ей нужна новее, то возникает проблема. Меняя на версию новее перестают собираться компоненты от Vaadin Flow.
Поэтому мне пришлось отказаться от использования данного фреймворка в своем проекте.
Начиная с версии 10 разработчиками было внедрено спорное решение: интегрироваться с экосистемой JS и использоваь ее средства сборки. Если раньше все было достаточно просто и быстро, то сейчас оно тащит node с двухсотмегабайтным бонусом пакетов, и собирается минут 5. Пробовал Vaadin 14, у которого даже официальные сэмплы не собирались. В офисе сборка внезапно подвисает минут на 10, но в лог ничего не пишется — подозреваю, что что-то пытается пробиться сквозь корпоративные прокси. Кроме того, для Vaadin Flow на порядок меньше стало плагинов. Вобщем, все стало как-то тяжко и хрупко. Поэтому продолжаю пользовать Vaadin 8.
P.S. Хоть сам Vaadin 8 и написан на GWT, но практически все аддоны написаны на JS или предоставляют враппер над существующей JS-библиотекой, а посему не требуют никакой дополнительной компиляции при сборке.
GWT, поскольку проект старый и не развивается
Хмм… А последний коммит сутки назад был (https://github.com/gwtproject/gwt). А в качестве альтернативы Vaadin, можно Domino UI использовать
Не пытайтесь получить доступ к contactRepository из конструктора объекта это непременно вызовет NullPointerException, получайте доступ из методов с аннотацией PostConstruct, или методов уже созданного объекта.
Можно инъецировать через конструктор:
ContactRepository contactRepository;
@Autowired
public ContactList(ContactRepository contactRepository){
this.contactRepository = contactRepository;
...
P.S. Не очевидным моментом в статье является то, что при использовании Spring классы аннотированные как «Route» являются аналогами классов, помеченных как «Component» в обычном Spring приложении. Например, инспектор IDEA выводит предупреждение на этот счет.
Так используя Component вместо Route — не возможно будет использовать полностью Vaadin Flow, назначение у них все же разное.
Используя Component в ContactList сразу получаешь:
Could not navigate to 'contacts'
Reason: Couldn't find route for 'contacts'
Можете привести рабочий пример с использованием Component?
The only difference between using the router in a standard application and a Spring application, is that in Spring you can use dependency injection in components annotated with Route. These components are instantiated by Spring and become Spring-initialized beans. In particular, this means you can autowire other Spring-managed beans.
Быстрая разработка Web приложения на Vaadin и Spring Boot