Tuesday, August 31, 2010

Why Vaadin - proof of concept

Now, three weeks after deciding for Vaadin, we have finished the very first prototype.

To complete the current sprint we have released the result as the first milestone. We created a short video to demonstrate the current status so you don’t need to install it yourself. Please be aware that we have not focused on things like user experience design and theming. We just wanted to implement a mini AdminCentral and prove that Vaadin works for us.


Video: by Federico Grilli

Note: if you use the current milestone release you will have to point your browser to /AdminCentral/ as otherwise the old AdminCentral will be served. We will switch that as soon the new UI is functional enough.

Our experience
We had a quick start and were able to implement things like the tree view, accordion menu and dialogs very quickly. So Vaadin definitely fits our team and will fit other Java oriented teams well.

Extensibility
It is the ultimate goal to make the new AdminCentral extensible so that everybody can contribute rich modules and paragraphs to the system easily. As expected the server side characteristic of Vaadin helped a lot and allowed us the improve the wiring of the components:
  • Provider interfaces for the various elements (dialog field, accordion menu actions, ..)
  • No dependency on the Content API
  • DSL/Builder APIs can be build easily (not yet done)
  • All is instantiated/configured by Content2Bean

History support
We still need to improve things but the accordion menu already supports history, and if you switch the tree views (website -> config -> website) you will see that the state of the former selection is kept. We also want the complete status (selected page) to be “bookmarkable”.

Page editing
It was the goal to prove that we can embed a Vaadin application into an existing web page and that we can inject Vaadin components like the edit bars or dialogs. This worked, and since the client side coding is done in GWT, we did not need to leave the Java world. As always, once you leave the well-treaded path you have to overcome obstacles but we learned a lot, found traction and finally succeeded.

Now that the basics are done, we will have to optimize the initial loading time. The produced script is definitely not small (170k) and has to be cached. Setting the correct response headers will do its job. We also plan to add the edit bars already in the GWT entry point and only bind them later to the server side components. It might be that we even move bigger parts of the code to the client side, but since this is GWT backed code, it is not different from what we had to do in the "Plain GWT" approach.

Next steps
Many things were done and decided quickly so we need to finalize and clean up in the next sprint (the last before the conference). Therefore, we will improve the naming and streamline the architecture a bit.

Now that we can build the dialogs by code we want to show that it is feasible to write a nice dialog editor. How fancy is that!

Looking forward to discuss/argue at our conference ;-)

9 comments:

Boris Kraft said...

As usual, vote this blog post up on DZone to help us be seen!

Ernst Bunders said...

very interesting. We are looking forward to the new admin cetral, as we are presently struggeling with need to create higher level over recurring tasks. We would very much like to be able to create dialogs and wizards for maintenance tasks or (sub) site creation (from templates with a set of variables). We also would like to create dialogs that can be linked to (groovy) scripts as a way to create ad-hoc yet user friendly higher level tasks.

We hope the new admin cetral wil help us to make these things doable (or better: easy)

keep it up, and see you at the conference,

Ernst

RaghuK said...

hey philip,

firstly thank you for the valuable articles you have been writing about Vaadin.

Secondly, congratulations on successful development of proof of concept.

Choosing vaadin is the best thing you guys have done for magnolia and at the same time Vaadin community as well.

Long live these great open source technologies !!!!

Thank you
Raghu

Jan-David said...

Is the code available somewhere?

iirekm said...

There's a problematic thing with Vaadin: most GUI code is executed on server side - try for example Vaadin demo (http://demo.vaadin.com/sampler ) and see HTTP requests in for example Firebug. This can make GUI inresponsive with slower internet connections (it's not possible to get ping 500 ms between 2 any places in the world). What's more, many people connect to the Internet via digital TV satellite networks or via cellphone networks - ping is really slow there. I have tested this Vaadin demo with a quite good cellphone network (HSDPA), and I'm not pleased with the speed of Vaadin.
Another problem is that server may be quickly overloaded when many people click at the same time.

Pure GWT or GWT ExtJS don't have such limitations - the demo at http://www.sencha.com/examples works very fast even with my HSDPA.
Of course GWT makes bigger burden related with Java -> JavaScript conversion (you have very restricted Java API), but the only rule to remember is to use it wisely: if some computation can be done at server, do it at the server, don't translate all Java code to JavaScript code.

For me Vaadin can be possibly used for intraned apps (where network is usually fast), GWT for internet apps (where network can often slow down).

Philipp Bärfuss said...

In response to the comment of iirekm:

I have outlined my arguments in my former blog post "line of argument" in details but in short:

1. if you interact with the UI you normally also need data (tree view, dialog)
- it does not make a difference if you request data or send an UI event
- the more data/configuration driven the application, the less difference can be seen

2. in Vaadin you can write client side code using GWT
- if you don't need the server you don't have to ask it (accordion menu, context menu)
- we do that in the page editor where we will write a bunch of client side code

3. we use Vaadin to implement the new Magnolia back-end
- it is not used in the front-end (public pages)
- I share the concerns in regard of high traffic web-sites

4. The GWT and ExtGWT samples are mostly plain client side code
- they are responsive
- but only as long they don't need to load data

We have mainly chosen Vaadin to overcome some limitations with the plain GWT approach. The basics can be looked up in "the Odyssey" and I hope to line out the GWT library linking problem in a future blog post.

iirekm said...

Maybe Vaadin demo is written incorrectly, and they use server-side code where GWT code should be used for better interactivity.
Due to bad feelings after clicking Vaading demo I haven't tried it yet, although I know about Vaadin for some time.
Is Vaadin-GWT integration done well, or it requires some tons of boilerplate code?
If it's easy, I think that Vaadin developers should improve their demo to avoid so many server calls. Probably there are other people disappointed with this problem.
Looking at demo examples and trying to implement something own is probably the fastest way of learning a new library, so good demos are very important.

Hendy Irawan said...

Why not Eclipse RAP? Did you consider it also?

iirekm said...

I don't know how good RAP is, but one thing is sure: it's not as popular as Vaadin recently is.
One of points when choosing a framework is it's popularity: more popularity means more community support more books, more tutorials, more programmers available, etc.
Unfortunately RAP doesn't shine in this area as bright as Vaadin (although Vaadin is also not as popular as let's say JSF, but anyway Vaadin is quite well known).