-
Notifications
You must be signed in to change notification settings - Fork 16
01. Motivation & Concepts
Based on a discussion at Gitter the idea of creating Nalu was developed.
The main goal was 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.
- Parameter Constrains
- History Support by default.
- Separation of views into a controller and a component with framework sided instantiation.
- A controller life-cycle using
start-,mayStop- andstop- similar to GWT Activities & Places. - 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 (handler registrations must be added to the manager).
- UiBinder-Support (nalu-plugin-gwt)
- 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
- Tracking Support
- Multi Module Support
Keeping these requirements in mind the implementation of Nalu was started.
The basic idea of Nalu is to use a String to route between screens. In the context of a web application this is done using a hash which gets added to the url. Based on the fact that every controller in Nalu is related to a route, Nalu is able to identify controllers, create controllers and add controllers to the DOM.
Parameters are also added to the route, so there is no need to create a place (like it is necessary in GWT 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 one and add the new.
Let's compare GWT Activities & places with Nalu and see, what are the key differences:
| Feature | GWT | Nalu |
|---|---|---|
| J2CL-Ready (in case the org.gwtproject.*-modules are used) | Yes | Yes |
| MVP-Pattern | Yes | Yes |
| Composite-Support | No | Yes |
| Handler-Support | No | Yes |
| Block-Controller-Support | No | Yes |
| PopUp-Controller-Support | No | Yes |
| History-Management | Yes | Yes |
| Client-Factory | Yes | Yes |
| Filter | No | Yes |
| Component Caching | No | Yes |
| Multi-Shell-Support | No | Yes |
| Parameter Constrains | No | Yes |
| Tracker | No | Yes |
| Multi Module Support | No | Yes |
All visual components in Nalu are implementing the MVP-Pattern. The equivalent of the GWT Presenter is in Nalu a controller and the GWT View is the component.
You will find this pattern for:
Nalu controller & components have a similar life cycle like GWT Activities. Nalu and GWT both support a start-, mayStop- amd stop-method.
Nalu also support component caching.
In Nalu you can separate a visual component into smaller components. This smaller pieces are called Composites. Composites have a controller and a component - similar to components, but can not be attached to route. Composites can only be used inside components.
The benefit of composites are:
- composites can be reused
- composites can be used to cache parts of a component
- divide visual components into smaller units of work to improve maintaining.
See: Composite Documentation for more information.
GWT Activities & Places does not support composite creation.
Nalu supports Handler. Handler are controllers without a visual component. Nalu will create the handlers at application start. Handlers are listening for events to get triggered.
See: Handler Documentation for more information.
GWT does not support handlers.
A block component in Nalu is an always visual component.
See: Block Documentation for more information.
GWT Activities & Places does not support block components.
Nalu supports popups. Popups in Nalu have also controllers and components and get triggered using a special Nalu event.
See: Popup Documentation for more information.
GWT Activities & Places does not support handlers.
GWT and Nalu, both support history management. The back-, forward- and reload-button works as expected.
Using GWT you have to create an activity and a place, containing the Tokenizer, for each screen.
Nalu supports history management by default. No need to implement anything. In Nalu, you don't have Activities nor Places. Nalu uses routes to manage history and to navigate. A route in Nalu has all informationen needed to restore a place. The route contains all needed keys and the router inject the keys into the controller. All you need to do is to implement a method, that accept a String and is annotated it with @AcceptParameter. See: Routes for more information.
In GWT it is a good advice to have a ClientFactory. The advantage of a ClientFactory is to improve DI and to enable different implementation.
That's something you do not need to worry about in Nalu. The key components of a Nalu application:
- Router to manage navigation and history
- Event Bus to handle events
- Context client sided session store
are automatically injected into every controller, handler, filter, tracker etc.
GWT Activities does not support DI. It needs additional implementations.
Nalu supports Filter to intercept a routing. Once a routing (navigation to a new screen) occurs, Nalu will use the filter to check if the routing can be done or not.
GWT Activities does not support filtering out of the box.
Nalu supports component and composite caching.
This means, you can reuse components and composites.
GWT Activities & Places does not have component caching.
GWT Activities and Places support one visual area where the dynamic components of an application will be presented. If you want to change the visual area or divide it into more areas where components should be presented, it gets very difficult.
Nalu supports several shells and a shell in Nalu can have more than one visual area. See Shell for more information.
GWT Activities & Places does not have multi shell support.
Nalu supports parameter constrains for parameters inside a route. You can use parameter white- or black-listung or use regular expressions to check a parameter. Nalu will validate the parameter against the constraint before injecting it into the controller.
See: Controller Documentation for more information.
GWT does not support parameter constraints.
Nalu will call a tracker anytime a routing occurs. This might be helpful in case you want to do something in case a routing occurs.
See Tracking for more information.
Nalu supports the creation of modules. A Nalu module is a separate Maven module. The classes of a module are invisible to other modules. So, you can create domain specific modules to organize your application. Another advantage of a module is, once you are working with J2CL, smaller units get transpiled faster.
See Multi Module Support for more information.
GWT Activities & Places does not support modules.
Nalu is a J2CL ready replacement for GWT Activities & Places with less code to write and more features.