Important Notice - Forums is archived

To simplify things and help our users to be more productive, we have archived the current forum and focus our efforts on helping developers on Stack Overflow. You can post new questions on Stack Overflow or join our Discord channel.

Product icon

Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.

Navigator7 add-on: API of Vaadin 7 ?

John Rizzo
1 decade ago May 05, 2010 9:05am

Hope that with such a thread title, we are going to have reactions and feed the not-very-active (on the site) debate about what API change developers need to address that:

Window management should be completely revised to make supporting multi-window applications, tabbed navigation, bookmarking and web-style applications easy and logical


I've taken a week to extract what I know and have done in that area (with the accumulated knowlege given by your great support on this forum), into a reusable framework that is running in production on BlackBeltFactory.com. I've taken an extra day to document it, in order to have more reactions about what API developers need.

Navigator7 is born: http://vaadin.com/directory#addon/120

Let me already answer the following question:

How Navigator7 compares to the Navigator plugin?

I started from the Navigator plugin (1 class). You will notice that I've kept the examples of it to ease the usage comparison.
I've added all the reusable code of BlackBeltFactory.com in that area. I ended up with a mini framework of a dozen of classes. It's much more code because I address more areas (as URI analysis and page templating. Navigator7 also fixes a technical weakness of UirFragmentUtiliy not addressed by the original Navigator). I've been also much more aggressive/intrusive in the API changes for the programmer.

If you have anything to say about what you expect in Vaadin 7 to ease your life in these areas, please post a reply.
- page navigation,
- tabbed browsing,
- URI parameters handling,
- page templating.

Ramzi Youssef
1 decade ago May 05, 2010 10:23am
John Rizzo
1 decade ago May 05, 2010 11:31am

What is your opinion about that ?

Good question Ramzi.

Navigator7 is an odd-on on top of Vaadin 6. By definition it removes nothing from Vaadin 6 and backward compatibility is 100% (it is just not using the add-on). If it would be integrated in Vaadin 7, it could be an addition of classes without much impact on the existing ones.

I would be to say that it's a layer on top of the existing API. It's obvious to me now Navigator7 exists, but it was not clear to me a month ago. It's like having (sorry for the ugly comparison ;-) Struts2 on top of Servlet. Struts2 does not break Servlet/JSP. Some need Vaadin Window management API as it is now. But it is probably too low level and the answer is probably to leave the current Window management API untouched (or nearly), and to add a web navigation layer.

What needs to change is the documentation in that case: you don't teach the low level (existing) API anymore (Servlet) but directly the higher level one (Struts2) to the masses. The sampler application, for example, if a perfect candidate to benefit Navigator7.

Last updated on May, 5th 2010
Joonas Lehtinen
1 decade ago May 05, 2010 7:50pm

Ramzi Youssef: You agree with me that Vaadin 7 will be a major new version with lots of enhancement ?
I'm not OK with Joonas about “maintain 100% backwards compatibility “. I think that it'll be a brake to solid fearless and audacious evolution of Vaadin if we maintain 100% backwards compatibility.
What is your opinion about that ?

I think that you misread my proposal. The quoted part should be "Make it easier to implement the Container interface, but maintain 100% backwards compatibility.". The API I proposed for windowing in Vaadin 7 is far from being 100% compatible. See http://vaadin.com/web/joonas/wiki/-/wiki/Main/Vaadin_7_API

Ramzi Youssef
1 decade ago May 06, 2010 9:13am
John Rizzo
1 decade ago May 13, 2010 3:10pm
Sami Ekblad
1 decade ago May 13, 2010 5:32pm
John Rizzo
1 decade ago May 16, 2010 2:11pm

I introduced a new class in the framework: WebApplication.
It's a ServletContext scoped application. There is a name clash with the com.vaadin.Application.
That's now Navigator7 v7.1

The more I think about it, the more I beleive that the "application" defined in the web.xml as init parameter for the vaadin servlet, should be ServletContext scoped (as my new WebApplication), and users should override it, instead of the HttpSession scoped com.vaadin.Application.
If we take the Navigation7 stuff apart, what is com.vaadin.Application instances used for?

1. to hold references to Window objects. Is it ok to store that in the HttpSession? Probably.

2. to define the algorithm for creating the main window. It's probably no user-specific algo => It should probably moved in the ServletContext scoped application.

Now, with Navigator7, user application code (pages) don't need the com.vaadin.Application (or their descendant). They need the main Window (to template it) and the UriAnalyzer (ServletContext scoped now).

As summary, I'd rename com.vaadin.Application to com.vaadin.UserContext, and make it less central in the design, with things moved to the ServletContext scoped WebApplication. People would extend WebApplication and tell the new class name in the web.xml (init param of Vaadin servlet).
I've not changed Navigator7 to that point, it's not goal (at least not before an common agreement after discussion).

