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.
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.
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
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”.
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.
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 ;-)