-
Notifications
You must be signed in to change notification settings - Fork 0
Home
The Quantum (dsweb) framework tries to bring modern web development techniques to Java (GWT). It's most similar to the well known AngularJS, except that it uses imperative Java code to build views with type-safe declarative data binding, instead of html templates.
- Type-safe, two-way data binding with automatic propagation.
- Imperative view creation
- Clear component API
Data and action binding is provided by the ds-bean framework. It generates static property literals similar to those you might know from Hibernate/JPA metamodels. It looks like:
label.bind(Bindings.obs(person).get(Person_._name));
Note that things are compile-time checked and type-safe.
It's common with Javascript frameworks to use html templates, but Java guys like type-safety and it's hard to use type-safe bindings with html templates. We've also found that in large applications html templates easily get messy (we've also switched to imperative view building with JSF). The main benefit is that things are navigable and discoverable from your IDE. Views still look declarative in most cases, but in special cases when the common builders are not enough, you can still use imperative code. The main idea is still that views should be as dumb as possible, not containing any logic. A quick example:
// the view
new Label().appendTo(container).bind(bindOnPresenter().get(Presenter_._greeting));
new InputText().appendTo(container).bind(bindOnPresenter().get(Presenter_._name));
new Button("Greet").appendTo(container).click(presenterMethod(Presenter_.__greet));
// the presenter
@ObservableProperty
private String name;
@ObservableProperty;
private String greeting;
@MethodRef
public void greet() {
setGreeting("Hello " + name);
}
The API is designed so that you can write your views as easy as possible, though the declarative approach does have a learning curve (that can be well reused with Angular and other frameworks).
Components encapsulate their complexity, so that view creators can focus on the view model. Components are split in three: Builders, Models and Renderers.Each component has a clear component model, that reflects the state that can be used in a presenter. A label has a text, a select has a selected value and options. Such stuff. Builders provide convenience methods so that your view code can look simple. Renderers do the magic with ensuring that the HTML DOM is always in sync with the component model.
Quantum works well for business applications. Though Quantum quite easily integrates modern web components, Quantum components are always bound to the view model and there's no easy possibility for "quick hack" interactions between them. It is desirable to hide component complexity from screen implementors. If your page would contain many rules like 'when hovering this, that should fade in', Quantum components will not serve you well.