Now for the downsides and gotchas:
The use of javabeans depends on java.beans.Introspector
https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/beans/Introspector.html
among the catches are:
- the fields / properties returned are not in source code order
(accordingly, there isn't a formal/proper way to get it in that order)
- fields like "class" (shown in the prior example) are retrieved as
properties
hence a 'solution' is needed. From the javadocs for Introspector above:
For each class "Foo", explicit information may be available if there
exists a corresponding "FooBeanInfo" class that provides a non-null
value when queried for the information. We first look for the BeanInfo
class by taking the full package-qualified name of the target bean class
and appending "BeanInfo" to form a new class name. If this fails, then
we take the final classname component of this name, and look for that
class in each of the packages specified in the BeanInfo package search path.
Thus for a class such as "sun.xyz.OurButton" we would first look for a
BeanInfo class called "sun.xyz.OurButtonBeanInfo" and if that failed
we'd look in each package in the BeanInfo search path for an
OurButtonBeanInfo class. With the default search path, this would mean
looking for "sun.beans.infos.OurButtonBeanInfo".
---
This means that the fields to be displayed can be 'configured' in the
Beaninfo class, e.g. in the getPropertyDescriptors() method.
I've tested that and it causes those fields specified in the BeanInfo
class's getPropertyDescriptors() to be returned.
However, it is still not in source code order.
Hence, I hacked the Beaninfo class added a method e.g. getFieldOrder()
which would need to list the fields in the appropriate order in a
String[] array.
Then that I sorted the properties according to it.
Well, this works and the HTML table display appropriately.
Unfortunately, this practically means that the 'configuration' shifted
from the templates into the BeanInfo class, practically.
It is a 'good and bad' thing, BeanInfo class and field ordering can be
shared by several components processing it. (a slight improvement over
templates)
But that it means maintaining a separate BeanInfo class for each Bean class.
On 16/04/2025 21:38, andrew goh wrote:
Taking in context:
https://gist.github.com/ag88/a0232510c28b4c45b82943527b7ea87e
The templates:
DataListPanel.html
<wicket:panel>
<table id="dataitems" class="table table-striped">
<thead class="table-secondary">
<th class="col-md-1" wicket:id="hdrRepeater"></th>
</thead>
<tbody>
<wicket:container
wicket:id="dataRepeater"></wicket:container>
</tbody>
</table>
</wicket:panel>
DataRowPanel.html
<wicket:panel>
<tr>
<td wicket:id="dataField" class="col-md-1"></td>
</tr>
</wicket:panel>
And in the demo app where it is implemented
https://github.com/ag88/wickettest1
expands to:
<table id="dataitems" class="table table-striped">
<thead class="table-secondary">
<th class="col-md-1">class</th><th
class="col-md-1">firstname</th><th class="col-md-1">lastname</th>
</thead>
<tbody>
<tr>
<td class="col-md-1">class
com.wicketest.pages.DataListExample$Person</td><td
class="col-md-1">Smith</td><td class="col-md-1">John</td>
</tr>
<tr>
<td class="col-md-1">class
com.wicketest.pages.DataListExample$Person</td><td
class="col-md-1">Johnson</td><td class="col-md-1">Emily</td>
</tr>
...
</tbody>
</table>
--------------
Even if for that matter say that I specify each column (field) in the
template the template itself would be fairly verbose.
Apache Wicket components practically reduced the templates to 'regular
expressions'
<table>
<thead> <th>*</th><thead>
<tbody><tr><td>*</td></tr></tbody>
plus the javabeans, it literally fills in those *, given the javabean,
generic, reusable.
Yes, I think this design pattern made possible by Apache Wicket matters.
On 16/04/2025 20:54, andrew goh wrote:
Thanks, Rob Audenaerde
I'd check out ISortableDataProvider and DataTable.
I did this 'experiment' as I'm using handcrafted Bootstrap
https://getbootstrap.com/ based pages.
And in part coming from spring-boot and Thymeleaf templates, I'm
starting to have a lot of HTMLs in the templates and rather often
repetitive blocks.
Hence, creating these components in part to keep the 'look and feel'
consistent with 'Bootstrap' style of pages and that the Apache Wicket
components
abstracts away the verbose HTMLs making them far more concise vs
littering them in templates.
I think in spring-boot + Thymeleaf, what is normally done is to build
a 'dialect' and abstract those components away. But that without
doing so, HTML codes repeat and proliferate, e.g. for the likes of
forms, tables etc.
I'd nevertheless try out ISortableDataProvider and DataTable. to see
how they works and possibly use them where they are appropriate.
On 16/04/2025 19:23, Rob Audenaerde wrote:
I'm also not actively working with Wicket anymore (a shame), but we
made
extensive use of the `ISortableDataProvider` and `DataTable`. It
should not
be to hard to create a `BeanSortableDataProvider<T>` and a class that
generated the `AbstractColumn<T, S>` from the beans?
On Wed, Apr 16, 2025 at 12:56 PM andrew goh
<gohand...@yahoo.com.invalid>
wrote:
I think some of these stuff may be good to be added in
https://wicketstuff.org/
But for now this is very rough and 'only about works'.
Back in the 'early' days of GUI development, there has been lots of
re-usable GUI data components, e.g. the old Powerbuilder data windows
https://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.dc00044_0250/html/dwprgnet/CHDHFGCJ.htm
For some reasons, that art is 'lost' and it became 'scripting in
templates' jsp/etc, yup there is MVC and all, but that 'scripting in
templates' seemed to become an 'accepted norm' for web development. It
starts to get on my nerves when I realised that I'm copying lots of
(HTML+script) codes between forms, the HTML is verbose often much more
so than the java codes and error prone, missing tags / closures, they
are very state dependent (e.g. after you 'display' an error, forget to
'hide' it etc) upon submit etc.
Hence, I looked elsewhere for a solution and I stumbled into Apache
Wicket.
Apache Wicket and its components based design alleviates a lot of
that.
And I think it'd be good to explore further e.g. like what I'm trying
out currently give the forms or pages a Java Bean and the components
handle it fully. It can make database web apps a lot less verbose
to write
Cheers,
Andrew
On 16/04/2025 18:26, Jonathan Locke wrote:
Hi Andrew,
Interesting idea. I’ve been mostly away from Wicket for about 10
years
as a committer, but I’m drawn back to the project again by some
things I’d
like to see done that would provide more automation like this and also
improve support for CSS and JavaScript and more concise syntax for
fluency
in building UIs (I know this is one of Martian’s wishlist items). I
also
have some curiosity about whether Wicket could have core features that
might make integrations with client-side frameworks like React and
Angular
easy. The pipe dream there is that you might build a Wicket app
where there
are some richer client side components you’d like to work with in a
small
portion of the site.
I have a client right now that I’m working with on a system for
viewing
and editing models automatically, kind of like your bean table
project, but
for individual beans.
I think you’re thinking along the right lines in general. My
client and
I would ideally like to find one or two other companies with a
financial
interest in conquering some of these complexities. I think for some
very
complex apps, what we’re working on could yield significant cost
savings.
It would be a further good if our project were sufficiently useful
to other
parties that it would make a good, solid addition to wicket core or
wicket
extensions.
If we can find some other interested parties, I might be able to
work on
these problems full time. Additionally, we would have more
perspectives and
possibly some assistance with implementing some of these design I am
flushing out now.
Let me know if you know of any interested parties and please keep us
posted on your bean table project. I’m interested in how that goes
and what
design you come up with.
Best,
Jon
Sent from my iPhone
On Apr 16, 2025, at 3:26 AM, andrew goh
<gohand...@yahoo.com.invalid>
wrote:
While I'm learning the ropes of Apache Wicket currently and I'm
exploring making reusable components.
I tried making An Apache Wicket reusable Data List
This component displays a list of JavaBeans as a html table
DataListPanel takes as input in the constructor :
the wicket:id of the component
itemclass The java class of the JavaBean
List items the list of JavaBeans
https://gist.github.com/ag88/a0232510c28b4c45b82943527b7ea87e
This version is pretty rough as I'm trying out a 'proof of concept'
test.
it actually works, rendering the list of JavaBeans as a html table.
I used an often 'neglected' java package java.beans, technology
Javabeans
https://en.wikipedia.org/wiki/JavaBeans
https://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/
practically as 'old' as Java itself.
It is probably quite interesting as many database interfaces
basically
use JavaBeans to represent the records and as well used in forms.
This practically makes the task of displaying records in a (html)
table
done using a reusable component.
It is likely possible to implement similar setup say with
spring-framework, spring-boot and templates, but that Apache Wicket
makes
the codes and templates very concise.
The magic is implemented by the repeating views
https://nightlies.apache.org/wicket/guide/9.x/single.html#_the_repeatingview_component
and java.beans itself which I get the 'field' (beaninfo) names
and java
reflection retrieval.
I think it is likely feasible to implement such reusable pages as
form
components too, i.e. give a form a JavaBean it renders it and
handles/process it with database CRUD and all.
Cheers,
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