John Rizzo
1 decade ago May 18, 2010 1:00pm
Pether Sorling
1 decade ago May 25, 2010 2:51pm
John Rizzo
1 decade ago May 25, 2010 3:06pm
Pether Sorling
1 decade ago May 27, 2010 10:40am
John Rizzo
1 decade ago May 27, 2010 12:02pm
Pether Sorling
1 decade ago Jun 02, 2010 9:08pm
John Rizzo
1 decade ago Jun 03, 2010 11:43am
Pether Sorling
1 decade ago Jun 03, 2010 4:33pm
John Rizzo
1 decade ago Jun 04, 2010 8:54am

I've added an interceptor mechanism.
Here is the Interceptor interface and doc:

 * An interceptor is a stateless class that follows the interceptor pattern, as found in Filter and in AOP languages.
 * Interceptors are objects that dynamically intercept Page invocations. They provide the developer with the opportunity to define code that can be executed before and/or after the execution of an action. They also have the ability to prevent a page from being invoked. 
 * Interceptors provide developers a way to encapsulate common functionality in a re-usable form that can be applied to one or more Pages.
 * Interceptors must be stateless and not assume that a new instance will be created for each request or Page. 
 * Interceptors may do some processing before and/or after delegating the rest of the processing using PageInvocation.invoke().
 * Navigator7 Interceptor differs from Struts 2 Interceptors and Servlet Filters the following ways:
 * - There is one Navigator7 Interceptor invocation for each NavigationEvent (=> once when we move to the page and instanciate it), while Filters and Struts 2 Interceptors are called for every request (included when you click a button on a page).
 * - Navigator7 Interceptors are not configured into an external xml file, and you cannot define a set of pages for which they should be applied and others for which they should not be applied. Just program it inside the interceptor if you need to activate it for specific pages. This should probably change if we want to use reusable interceptors written by others only for specific pages, but it's not the case yet. Let's keep it simple for now. 
 * To have an idea of what interceptors can be used for, see Struts 2 documentation (while some examples are meaningless in a Vaadin context): 
 * http://struts.apache.org/2.x/docs/interceptors.html
 * A typical usage would be security: the interceptor can check the logged-in user in the session, and can check annotations on your Page classes, and forward to an error page in case of mismatch.
 * Register your interceptor in your class extending WebApplication, by calling WebApplication.registerInterceptor().
 * @author John Rizzo - BlackBeltFactory.com
public interface Interceptor {
    public void intercept(PageInvocation pageInvocation);

In the initial Navigator, Joonas did implement a dialog box that asks the user to confirm before leaving some pages.
It was there (in a more generic form) in the Navigato7's Navigator class. But I didn't feel it was at the right place, it was too close form the heart.
I've transformed it into an interceptor and it's much better now on the design point of view. It also gives you a non trivial example of Interceptor ;-)
The example application has been updated as well to show how to register interceptors.

It's in version 7.2, available now.

John Rizzo
1 decade ago Jun 16, 2010 7:58am
John Rizzo
1 decade ago Jun 23, 2010 9:10am
John Rizzo
1 decade ago Aug 19, 2010 8:59am
Pether Sorling
1 decade ago Sep 12, 2010 7:54am
John Rizzo
1 decade ago Sep 13, 2010 7:32am
John Rizzo
1 decade ago Sep 13, 2010 2:23pm
John Rizzo
1 decade ago Sep 14, 2010 11:45am
John Rizzo
1 decade ago Sep 23, 2010 9:38am
Jens Jansson
1 decade ago Sep 23, 2010 12:00pm
John Rizzo
1 decade ago Sep 29, 2010 9:38am
Jens Jansson
1 decade ago Sep 29, 2010 1:32pm
Jan De Beule
1 decade ago Sep 29, 2010 2:11pm
John Rizzo
1 decade ago Sep 29, 2010 2:28pm
Johannes Peeters
1 decade ago Sep 30, 2010 8:19pm
John Rizzo
1 decade ago Sep 30, 2010 10:44pm
Johannes Peeters
1 decade ago Oct 02, 2010 8:45am
John Rizzo
1 decade ago Oct 02, 2010 1:21pm
Johannes Peeters
1 decade ago Oct 03, 2010 8:24am
Gregory Katkov
1 decade ago Oct 03, 2010 5:12pm
1 decade ago Oct 04, 2010 8:03am
John Rizzo
1 decade ago Oct 05, 2010 8:38am
John Rizzo
1 decade ago Oct 05, 2010 9:04am
1 decade ago Oct 05, 2010 2:51pm