Unusable Style Editor
A great idea crippled by an unusable tool
A few years ago, my team leader asked me to investigate replacements for the obsolete MVC framework Struts 1. One of the candidates was Vaadin. Alas, what seemed its killer feature ran into a brick wall.
What it does
What was liked
What got my attention was the Designer, which allowed design of pages using drag-and-drop components, such as buttons or text. By clicking on a component, its properties could be edited, like the old desktop languages Delphi and Visual Basic. Unlike the IDEs of those languages, the property editor could not create event handler stub code, requiring manual adding of handler code, but seemed easy enough for colleagues who barely knew HTML and CSS. Better, the CSS class property (confusingly named style) could be edited by picking names from a theme, leading to a consistent look and feel.
The brick wall
A simple table editing page was created using a custom theme, so it looked like the existing admin pages. It needed bespoke code to link a database grid to a record list but changing the record list in response to search fields meant the grid would automatically work out formatting and displaying the new list. A record editing page similarly used the custom theme and setting a different record would be automatically formatted and displayed.
Thus, linking front-end, presentation code with the back-end, business layer seemed workable. As long as the Designer was idiot proof enough for programmers who knew little CSS, the framework was a possible candidate. The style editor for selecting the CSS class of a component looked like below.
Notice, at the top, the Designer plugin is using the custom theme 'vaadinservlet1' but the style editor only has the default theme 'ValoTheme'. The selected component is text but the available styles (which are actually CSS classes) are all the styles in the theme, most of which don't apply to text components. It's possible to enter custom style names but the developer must know which exist as the available style list is useless.
It's odd the plugin can recognise custom themes but one part of it can't. Nonetheless, this seemed like the configuration would fix it. As documentation revealed nothing, a question on the Vaadin forums was tried, as found at Vaadin forum > Designer > Where does the Style editor Available Styes come from?. It got a reply from a Vaadin developer, as shown below.
The ticket is found on Github at vaadin / designer / Support custom theme class constants in style editor, as shown below. It was automatically closed due to inactivity after a year.
The ticket was not the first one requesting the fix either, as seen at vaadin / designer / Style editor should show styles according to used theme. It was also automatically closed due to inactivity.
As an ex-Delphi developer, I miss WYSIWYG page designers, regard the HTML/CSS/Ajax model as a step backwards for application development in many aspects, and the Vaadin, server-side model as a partial redress for LAN-based applications. That the style editor is stuck with the default theme hinders an organisation's own look and feel, commonly developed by those with collections of bespoke applications and graphic artists. The kind of organisations that would benefit from Vaadin. That Vaadin Ltd cannot be bothered to fix the Designer plugin that users pay a monthly subscription for marks Vaadin as unusable for professional level.