There exist two independent
predecessors of this framework that were used as inspiration:
- gengui: This
was the first implementation that was done with Swing
for the desktop and AjaxSwing
as an addon for web transformation of the Swing code. It was the
first one to define the idea of a naked objects framework like
this. The core concepts about how the framework should behave and
how the intelligent models should be coded originates from there.
- nocket
(previously codenamed DMDWebGen): This implementation was based on
Wicket and was using twitter-bootstrap 2.x.x
and custom developed components. It was reusing the concepts of
gengui, as well as code of its reflection API and applied it to a
more web like development paradigm.
Something Resembling History
![Something Resembling History]()
The following differences exist
between this framework and the other two:
- This framework shares no code with those and is a complete
rewrite. It shares only the core ideas and diverges in
implementation details.
- The parts where intelligent models (domain objects
called there) diverge most are in the use of different annotations
and the handling of tabbed panels. Also the @BeanPathRedirect used
here can rewrite complete bean paths (by changing the type of a
property) instead of just being able to decorate bean path end
points (which you can still do to add utility methods) as the
gengui @Decorate annotation does. The solution here is thus more
versatile.
- Complex custom validators that validate against
other model fields have become more intelligent and do not require
a @Eager workaround for the order of synchronization. Instead the
validators get called once more after valid properties have been
synchronized from the browser to the model to allow complex
validators to produce a correct result the second time.
- The new implementation tries to fix a few bad design
decisions and code smells of the previous implementation.
Especially inside the GuiService by dividing the concerns of
GuiTasks instead of implementing everything in one complicated
class that is hard to debug. Also the reflection API was tried to
be improved by introducing invesdwin-norva as an independent
framework.
- The reflection part is based on invesdwin-norva
which allows the bean path constants class generator to work as an
annotation processor. This fixes a nasty productivity problem with
refactorings of models: Previously the compiler and generator
would lock out the developer when the constants generator
failed, because the model cannot be compiled, because a bean path
constant from the constants class is referenced for which the
model element was renamed. It was quite tricky previously to work
around cases like these during refactorings. With the new solution
of switching to java source based processing using javax.lang.model
instead of java reflection on bytecode, the generator still runs
on model classes that do not compile completely, so the constants
are already there when the model needs to be actually compiled or
manually fixed.
- Instead of building most components from scratch,
this framework reuses open source solutions like wicket-bootstrap.
This results in higher quality and extensible components, better
bootstrap integration and better maintainability. Also the
paradigm how tables are bound is different here. Instead of using
table templates in the HTML, a more generic table tag is used with
the possibility to customize the table using a BindingInterceptor.
This removes refactoring intensive code from the HTML file and
reduces the overall code required to implement the table
component. Filtering and ordering table columns is still possible
using @Hide or the hideXyz utility method and via @ColumnOrder or
the columnOrder utility method.
- Modal dialogs have been simplified by reusing the bootstrap-modal
library and building on intelligent model based dialogs. The
decision was made to stay away from a callbacks based alternative
since it resulted in a switch of paradigm that is unnecessary.
- Instead of implementing a custom security layer,
spring-security and apache shiro were integrated as more versatile
providers in this regard.
- Paradigms that originated from desktop development were
ignored to favor ones that feel more aligned with Wicket and web
development.
- This implementation aims to be developer friendly
by providing helpful error messages and warnings about common
development problems where possible. Also this project aims to be
easily accessible by providing a comprehensive documentation.
This framework would not exist
without the work on the other ones and the people behind them. The
other frameworks still have valid use cases today and a plethora of
applications built with them. The reference on them here is made to
praise them and to highlight the differences between these
frameworks. This framework owes them a lot and is thankful that
they got open sourced as well.