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
Large forms
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
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
Re: Wicket capability for LARGE forms
You are aware of what you are doing to your browser? There is a limit to the pain you can cause. I'm calling the People for the Ethical Treatment of Web Browsers! Seriously: there is a limit to the number of form controls you can put in a page (around ~1000 iirc) Martijn On 8/30/07, Antony Stubbs [EMAIL PROTECTED] wrote: I have a couple of pages with _very large forms_, that are also modified dynamically to set which fields are editable using javascript, dependant on the value of a drop down list. Please see the example image attached. And that's only the first page the application is in - *gasp* - struts. I love what I've seen so far with Wicket, but I'm unsure what it's like to use compared to say, Stripes, Struts 2, Click, Tapestry etc when it comes to very large forms. being that setting up each field in wicket is kinda verbose... What are people's experiences? How do you find Wicket to use in very large forms? Thoughts? Ideas? Alternatives? (disclaimer - I've only written one page in Wicket, and that was just playing around with Ajax (NCE!! :))) http://www.nabble.com/file/p12398507/bigForm.png -- View this message in context: http://www.nabble.com/Wicket-capability-for-LARGE-forms-tf4351285.html#a12398507 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wicket capability for LARGE forms
I have a couple of pages with _very large forms_, that are also modified dynamically to set which fields are editable using javascript, dependant on the value of a drop down list. Please see the example image attached. And that's only the first page the application is in - *gasp* - struts. I love what I've seen so far with Wicket, but I'm unsure what it's like to use compared to say, Stripes, Struts 2, Click, Tapestry etc when it comes to very large forms. being that setting up each field in wicket is kinda verbose... What are people's experiences? How do you find Wicket to use in very large forms? Thoughts? Ideas? Alternatives? (disclaimer - I've only written one page in Wicket, and that was just playing around with Ajax (NCE!! :))) http://www.nabble.com/file/p12398507/bigForm.png -- View this message in context: http://www.nabble.com/Wicket-capability-for-LARGE-forms-tf4351285.html#a12398507 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket capability for LARGE forms
On 8/29/07, Antony Stubbs [EMAIL PROTECTED] wrote: I have a couple of pages with _very large forms_, that are also modified dynamically to set which fields are editable using javascript, dependant on the value of a drop down list. Please see the example image attached. And that's only the first page the application is in - *gasp* - struts. I love what I've seen so far with Wicket, but I'm unsure what it's like to use compared to say, Stripes, Struts 2, Click, Tapestry etc when it comes to very large forms. being that setting up each field in wicket is kinda verbose... Yeah, you definitively should not just add all these examples by hand :) What you do is e.g. use a DataTable component. The data provider would return the rows, and you define the columns on that data table. Rest should be straightforward. Don't forget to set the itemReuseStrategy if you're working inside a form (e.g. to use ReuseIfModelsEqual). Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket capability for LARGE forms
Ah yes, DataTable, I see, like a data grid... And what about changing the fields to enabled / disabled? Staying within Wicket I suppose the nicest way would be ajax onChange behaviour on the initial drop down box? Eelco Hillenius wrote: On 8/29/07, Antony Stubbs [EMAIL PROTECTED] wrote: I have a couple of pages with _very large forms_, that are also modified dynamically to set which fields are editable using javascript, dependant on the value of a drop down list. Please see the example image attached. And that's only the first page the application is in - *gasp* - struts. I love what I've seen so far with Wicket, but I'm unsure what it's like to use compared to say, Stripes, Struts 2, Click, Tapestry etc when it comes to very large forms. being that setting up each field in wicket is kinda verbose... Yeah, you definitively should not just add all these examples by hand :) What you do is e.g. use a DataTable component. The data provider would return the rows, and you define the columns on that data table. Rest should be straightforward. Don't forget to set the itemReuseStrategy if you're working inside a form (e.g. to use ReuseIfModelsEqual). Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Wicket-capability-for-LARGE-forms-tf4351285.html#a12399482 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket capability for LARGE forms
yeah, with ajax instead of simply disabling them you can remove them completely, or replace them with something else entirely. however, if all you really want to do is to make them disabled on clientside that should work also. might not be as straight forward but should work. -igor On 8/29/07, Antony Stubbs [EMAIL PROTECTED] wrote: Ah yes, DataTable, I see, like a data grid... And what about changing the fields to enabled / disabled? Staying within Wicket I suppose the nicest way would be ajax onChange behaviour on the initial drop down box? Eelco Hillenius wrote: On 8/29/07, Antony Stubbs [EMAIL PROTECTED] wrote: I have a couple of pages with _very large forms_, that are also modified dynamically to set which fields are editable using javascript, dependant on the value of a drop down list. Please see the example image attached. And that's only the first page the application is in - *gasp* - struts. I love what I've seen so far with Wicket, but I'm unsure what it's like to use compared to say, Stripes, Struts 2, Click, Tapestry etc when it comes to very large forms. being that setting up each field in wicket is kinda verbose... Yeah, you definitively should not just add all these examples by hand :) What you do is e.g. use a DataTable component. The data provider would return the rows, and you define the columns on that data table. Rest should be straightforward. Don't forget to set the itemReuseStrategy if you're working inside a form (e.g. to use ReuseIfModelsEqual). Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Wicket-capability-for-LARGE-forms-tf4351285.html#a12399482 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
