Introduction

---

This project is built on top of other amazing open source frameworks:

• wicket for its ability to reuse components while maintaining flexibility and control
• twitter-bootstrap for its superb layouting capabilities and responsive grid layout
• wicket-bootstrap for its amazing twitter-bootstrap integration for components and other goodies
• invesdwin-norva for a unified and naked objects aware reflection and visitor API
• ecs and jsoup for their easy HTML generation, parsing and formatting APIs
• Optional: spring-security and apache shiro for their almighty security capabilities and easy configurability

In comparison to other naked objects frameworks, this is not a full blown CRUD framework:

• It aims at being a lightweight web framework instead of being a development platform. You still use your tools of choice for dependency injection, container management, application integration, persistence management, etc.
• It does not abstract away Wicket or the HTML used with it, but instead embraces it by doing the routine work for you, allowing you to fully customize it to your layout and design requirements. It allows you to do this directly in the HTML instead of forcing you to use CSS for everything or some sort of domain specific language or abstract API.
• Same goes for the binding, instead of doing all the work behind layers of walls, you can tap into any part of the binding and provide your own components particularly where needed, as needed.
• It always allows you to do anything you are able to do with Wicket. Following the Pareto principle, this enables you to take control over those 20% complex requirements while not having to waste time implementing the standard 80% of requirements.
• It is also suitable for rapid prototyping of web applications while not requiring you to throw away the prototype, but instead just continuing work on it to make it a full application.

This framework also improves Wicket development in a few other spots:

• By enforcing a clean use of the MVC pattern in your code (Wicket still allows you to store state in page classes or spread it over lots of micro models), you can easily write automated unit tests for the logic of your models. They control most of the functionality of your pages, can run headless and can be tested easily with this framework. Only write those brittle Selenium or WicketTester tests where actually needed, but not to validate your logic of the presentation layer. Instead do it typesafe and much more robust on the models themselves.
• The browser back button support of Wicket is nice, but it does not easily remember page state when reentering a page from a bookmarkable link or other means of redirects in your application. Also you can get lost in old page states easily when navigating in the browser. This framework eases this by using a lightweight session based page cache that lets it feel more like a single page application when you want it to. Just override the hashCode and equals methods in your models appropriate to your needs and NoWicket will reuse pages and models where the same logical model state is used (still allowing you to keep full control by deciding otherwise in the onPageModelRefresh hook of your page).

---

Framework Slogan

---

Your typical development process with this framework would be (as an elaborate example):

1. Divide your desired page into a set of classes using the naked objects pattern in your mind or design it using a class diagram. You can even reuse existing transfer or persistence classes without modifying them where appropriate (being able to extend them from the outside using @BeanPathRedirect).
   => Your benefit: Your models reflect directly your UI both in naming and in structure.
2. Write your models appropriately and choose the model elements depending on the information that is to be visualized. Also decide for each class if it should be a page or a panel (or even both) by creating appropriate classes for those. Add complex validation, tooltips, hiding, disabling, redirects, modals and other presentation logic to your models.
   => Your benefit: Only one place that contains the important state information.
3. Run the NoWicket HTML generator for your models to get bootstrappified markup which normally takes a long time to write down and do right for some components.
   => Your benefit: Write less HTML code yourself.
4. Refine the generated HTML manually by moving things where you want them and visualize regularly in the browser to make adjustments. You could also use a WYSIWYG editor here. You can make full use of the bootstrap grid layout or remove all of the tags and write your own classic table layout.
   => Your benefit: A lot less refactorings in Wicket code, since the generated binding handles Wickets binding hierarchy automatically.
5. Modify the generated properties files to name the components as you want them, add some button icons or internationalization to your pages. Note that all strings returned from the model are internationalizable since you can also just return keys for the properties files as desired.
   => Your benefit: No need to lookup Wicket IDs since they get generated with texts from your models. Only change texts as needed.
6. If you are missing some components, just add them to the model and run the HTML generator again. It will merge the new markup snippets into your existing HTML files without destroying your manual changes in them. After they are in there, just move them as well to where you want them. If you want to undo some of your changes, just delete the desired tags to let them get generated again. The generator always checks for the Wicket IDs before generating anything.
   => Your benefit: No need to redo everything, instead merge changes.
7. If you are unhappy with some components, just change the tags to transform them. For example:
   • convert a text input into a password input or a text area
   • convert a select box into a radio input or set a size to make it into a list
   • change a button into a link
   • convert a table into a ul for a ListView of panels
   • make a file upload input handle multiple files
   The framework aims to be flexible and intuitive with this. If the automated binding does not support your desired changes, just enhance the binding manually by adding a BindingInterceptor for your special cases. Do the same for any components that are not represented in your models and are thus unknown to the generated binding.
   => Your benefit: Only write binding code for the components you have to.
8. Add complex features into your page or panels, utilizing the element and component registry in the NoWicket HtmlContext. This gives you access to the Wicket components and invesdwin-norva reflection elements that got generated. Or access the page model directly to do some extended manual binding. For example handling page parameters or the page lifecycle.
   => Your benefit: Full access to everything.
9. Last but not least, write some headless unit tests on your models logic as desired.
   => Your benefit: Stay maintainable for future refactorings and have something to alert on regressions.

If this got you interested, feel free to look at all the detailed explanations and examples of this guide available via the top menu bar, or just ...

continue reading the first chapter