Many thanks for all the options!
Since I'm on the subject of large forms, I was wondering what you opinion of
appropriate class / db design is for such cases (300+ fields)? I was
thinking of splitting the form into a number of sub-forms each with its own
entity / table. The main issue with this
Hi,
read here for a start:
http://stackoverflow.com/questions/12120256/generate-html-from-java-beans-at-compile-time
Have fun
Sven
On 23.02.2015 17:10, ChambreNoire wrote:
Hey there,
In the case of large forms with 20+ fields, how should one go about coding
the wicket components? I have a
Yes I'm aware of WicketRAD and WicketBeans but both projects appear to have
been abandonned. I take it there's nothing more recent? I'll have to
implement something myself (and these two projects will certainly be useful
for inspiration).
Thanks
CN
--
View this message in context:
Hi,
You may take a look at Apache Isis http://isis.apache.org as an more
sophisticated alternative of WicketRAD and WicketBeans.
It provides out of the box both Wicket viewer and RESTful (JAX-RS) viewer
for your entities.
The drawback is that it uses JDO/DataNucleus as ORM. DataNucleus is better
We have developed something like this at our company, and open sourced it a few
months ago.
Take a look at https://github.com/premium-minds/wicket-crudifier
Sorry, but we have yet to provide proper documentation and examples.
There is, as of today, an example here
I have solved it by creating a code generator, that for each POJO passed,
it makes physical html, java and properties files at given package path.
According to the template you pass to the generator, it can generate any
code for you.
Drawbacks
Once generated, there is no link between POJO and
Every code provided by the community helps the community, so it would be great
to see it on Github. :-)
Thank you.
kind regards
Tobias
Am 24.02.2015 um 08:10 schrieb Vit Rozkovec rozkovec...@email.cz:
I have solved it by creating a code generator, that for each POJO passed,
it makes
