Re: Large forms
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 would be doing lots of db joins - especially considering that the fields to sub-form ratio would vary (some could have up to 30 fields and others as little as one). There's also the EAV approach but there seem to be many conflicting opinions on this. I'm currently using a relational db but a move to nosql would be possible if it would greatly simplify this issue... CN -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Large-forms-tp4669718p4669748.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large forms
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 large form of over 300 fields divided into 20 pages to code. Instantiating and wiring up each of these one by one would take an age. Any ideas? Many thanks, CN -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Large-forms-tp4669718.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large forms
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: http://apache-wicket.1842946.n4.nabble.com/Large-forms-tp4669718p4669720.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large forms
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 than Hibernate (IMO) but not so popular ... Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Feb 23, 2015 at 6:36 PM, ChambreNoire a...@tentelemed.com wrote: 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: http://apache-wicket.1842946.n4.nabble.com/Large-forms-tp4669718p4669720.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large forms
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 https://github.com/froque/wicket-crudifier-example best regards, flip - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large forms
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 generated files, if you change POJO, you have to run the generator again, overwrtiting existing files at given path. Therefore it is necessary to move your files to another package and once you add your custom code, transfer new generated changes by hand. May not be the best approach, but this way you can fully customize generated files, they are the same files you woud prepare by hand, only automatically generated. Would you be interested in using such a tool? So far I have used it just for me, but can make it available at Github if you would like. Regards Vit Rozkovec Dne 23.2.2015 v 17:10 ChambreNoire napsal(a): Hey there, In the case of large forms with 20+ fields, how should one go about coding the wicket components? I have a large form of over 300 fields divided into 20 pages to code. Instantiating and wiring up each of these one by one would take an age. Any ideas? Many thanks, CN -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Large-forms-tp4669718.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large forms
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 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 generated files, if you change POJO, you have to run the generator again, overwrtiting existing files at given path. Therefore it is necessary to move your files to another package and once you add your custom code, transfer new generated changes by hand. May not be the best approach, but this way you can fully customize generated files, they are the same files you woud prepare by hand, only automatically generated. Would you be interested in using such a tool? So far I have used it just for me, but can make it available at Github if you would like. Regards Vit Rozkovec Dne 23.2.2015 v 17:10 ChambreNoire napsal(a): Hey there, In the case of large forms with 20+ fields, how should one go about coding the wicket components? I have a large form of over 300 fields divided into 20 pages to code. Instantiating and wiring up each of these one by one would take an age. Any ideas? Many thanks, CN -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Large-forms-tp4669718.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
