I’ve seen in the Vaadin 7 roadmap that there are some much needed refactorings planned for ApplicationServlet.
I’d like to know if there are any more details on what classes will be introduced in order to delegate beaviour.
I’d also like you to consider using custom Request and Response classes which can wrap the HttpServlet* stuff… this is useful if we want to use non Servlet API compliant servers like Netty, it should also make it easier to add custom C/S protocols like WebSockets.
Finally, please change all the URLs to URIs to allow using custom protocol handlers… I’ve toyed with the idea of developing native Android apps using Vaadin. Basically I added a custom ContentProvider a change to URIs to a use a prefix like “content://com.vaadin”, of course this threw MalFormedURL exceptions all over the place… This allows “shortcutting” the HTTP request handling and no application server is needed… in the quick “hackish” version I toyed with I just created a dummy HttpServletRequest and called the service method in the servlet.
These scenarios require big changes to ApplicationServlet so I think it would be best if there was a VaadinHandler and the Servlet would only delegate service calls to the Handler using a custom Request.
On a side note would you consider setting up a GitHub mirror for Vaadin ? It should simply be a matter of getting in touch with their support and they should setup automatic mirroring (or you could just use post-commit hooks).
You can find the plans of Vaadin 7 at
http://dev.vaadin.com/wiki/Vaadin7 . Note that those are the plans made before development so some of the points may be scarce or a bit outdated. This might be because the plans change while the features are developed, but the basic ideas are still there. The points in the feature list that might interest you are 3, 7, 8 and 11.
The first features that are being worked on are Root (the new main window), new way of doing forms and CustomField. The root may already have a bit of those things you are looking for. For example it gets in a WrappedRequest parameter in the init method, which again Vaadin 6 Window didn’t, and you had to access the app servlet to get that. The first alpha version of Vaadin 7 is actually just around the corner and you should test it out and give feedback when it does. By giving feedback now you can influence on what V7 will look like.
Thanks for you ideas. We are currently working on the final details for the first alpha release of Vaadin 7. Part of that release will be two new interfaces that are used in various locations inside the framework and also in some parts of the public API: WrappedRequest and WrappedResponse. The current state of e.g. AbstractApplicationServlet and related classes will be quite messy in the release - backwards compatibility has been broken in order to incorporate support for WrappedRequest and WrappedResponse and some parts of the functionality has been moved to more generic RequestHandlers.
The next two months the development will focus on improving client side performance and the high level API that components use to communicate with their counterparts in the browser. After those topics, the roadmap brings us to the kind of issues you describe. There are not any specific plans on exactly what will be changed and how it will work, but the vision is to rework the way the Servlet/Portlet parts of Vaadin can be extended e.g. by add-ons (preferably without requiring any changes to e.g. web.xml when adding a new add-on). Two specific targets are enabling add-ons to easily modify the contents of the initial HTML page that is used to bootstrap a Vaadin application and enabling pluggable support for server push using e.g. WebSockets and some fallback for older browsers.
There have been some discussions about mirroring the git repository on GitHub, but we have kept those visions on hold until we have “learned” how we want to use git. We might still want to rewrite the history of our semi-public git repository hosted on dev.vaadin.com as it is unnecessarily huge because of some libraries that were imported from the old svn repository even though they are not used any more as we are now pulling the libraries using Ivy.
