Yet another navigation framework

Hello,

In time when I was using Navigator7 with grails i don’t feel comfortoble with it. Don’t get me wrong, Navigator7 is great addon, but it wasnt enough flexible for my purposes:

  • I’ts painful in grails to use custom servlet, provided with framework
  • I want pages without uri’s
  • I want more than one application window (with unified navigation)
  • I want to change page url format for some pages (but leave default one for others)
  • And finally i want prettier way to configure my navigation

So I decided to make my own. At first it was forked Navigator7, but later I drop it and wrote everything from scratch.

As a result i get:

  • Java dsl for navigation configuration. It allows easily view structure of application. But more important is side effect of having application “skeleton” in runtime: fail fast (it is easy to implement startup time checks and valiadate annotations use correctness, structure correctess etc.), ability to easily add custom annotations and automatic logic (e.g. automatic menu building)
  • Navigation process between pages is more like ordinary servlet request - navigationt request concept. But also navigation gets lifecycle - set of events which could be used to insert custom logic in exact time (window created, new page request received, new page prepared, navigation finished etc.).
  • Most of internal logic is represented as set of handlers, so it is possible to change e.g. url format (for one or more windows or for just one page)

Experimental release of nf4v is availible here: http://code.google.com/p/nf4v/

I didn’t published it as addon (in fact jar is ready for publishing), because currently i can’t continue development and i don’t want to abuse directory with dead project

I hope someone will find it useful (or at least ideas).
And if somebody want to
continue development
please contact me (for hosting access).

Hi Vyacheslav,

I didn’t look at the framework yet; but anything done in that area will certainly help the discussion and I hope Vaadin guys will seriously look at your motivations/needs for every choices you’ve made.

A few comments on your main points

I don’t like the servlet so much either. I’ve done it to respect the way Vaadin 6 is implemented. Struts 2 proposes a filter.

I need a reference to the ServletContext someway, in order to store application scope things in it. Even if Vaadin 7 does nothing for navigation, it should give us a ServletContext scoped object (and name it Application, and don’t anymore name “Application” an HttpSession scoped object).

We all prefer pages without URI.

http://mydomain.com/myPage/param1/param2

is much nicer than

http://mydomain.com#myPage/param1/param2

or

http://mydomain.com#!myPage/param1/param2

Joonas told me that the URI was the better way to do it for technical reasons. Maybe for coherance with GWT?
I don’t remember the forum post, sorry.

I’d be interested to know why. You probably put something in that window to wish you have 2.

Can you give us a useful example?

Prettier than @Page on a class?
More detail would help the discussion.

Thanks.
John.

Why not just do ((WebApplicationContext) yourApplication.getContext()).getHttpSession().getServletContext() ?

hi,
I don’t thing It’s possible to use page navigation such as:

http://mydomain.com/myPage/param1/param2 in the portal environment.

So it’s probably wise to be able configure navigation in different ways.
Correct me If I am wrong.

It was an option. It requires to have a reference to yourApplication, probably via a ThreadLocal.

I hook the servlet.init() method to activate application init code (init on the web app ctx point of view, not on the HttpServlet point of view).

Hello John,

Thank you for response.

I know that your intention was to reuse configuration for all application instances, and you are using servlet config for such single place.
As i mention, i used grails, so it was more natural for me to use spring singleton bean for configuration.

As a result, my approach is to implement Application.getNavigationConfig() to allow developer to obtain configuration from whatever he wants (servlet context, spring bean etc.). But also this allows developer to choose reuse strategy: he can use one configuration instance for all application instances (preferred way) or create different configurations.

By pages without uri i mean “secret” pages or pages that should not be called from browser address bar directly:
e.g. error page, access denied page, or in case of wizard (when few pages represent wizard steps), steps after the first one.

And about url’s look (to be clear): i don’t see problem with containing “#”.

Am i wrong that in Navigator7 you can’t have pages without uris?

For example: one window for application itself and the second one for administration part.
Using different windows i can have different urls for these zones (domain.com/ and domain.com/admin).

Also it could be required to have, for example extranet zone for logged in users (payed customers).
When windows are different it is easier to make different layout structures for them.

I tried both approaches (single window and multi window) and came to conclusion that multi window approach is more natural.

But, i should mention, that there is one problem with this approach: browser tabs. Vaadin now correctly handles browser tabs only for main window and for other windows there is no way to detect tabs.

I make a mistake at this point. I mean different parameter handling.
Nvigator7 has different stratagies for parameters handling (simple, JPA mapping)
But exact implementatin is application wide, so i can’t use one for some pages and the other one for the others.
(please, correct me if i’m wrong).

I took a little bit different approach: i have separated uri parser and parameters parser, so:

  • uri parser founds page uri part and parameters string and searches for page with this uri
  • parameters parser parses parameters string.

both uri handler and parameters handler may be specified for page or window, so for example,
one page could have url like “domain.com/app/#pageUri/param1/param2” and the other page url like
domain.com/app#group/page(para1|param2)”. (Example is little bit not natural, i just want to show that this approach should avoid any limits)

For parameters part, for example, it may be required to secure parameters string, for example apply md5 to it: in this case i will need to provide parameter parser impl which will decode and ancode parameters string and leave generic uri logic untouched.

In fact it is not a problem of navigator7: it was consequence of my turn to multi window approach.
When i have few windows, i want to separate pages between them (but still share some pages).
First of all i tried to extend navigator7 configuration approach, but it begin to look like a mess. At that point i remember groovy builders and thought that I want something similar - simple tree structure which will allow me to see pages structure naturally.

And about annotations, i drop this approach because of:
the first thing i did with Navigator7 was addition of classpath scanning (using scannotation); It was great at first but sooner (when pages count grows) i feel little lost: i have to always remember site structure.

Anyway it is just a personal preference: i think it is better to have “static sitemap” (more obvious).

One important note(!):
Novigator7 is production proved library, while my nf4v is little bit “academic” work - i didn’t used it in a big project. (It was intended, but plans were changed)

Hi Vyacheslav,

Vaadin has no xml configuration file, and usually configurations are done via de Java code. What about the code below? Does it give a “site map overview”?


        registerPages(new Class[] {
                DashboardPage.class,
                EditorPage.class,
                TicketPage.class,
                ParamTestPage.class,
                ProductAPage.class,
                ProductBPage.class,
                SeoPage.class,
        });

I’ve gathered some requirements from the forum, that we want in Vaadin 7 navigation. Don’t hesitate to suggest more in this forum.

http://code.google.com/p/navigator7/wiki/RequirementsForVaadin7

Hi John,

Yes, indeed.
I just tried to say that page annotations are redundant. They didn’t provide any benefit.

Isn’t it better to have all navigation info in one place (page class and uri)?


context("main").window(MyWindow.class);

inContext("main")
         .page(DashboardPage.class).uri("dashboard")
         .page(EditorPage.class).uri("edit")
         .page(TicketPage.class).uri("ticket")
         .page(ParamTestPage.class).uri("params")
         .page(ProductAPage.class).uri("productA")
         .page(ProductBPage.class).uri("productB")
         .page(SeoPage.class);