Well, when going with the <ul> binding, you normally don't use any table tags and thus remove them from your html. The ordering/alignment can then be handled by your html code around in the <ul> in FooPage.html.
The BarPanel.html then defines the nested html code of each element. If you want to combine multiple elements into groups, you have to also group these via NoWicket.
So for your example you have:
<div class="container">
<ul wicket:id="rows" />
</div>
Inside a ContainerPage.html with a Container model:
public Container {
public List<Row> getRows(){...}
}
Then for the RowPanel.html:
<div class="row">
<ul wicket:id="cols" />
</div>
which has the Row model:
public Container {
public List<Col> getCols(){...}
}
And lastly the ColPanel.html:
<div class="col-*-*">
...
</div>
For your Col model which either defines the editor field directly as in the Dynamic Editor Fields example or wraps another panel which contains the actual editor field.
As can be seen in the live html generated for your browser, the <ul> tag is actually not rendered but only in the html files for metainformation that is being digested by the generated binding. The component it binds is as previously noted "de.invesdwin.nowicket.generated.binding.processor.visitor.builder.component.ModelRefreshingView" which disables rendering the <ul> tag via "this.setRenderBodyOnly(true);". You can make use of the same method to remove unwanted div or other tags from around your own nested panels.
Though as can be seen this involves quite some code with NoWicket and is feasible. But a more pragmatic approach would be to write a custom component for your layout needs in plain wicket as a replacement (via a binding interceptor) for the ModelRefreshingView and utilize wickets internal repeating abilities as described here:
https://cwiki.apache.org/confluence/display/WICKET/ListView+and+other+repeatersThough there is more documentation available. At least this would lead to one less layer of panels needed and a bit less code. But it depends on the developer which approach is considered easier/faster.
Best regards,
Edwin