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

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.