Mission statement
This document describes what the Wicketizer is for.
Feeding Wicketizer will in turn provide you an Eclipse Project, which contains a complete runnable Wicket Application - without any further installation!
The wicket Application can be used to run Standalone as well as as a server.
You can use it as simple DB Access Tool on the one hand (Filter your Data, CRUD operations ).
But the key note is that you use its artifacts as Templates for your Webappp. That means that you just compose the Artifacts into your Application and change the Layout.
Base for all persistence is Hibernate. Therefore all you get is based on hibernate configuration files (the Feed).
Mostly any database can be used (limited to work with hibernate) - handling of database is OUT OF SCOPE here. I use H2 database - not only in this example.
Known Limitation
Do not use Columnname id! Microsofts Internet Explorer is not updating fields with name id via Ajax- wicketizer uses the db columnname as caption in all tiers.
If you use only Firefox, you do not have any problem even with columns with name id.
Ensure to use only Number / Integer for primary keys.
Short Description of what you will get.
Functional View
For each Entity (Table/View) you will get two Pages: One whichuses Ajax heavily and one which uses it mostly not.
Each Page(Ajax or not) consists of a Listpanel and and Editpanel
The Menu
All Pages are reachable to an Ajax menu. The Menu can be adapted and provide many Levels (I have tested to 5 hierarchy levels by now - but I am not aware of a limitation of Levels) in the Baseclass.
The Listpanel
... gives you a list of all entries you have (30 Entities per page as default). You can Filter your Entities by the embedded Filterpanel, for shrinking the List by providing Filter Criteria. You can select an Entry in the list via Link - that Entry will be displayed in Editpanel.
The Editpanel
... will give you CRUD operations for the current Entity.
Security
... can be changed in Parent Class of Wicket Applications (MBOApp), by default all Pages are in Security Context (see WicketPage for changing that).
Technical View:
just as an insight ....
Model
... is a LoadableDetachable Model (see Wicket Examples for details)which is embedded in other Models (either Model or Compoundmodel).
That reduces Memory usage significantly: Only Identifier and nonpersistent Data (like Filtercriteria, no of sublist /amount of Sublists for PagebyPage, ...) will be hold in Memory, at the end of the request cycle all other data will be persisted).
Page by Page
... is realized by a class I call DataViewport. It will select (via hibernate - a little tricky:-) only a sublist of 30 items and will hold the current sublist number and the max of Sublists. It further has methods to check if the current position is the first or the last and if there is a previous sublist or a next sublist (this position Data is not persisted in LoadableDetachableModel. That call is only done on READ -that differs from default behaviour of LoadableDetachable Models which loads multiple time per Request ...).
DAO
You will get a DAOs (using HQL) per Entity.
Jetty
... is embedded to provide a simple start.
Marcus Bosten
20090315