Suggestion for a future version of Vaadin: Event Methods

Vaadin 6 / 7 / 8
1

Hi,
I come from a ZK background, so that definitely colours my suggestion here. By and large, I find Vaadin more productive, in some cases significantly. However, there is one area that I really think is weak in Vaadin’s programming model.

That is the Listener concept: e.g. component.addListener (…code… or interface implementation).

In ZK to handle an button event for example, you have a public method like this:


public void onClick$<item name>()
    {
    // Handle event details here...
    }


I know there are a couple of addons for Vaadin that do this
, but I think this is a good candidate for inclusion into the core.

There reasons I feel strongly about this are:

  2. Less coding, the current Listener only approach takes much more code to achieve the same
  3. Implementing the listener for onClick for example, handles ALL buttons = more complex event logic
  4. I personally really dislike anonymous inner classes, OK my hang up :slight_smile:

On the 3rd point, guilty as charged, largely because I spent years fighting with Swing and finally giving it up in favour of SWT. So esthetically and in terms of volume of code to maintain I really don’t like inner classes. It makes code harder to maintain and the UI logic is scattered through lots of snippets of code.

Good OO design generally discourages Inner classes. I tend to design one class = one java file, I know Vaadin makes extensive use of inner classes, which I personally do not like, but I’ll live with it :stuck_out_tongue: I find explaining the concept of inner classes to someone who is new to OO very long winded. From a coding point of view, they add no logic or informational value at all and possibly create more confusion. So I personally never use them. Again, my design choice.

That being said, anonymous inner classes
may
 also impose a slightly greater performance hit on the JVM (at least they did when I last looked at this kind of thing some years back).

See this thread on
Stackoverflow

and may have memory and security leaks:

Any seasoned developer will dread taking over someone else’s code because of finding so much spaghetti code. I’ve done this on quite a few large projects and it is really, really, really nasty.

I think the ZK concept is much cleaner, much easier for a new developer to pick and far, far more maintainable. The only “downsde” is each component you want to have an event handler for must have a unique ID. They then automatically auto-wire the calls from the button, for example, to the on$ that handles it.

I’m not starting a ZK vs Vaadin flame here, both a very good in different areas (I’m writing this in a Vaadin forum, hint, hint :wink: )but any successful project can learn from another.

The main reason I’m focusing two new projects on Vaadin is frankly the much, much better handling of themes and the ability to style systematically components. I know the same can be done in ZK, but it is not as rigorous as Vaadin.

Anyway, that’s my 2 cents worth.
Thanks again for producing an amazing product.
Anthony

2

Hi,

I used to prefer this type of approach (methods invoked via reflection vs listeners) when I was coding in Swing, but after 5 years of trying to maintain a large system, found that it was actually quite tricky : finding usage/refactoring is really rather complex when you are invoking methods by name - which is what you are doing here.


AbstractComponent#addListener(java.lang.Class, java.lang.Object, java.lang.String)
If do want to go down this route, you could do it yourself via reflection - i.e. create a listener class to invoke the a method on an object via reflection. That method could be discovered via a naming convention or via annotations; in fact If you look closely at the source/javadoc of Vaadin, you’ll see that there is a simple method there that will allow you to do pretty much what you are asking for .

You’ll also note from it’s documentation see that it’s use is discouraged.

Cheers,

Charles.

3

On the main issues I agree with Charles. You should be able to implement something close to what you want easily with small utility classes or subclasses of the standard Vaadin components if that is really what you want.

On anonymous classes:

In Java, especially with respect to memory leaks, it is quite easy to shoot yourself in the foot, but this is rarely an issue with component internal listeners as their lifecycles typically match the component’s lifecycle. When adding listeners between separate parts of the application, it is good to keep in mind that one component might hold onto another via the listener - and this goes unnoticed more often with non-static nested classes (including anonymous classes) as the references to the containing instance are implicit. This is a general issue, though - not specific to Vaadin but just as pervasive with Swing as well as many non-UI parts of applications.

The performance cost from the extra class and synthetic methods etc. is negligible with all modern JVMs - class loading might take up to some milliseconds, but only once, and the JVM typically quickly optimizes the invocations from nanoseconds to no penalty at all if used a lot. I would expect the performance cost of a reflection based approach to be orders of magnitude higher.

4

Thanks Henri and Charles,
I recently found the addListener (Event.class, Object targer , String methodName) method which suits me fine. I do appreciate your comments and views.

However, I note in the documentation of the method above it may be deprecated in favour of addListener(Event.class, Object, Method). I would put in a plea not to do that. Since it is the programmer’s responsibility to behave in an adult manner when playing with code, it also makes coding much simpler without so much “noise” and clutter that creating a method would take.

Just my two cents worth.
Thanks,
Anthony