v1 01. Motivation and Basic concepts

Motivation & Concepts

Based on a discussion on Gitter the idea of creating Nalu was developed.

The main goal is to create a tiny and simple to use application framework with the following characteristics:

• Full support of the browser's back- forward- and reload-button.

• An optional loader that will be executed at application start to load data from the server.

• A client side context, router and event bus which will be automatically injected in every controller. (Handler have only access to the context and the event bus)

• Filters to intercept routing.

• History Support by default.

• Separation of views into a controller and a component with framework sided instantiation.

• A controller life-cycle using start-, mayStop- and stop- similar to GWT Activities.

• Supports HTML links and programmatically routing thanks to a router.

• Controller based handler manager, that will remove all handlers from the event bus in case the controller is stopped to prevent memory leaks (handler registrations must be added to the manager).

• Support for UiBinder (nalu-plugin-gwt)

• Nalu composites to support smaller units

• Controller & component caching

• Component creation inside a controller to support GWT replacement rules and static factory methods

• Multi Shell Support

Keeping these requirements in mind the implementation of Nalu was started.

Basic Idea

The basic idea of Nalu is to use a String to route (will be called 'route') between screens. In the context of a web application this is done using a hash which gets added to the url. Because of the fact that every controller in Nalu is related to a route, Nalu is able to identify controllers, create the controllers and add the controllers to the DOM.

Parameters are added at the end to the route, so there is no need to create a place (like it is necessary in GWT's Activities & Places). In case Nalu identifies a controller, it will inject the parameters (which are defined by the route definition inside the @Controller-annotation) into the controller.

Nalu supports the usage of multiple shells. This is done by adding the shell's name as first part to the route. In case the shell changes, Nalu will look for a shell defined with this name, remove the old shell and add the new shell.

Routing

Nalu provides two ways of routing.

• The first way to navigate is to add the route to a link. The router provides a method that returns the generated hash.
• The second way is to call the route-method of the router. This method will create a new hash, updates the URL and routes to the new screen.

Application

It is necessary to have one application interface annotated with @Applicationand @Shells.

This annotations will define:

• the application context
• the start route
• the error route
• an application loader that will be executed at application start
• the shells of the application.
• the behavior in case of a empty hash

Shell

The area of the browser window where the application is running, is called shell in Nalu. A Nalu based application will always have one active shell which divides the viewport into several areas. These areas will be used by components to display the layout.

Controller and Components

Every visible area of a application shell can be used to display components. A component is defined by two classes:

• the controller class (similar to the presenter in the MVP pattern)
• a component class (similar to the view in the MVP pattern)

A controller is annotated with the @Controller-annotation. The annotation defines

• the route, which will activate the controller
• the selector which defines the place where to a the component to the DOM
• the component interface and class so that Nalu is able to create it.

A controller has a lifecycle. In case of routing, the current controller will be ask, if the controller can be left by calling the mayStop-method. If the routing can occur, the controller gets stopped and removed from the DOM. The new controller will be created an added to the DOM.