Re: Wicket Web Beans
Hi Josh, The last downloadable release (v 1.1) supports Wicket 1.3, and current trunk (1.2) supports Wicket 1.4. Some days ago Dan created a branch in which I'll try to migrate to Wicket 1.5 in the near future. From time to time, a new issue pops in the issue tracker, so I can say some people is using it. The project is only receiving migration updates and maintenance fixes. In case you don't know, the SourceForge site is not used anymore, please go to the Google Code site: http://code.google.com/p/wicket-web-beans/ Cheers, Daniel Josh Kamau wrote: Hi Guys, Is wicket web beans project still being developed? There is somewhere in the docs where its indicated that it supports wicket 1.3RC1? Is someone using it? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Web-Beans-tp3013497p3014807.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: Re Wicket Web Beans
Hi Thanks for that Nick. I guess I will investigate more on this, actually i did get to lookup Dynamic Forms and then linked to WWB. I will do some homework on this topic and bounce any questions. Thanks for that Niv On Tue, Aug 17, 2010 at 11:11 AM, Nick Heudecker nheudec...@gmail.comwrote: It sounds like what you're after is a dynamic form. This has been discussed several times on the list and used to be detailed in the wiki. It's pretty straightforward to implement. Hopefully this gives you an implementation option. On Mon, Aug 16, 2010 at 7:17 PM, Nivedan Nadaraj shravann...@gmail.com wrote: Hi Daniel Thank you for getting back so quickly. I used Hibernate that maps to entities in the table. Fields are defined by an administrator when he creates a new entity like Study(Hibernate entity for Study). There is a standard table called Study however if the administrator feels this new study he is creating requires additional fields he then will do the following Create Scenario: 1. Click a button to add new field 2. Provides the Field Name (either types it in or selects from a list of data dictionary fields) 3. Selects a data type from a drop down ( I have created this table with required data types so this can be sourced) 4. Enters a value for the new field. 5. Optionally, he must be able to provide the type of control this field will be linkedf to ( guess #4 and 5 are inter-related) or can WWB infer this? Not sure about this part. 6. On Save - The New field meta data is stored along with the data in another table that links to this meta data table. View/Edit Scenario: When a user reads or looks up this entity, it should bring back the general fields and the custom fields that were defined. Now, the UI should be rendered. Will I be able to use WWB in this scenario? I guess if I don't use WWB then, i have to stored field UI meta data along with values in separate tables and infer this when the UI is rendered. Will be quite a task. Thanks for your time Dan, I was planning on playing with WWB and see if my requirements can be met using WWB. Reg Niv
Re: Re Wicket Web Beans
Hi Daniel It is more of a dynamic form thinking of it I might investigate more on this in Wicket. But here is a link and is pretty much what we want to achieve using wicket https://redcap.vanderbilt.edu/consortium/videoplayer.php?video=form_editor_fields01.flvtitle=The+Online+Form+Editor+-+in+depth+%285+min%29text=referer=REDCAP_PUBLIC If you have done either using Wicket or WWB please let me know. Thanks Niv On Tue, Aug 17, 2010 at 11:32 AM, Daniel Toffetti dto...@yahoo.com.arwrote: Hi Niv, I'm not sure if I just get your domain model right, the closest I think you can get is something like this: http://jweekend.com/wicketwebbeans-examples-1.1/WebBeans/?wicket:interface=:0:2: :: Where you can have a list (a table) of fields, each with a name, a datatype and a value. But all values in each column will be represented with one single type of input field. Perhaps you can attempt to create a custom field for the value property, that renders a different input for each datatype, but I'm not sure if this can be done at all. One problem is, how to re-render the input if the datatype changes ? Don't think WWB allows that easily. Cheers, Daniel -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Re-Wicket-Web-Beans-tp2326481p2327733.html Sent from the Wicket - User 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 Wicket Web Beans
Hi Would like to know if some one has used Wicket Web Beans in their wicket projects? One of our requirements is to add fields at runtime and be able to render it on the front end. So in this case , I have no control of building the panels for some fields that are 'yet' to be created and to infer what UI component(textfield, drop downs, radio box) should be rendered when I try to view those fields on the front end. Also will I be able to add validation rules to these fields at the same time the field is defined? I am using Wicket as the primary framework for the web layer and hibernate for the backend. I am hoping that this toolkit will be helpful in addressing this requirement. If anyone of you have used this toolkit would like to hear about your experiences. I am yet to embark on this path but in the meantime welcome your thoughts. Thanks Reg Niv -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Re-Wicket-Web-Beans-tp2326481p2326481.html Sent from the Wicket - User mailing list archive at Nabble.com.
Re: Re Wicket Web Beans
Where does your fields come from ? In WWB, you have to provide beans, and configure them with annotations or beanprops files to control the way the beans are displayed. You can provide beans and they will be correctly displayed in a default way, with proper editing inputs according to the datatype of each field. But both the beans and the (optional) configurations need to be coded, you will not be able to provide WWB with a stream of isolated fields. Regarding validations, some are provided by WWB itself (required), anything else will be rather hard to add with standard WWB, but you can provide customized input field implementations (see customfields example). Of course those custom fields will not be used by default, you will have to configure the properties to use them. See live examples here: http://jweekend.com/wicketwebbeans-examples-1.1/WebBeans/ And the source code for the examples here: http://code.google.com/p/wicket-web-beans/source/browse/#svn/trunk/wicketwebbeans-examples/src/main/java/com/googlecode/wicketwebbeans/examples Hth, Daniel -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Re-Wicket-Web-Beans-tp2326481p2327195.html Sent from the Wicket - User 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: Re Wicket Web Beans
Hi Daniel Thank you for getting back so quickly. I used Hibernate that maps to entities in the table. Fields are defined by an administrator when he creates a new entity like Study(Hibernate entity for Study). There is a standard table called Study however if the administrator feels this new study he is creating requires additional fields he then will do the following Create Scenario: 1. Click a button to add new field 2. Provides the Field Name (either types it in or selects from a list of data dictionary fields) 3. Selects a data type from a drop down ( I have created this table with required data types so this can be sourced) 4. Enters a value for the new field. 5. Optionally, he must be able to provide the type of control this field will be linkedf to ( guess #4 and 5 are inter-related) or can WWB infer this? Not sure about this part. 6. On Save - The New field meta data is stored along with the data in another table that links to this meta data table. View/Edit Scenario: When a user reads or looks up this entity, it should bring back the general fields and the custom fields that were defined. Now, the UI should be rendered. Will I be able to use WWB in this scenario? I guess if I don't use WWB then, i have to stored field UI meta data along with values in separate tables and infer this when the UI is rendered. Will be quite a task. Thanks for your time Dan, I was planning on playing with WWB and see if my requirements can be met using WWB. Reg Niv On Tue, Aug 17, 2010 at 1:13 AM, Daniel Toffetti dto...@yahoo.com.arwrote: Where does your fields come from ? In WWB, you have to provide beans, and configure them with annotations or beanprops files to control the way the beans are displayed. You can provide beans and they will be correctly displayed in a default way, with proper editing inputs according to the datatype of each field. But both the beans and the (optional) configurations need to be coded, you will not be able to provide WWB with a stream of isolated fields. Regarding validations, some are provided by WWB itself (required), anything else will be rather hard to add with standard WWB, but you can provide customized input field implementations (see customfields example). Of course those custom fields will not be used by default, you will have to configure the properties to use them. See live examples here: http://jweekend.com/wicketwebbeans-examples-1.1/WebBeans/ And the source code for the examples here: http://code.google.com/p/wicket-web-beans/source/browse/#svn/trunk/wicketwebbeans-examples/src/main/java/com/googlecode/wicketwebbeans/examples Hth, Daniel -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Re-Wicket-Web-Beans-tp2326481p2327195.html Sent from the Wicket - User 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: Re Wicket Web Beans
It sounds like what you're after is a dynamic form. This has been discussed several times on the list and used to be detailed in the wiki. It's pretty straightforward to implement. Hopefully this gives you an implementation option. On Mon, Aug 16, 2010 at 7:17 PM, Nivedan Nadaraj shravann...@gmail.comwrote: Hi Daniel Thank you for getting back so quickly. I used Hibernate that maps to entities in the table. Fields are defined by an administrator when he creates a new entity like Study(Hibernate entity for Study). There is a standard table called Study however if the administrator feels this new study he is creating requires additional fields he then will do the following Create Scenario: 1. Click a button to add new field 2. Provides the Field Name (either types it in or selects from a list of data dictionary fields) 3. Selects a data type from a drop down ( I have created this table with required data types so this can be sourced) 4. Enters a value for the new field. 5. Optionally, he must be able to provide the type of control this field will be linkedf to ( guess #4 and 5 are inter-related) or can WWB infer this? Not sure about this part. 6. On Save - The New field meta data is stored along with the data in another table that links to this meta data table. View/Edit Scenario: When a user reads or looks up this entity, it should bring back the general fields and the custom fields that were defined. Now, the UI should be rendered. Will I be able to use WWB in this scenario? I guess if I don't use WWB then, i have to stored field UI meta data along with values in separate tables and infer this when the UI is rendered. Will be quite a task. Thanks for your time Dan, I was planning on playing with WWB and see if my requirements can be met using WWB. Reg Niv
Re: Re Wicket Web Beans
Hi Niv, I'm not sure if I just get your domain model right, the closest I think you can get is something like this: http://jweekend.com/wicketwebbeans-examples-1.1/WebBeans/?wicket:interface=:0:2::: Where you can have a list (a table) of fields, each with a name, a datatype and a value. But all values in each column will be represented with one single type of input field. Perhaps you can attempt to create a custom field for the value property, that renders a different input for each datatype, but I'm not sure if this can be done at all. One problem is, how to re-render the input if the datatype changes ? Don't think WWB allows that easily. Cheers, Daniel -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Re-Wicket-Web-Beans-tp2326481p2327733.html Sent from the Wicket - User 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: Wicket Web Beans 1.1 and Wicket 1.4
Ahh interesting thanks for telling 2009/5/21 John Patterson jdp2...@gmail.com: I just tried it out on 1.4 with no problems. It took about 2 minutes to edit the source - mainly by changing getModel() to getDefaultModel() etc Dan Syrstad-2 wrote: I think Daniel was going to start work on the Wicket 1.4 migration on the trunk sometime in the near future. Currently the trunk supports 1.3.5. -Dan On Wed, May 20, 2009 at 3:20 PM, nino martinez wael nino.martinez.w...@gmail.com wrote: Are there a trunk or something.. I'd really like to try it out. But im not going back to 1.3 todo it :) 2009/5/20 Daniel Toffetti dto...@yahoo.com.ar: danisevsky danisevsky danisevsky at gmail.com writes: Hi I wanted to try Wicket Web Beans 1.1 upload example but I get the following exception . Is Wicket Web Beans 1.1 incompatible with Wicket 1.4 rc4 or is reason of exception something else? Thanks for reply Hi, WWB 1.1 is compatible with Wicket 1.3.x, it's expected that a new version of WWB compatible with Wicket 1.4 will be released shortly after Wicket 1.4 goes final. hth, Daniel - 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 -- View this message in context: http://www.nabble.com/Wicket-Web-Beans-1.1-and-Wicket-1.4-tp23630336p23644633.html Sent from the Wicket - User 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: Wicket Web Beans 1.1 and Wicket 1.4
danisevsky danisevsky danisevsky at gmail.com writes: Hi I wanted to try Wicket Web Beans 1.1 upload example but I get the following exception . Is Wicket Web Beans 1.1 incompatible with Wicket 1.4 rc4 or is reason of exception something else? Thanks for reply Hi, WWB 1.1 is compatible with Wicket 1.3.x, it's expected that a new version of WWB compatible with Wicket 1.4 will be released shortly after Wicket 1.4 goes final. hth, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Web Beans 1.1 and Wicket 1.4
Are there a trunk or something.. I'd really like to try it out. But im not going back to 1.3 todo it :) 2009/5/20 Daniel Toffetti dto...@yahoo.com.ar: danisevsky danisevsky danisevsky at gmail.com writes: Hi I wanted to try Wicket Web Beans 1.1 upload example but I get the following exception . Is Wicket Web Beans 1.1 incompatible with Wicket 1.4 rc4 or is reason of exception something else? Thanks for reply Hi, WWB 1.1 is compatible with Wicket 1.3.x, it's expected that a new version of WWB compatible with Wicket 1.4 will be released shortly after Wicket 1.4 goes final. hth, Daniel - 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 Web Beans 1.1 and Wicket 1.4
I think Daniel was going to start work on the Wicket 1.4 migration on the trunk sometime in the near future. Currently the trunk supports 1.3.5. -Dan On Wed, May 20, 2009 at 3:20 PM, nino martinez wael nino.martinez.w...@gmail.com wrote: Are there a trunk or something.. I'd really like to try it out. But im not going back to 1.3 todo it :) 2009/5/20 Daniel Toffetti dto...@yahoo.com.ar: danisevsky danisevsky danisevsky at gmail.com writes: Hi I wanted to try Wicket Web Beans 1.1 upload example but I get the following exception . Is Wicket Web Beans 1.1 incompatible with Wicket 1.4 rc4 or is reason of exception something else? Thanks for reply Hi, WWB 1.1 is compatible with Wicket 1.3.x, it's expected that a new version of WWB compatible with Wicket 1.4 will be released shortly after Wicket 1.4 goes final. hth, Daniel - 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 Web Beans 1.1 and Wicket 1.4
I just tried it out on 1.4 with no problems. It took about 2 minutes to edit the source - mainly by changing getModel() to getDefaultModel() etc Dan Syrstad-2 wrote: I think Daniel was going to start work on the Wicket 1.4 migration on the trunk sometime in the near future. Currently the trunk supports 1.3.5. -Dan On Wed, May 20, 2009 at 3:20 PM, nino martinez wael nino.martinez.w...@gmail.com wrote: Are there a trunk or something.. I'd really like to try it out. But im not going back to 1.3 todo it :) 2009/5/20 Daniel Toffetti dto...@yahoo.com.ar: danisevsky danisevsky danisevsky at gmail.com writes: Hi I wanted to try Wicket Web Beans 1.1 upload example but I get the following exception . Is Wicket Web Beans 1.1 incompatible with Wicket 1.4 rc4 or is reason of exception something else? Thanks for reply Hi, WWB 1.1 is compatible with Wicket 1.3.x, it's expected that a new version of WWB compatible with Wicket 1.4 will be released shortly after Wicket 1.4 goes final. hth, Daniel - 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 -- View this message in context: http://www.nabble.com/Wicket-Web-Beans-1.1-and-Wicket-1.4-tp23630336p23644633.html Sent from the Wicket - User 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: Wicket Web Beans - An error occurred on the server. Your session may have timed out.
I have fixed the Localizer problem and committed it to the trunk. Thanks for pointing out the problem! -Dan On Tue, May 27, 2008 at 1:19 AM, Johan Compagner [EMAIL PROTECTED] wrote: getLocaliazer() in a constructor cant be done i guess because it will nog be able to find any resources, expect the application one On 5/26/08, Martijn Dashorst [EMAIL PROTECTED] wrote: When I use the BeanForm I consistently get this disturbing message in the feedback panel: An error occurred on the server. Your session may have timed out. It appears to be caused by: WARN - Localizer - Tried to retrieve a localized string for a component that has not yet been added to the page. This can sometimes lead to an invalid or no localized resource returned. Make sure you are not calling Component#getString() inside your Component's constructor. Offending component: [MarkupContainer [Component id = bean, page = No Page, path = bean.BeanForm]] And indeed, the BeanForm does this in its constructor: String serverErrorMsg = getLocalizer().getString(beanFormError.msg, this, An error occurred on the server. Your session may have timed out.); form.add( new Label(beanFormIndicatorErrorLabel, serverErrorMsg) ); (Lines 174 and 175) I've checked this in 1.0 and in 1.1-SNAPSHOT (built it fresh from trunk). Am I the first one to encounter this? Martijn
Re: Wicket Web Beans - wrong order of fields/buttons
Yes, the ordering changed a while back on the trunk (the change appeared in
1.0-rc2). It occurred due to a change in how actions are handled (hopefully
for the better). Anyway, you need to explicitly call out the actions and
properties in the beanprops props parameter (or @PropertyNames for
annotations). Actions are called out by saying: action.{action-name}.
I believe the Sourceforge WWB mailing list is working. Other posts are
coming through there.
-Dan
On Jan 23, 2008 9:45 AM, Zenrique Steckelberg [EMAIL PROTECTED] wrote:
First of all, congrats for such a nice tool, WWB has saved me lots of time
in
one of my projects!
I know it would be more appropriate to post this at WWB's mailing list,
but
I've sent an email 2 days ago but it seems it hasn't arrived there, so
I'll
try here: I've upgraded to the latest releases of Wicket (1.3.0) and
Wicket
Web Beans (WWB), everything went fine after I updated the bean prop files,
only thing is that the order of fields and action buttons in beantables
are
mixed now. They were respecting the order in which they were declared in
beanprop files before the upgrade. Has something changed in this versions
or
is it a bug?
TIA,
Zenrique Steckelberg
Re: Wicket Web Beans - wrong order of fields/buttons
Hey Dan, thanks for the help. I found out what's going on, I was
declaring all the actions in the actions bean property, and that somehow
affected the ordering. After I removed all but the actions which should
not appear (those with a minus before the action name), it worked fine!
Thanks again!
Dan Syrstad-2 wrote:
Yes, the ordering changed a while back on the trunk (the change appeared
in
1.0-rc2). It occurred due to a change in how actions are handled
(hopefully
for the better). Anyway, you need to explicitly call out the actions and
properties in the beanprops props parameter (or @PropertyNames for
annotations). Actions are called out by saying: action.{action-name}.
I believe the Sourceforge WWB mailing list is working. Other posts are
coming through there.
-Dan
On Jan 23, 2008 9:45 AM, Zenrique Steckelberg [EMAIL PROTECTED] wrote:
First of all, congrats for such a nice tool, WWB has saved me lots of
time
in
one of my projects!
I know it would be more appropriate to post this at WWB's mailing list,
but
I've sent an email 2 days ago but it seems it hasn't arrived there, so
I'll
try here: I've upgraded to the latest releases of Wicket (1.3.0) and
Wicket
Web Beans (WWB), everything went fine after I updated the bean prop
files,
only thing is that the order of fields and action buttons in beantables
are
mixed now. They were respecting the order in which they were declared in
beanprop files before the upgrade. Has something changed in this versions
or
is it a bug?
TIA,
Zenrique Steckelberg
--
View this message in context:
http://www.nabble.com/Wicket-Web-Beans---wrong-order-of-fields-buttons-tp15044863p15055721.html
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 Web Beans 1.0 (final) Released
Congrats, and wonderful work! I really hope this project takes off and is adopted by the wicket community! On Jan 14, 2008 6:57 AM, Dan Syrstad [EMAIL PROTECTED] wrote: Wicket Web Beans 1.0 (final) has been released. Wicket Web Beans (WWB) is an Apache Wicket component toolkit for displaying and editing POJOs that conform to the JavaBeans specification. Web pages are automatically generated based on bean properties and certain conventions. If necessary, the layout, editability, and actions of these pages can be customized on an exception basis. In other words, the toolkit normally does what you'd expect, but when it doesn't, you can override its behavior. Major inclusions in this release are the finalization of the Databinder integration and Wicket 1.3.0 (final) support. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0 (final) Released
+1, ditto I'm using WWB as a demo on how life as a webdeveloper should/could be. The only thing that would keep me from implementing it in projects now is the lack of good documentation (even the tutorial on the website is still partially in progress) and the small community that is using it. But anyway, it looks great and is a wonderfull project! On 1/14/08, Ryan Sonnek [EMAIL PROTECTED] wrote: Congrats, and wonderful work! I really hope this project takes off and is adopted by the wicket community! On Jan 14, 2008 6:57 AM, Dan Syrstad [EMAIL PROTECTED] wrote: Wicket Web Beans 1.0 (final) has been released. Wicket Web Beans (WWB) is an Apache Wicket component toolkit for displaying and editing POJOs that conform to the JavaBeans specification. Web pages are automatically generated based on bean properties and certain conventions. If necessary, the layout, editability, and actions of these pages can be customized on an exception basis. In other words, the toolkit normally does what you'd expect, but when it doesn't, you can override its behavior. Major inclusions in this release are the finalization of the Databinder integration and Wicket 1.3.0 (final) support. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0 (final) Released
Congrats! Eelco On Jan 14, 2008 4:57 AM, Dan Syrstad [EMAIL PROTECTED] wrote: Wicket Web Beans 1.0 (final) has been released. Wicket Web Beans (WWB) is an Apache Wicket component toolkit for displaying and editing POJOs that conform to the JavaBeans specification. Web pages are automatically generated based on bean properties and certain conventions. If necessary, the layout, editability, and actions of these pages can be customized on an exception basis. In other words, the toolkit normally does what you'd expect, but when it doesn't, you can override its behavior. Major inclusions in this release are the finalization of the Databinder integration and Wicket 1.3.0 (final) support. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans with Wicket 1.3b4 ?
Hi Daniel, If you check out the latest from the SVN branch branches/wicket-1.3-port, it builds with maven/1.3.0-beta4. The trunk is still for Wicket 1.2.6. The head of both the trunk and 1.3 branch are techinically wicketwebbeans-1.0-rc2SNAPSHOT. -Dan On 10/12/07, dtoffe [EMAIL PROTECTED] wrote: Hi ! Is Wicket Web Beans from SVN (rev 136 as of now) useable with Wicket 1.3b4? Should I stick to last (1.0 rc1) release with 1.2.6 ? Cheers, Daniel -- View this message in context: http://www.nabble.com/Wicket-Web-Beans-with-Wicket-1.3b4---tf4616136.html#a13183356 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 Web Beans 1.0-rc1 Released
On 9/15/07, Zenrique Steckelberg [EMAIL PROTECTED] wrote: - allow constructor to accept models besides beans too, if possible. Me too! :-) Or is there some other way to use DetachableModels backed by JPA with WWB? (The abbreviation conjures images of a tiny but venerable local railroad company somewhere in Germany :-) ) Gabor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0-rc1 Released
On 9/17/07, Gabor Szokoli [EMAIL PROTECTED] wrote: On 9/15/07, Zenrique Steckelberg [EMAIL PROTECTED] wrote: - allow constructor to accept models besides beans too, if possible. Me too! :-) Or is there some other way to use DetachableModels backed by JPA with WWB? (The abbreviation conjures images of a tiny but venerable local railroad company somewhere in Germany :-) ) For regular models, you should be able to pass model.getObject() directly to BeanForm. AbstractDetachableModels are probably a different story. For now, you can just do model.getObject(), but then bean form will hold onto the object. I'll add detachable model support to the Feature Request list on sourceforge. Gabor
Re: Wicket Web Beans 1.0-rc1 Released
Dan Syrstad wrote:
Sounds like this may be a caching issue - I'm not sure. Can you send me
your
beanprops file directly?
-Dan
Its the following, where marca field gets it options from database, and
temperaturaArmazenagem gets them from an enum:
Produtos {
actions: incluir, gravar;
props: produtos { colspan: 3 },
action.incluir { labelImage: images/add.png },
action.gravar { labelImage: images/accept.png };
}
Produto {
actions: remover;
props: nome,
marca { fieldType :
com.everyware.fsw.web.ui.MarcaField },
temperaturaArmazenagem { default : AMBIENTE },
descricao { fieldType :
wicket.contrib.webbeans.fields.TextAreaField ;
rows : 3; cols : 40 },
action.remover { confirm : Confirma remoção do item?;
labelImage:
images/delete.png },
-id;
}
Thanks for the help!
--
View this message in context:
http://www.nabble.com/Re%3A-Wicket-Web-Beans-1.0-rc1-Released-tf4431603.html#a12701667
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 Web Beans 1.0-rc1 Released
For me databinder helps cut the boilerplate code, just as WWB. I just add annotations to my domain model, and databinder does the rest. It's WWB for the database side of the app! Imagine putting both working together. I was able to create CRUD pages with the least amount of code ever. Less than that and it would need to read my mind... ;) Annotations have been a big win for Java. Many of their success stories have come out of their usage for configuration or metadata. I think that WWB may be a cantidate for using annotations instead of the beanprops file!
Re: Wicket Web Beans 1.0-rc1 Released
Although it may blur the lines between view and model, there are a number of reasons that it still could be the right direction. * centralized configuration. all view configuration is in the same file as your model code. * leverage Java syntax instead of custom DSL. easy for users to get up and going when they have autocomplete for annotation configuration. * annotations are metadata, and this configuration *is* metadata for the view layer. * configuration by exception works well with annotations. Hibernate applies the same principle. you only need to declare annotations when you want to change the default behavior. I do understand your disagreement. It's a very natural Java architecture to create abstractions and try to build to design patterns. Realistically though, there are times when it's just plain overboard. You could make the same argument that Hibernate annotations don't really belong in the model code since it's configuring the back end setup, but the beauty of annotations is that it's metadata that *any* layer has access to. I recently published a wicket/hibernate component that leverages the hibernate annotations to enforce view layer behavior (requiredness/max length). Talk about blurring the lines... I'm really impressed with your work, and just want to impart what's worked *really* well for me. Good luck with whatever direction you take. On 9/16/07, Dan Syrstad [EMAIL PROTECTED] wrote: Ryan: The WWB beanprops/metadata is a view abstraction, while your bean is a part of the model. It's my opinion that putting view-based annotations on your model is Not a Good Thing. It confuses the separation of concerns. -Dan On 9/16/07, Ryan Sonnek [EMAIL PROTECTED] wrote: For me databinder helps cut the boilerplate code, just as WWB. I just add annotations to my domain model, and databinder does the rest. It's WWB for the database side of the app! Imagine putting both working together. I was able to create CRUD pages with the least amount of code ever. Less than that and it would need to read my mind... ;) Annotations have been a big win for Java. Many of their success stories have come out of their usage for configuration or metadata. I think that WWB may be a cantidate for using annotations instead of the beanprops file!
Re: Wicket Web Beans 1.0-rc1 Released
I do control my crud list and detail pages with annotations on the model, and it works quite nice (although I can't say the panels constructing the data table and form belongs in the category pretty code, at least there isn't a lot of it). I find I often use multiple views of the same model objects though, and for the non-trivial views the annotations become less useful, although it's still nice to tie in validation and some of the simpler jpa annotations, using them for layout loses the point here. Johan Ryan Sonnek wrote: Although it may blur the lines between view and model, there are a number of reasons that it still could be the right direction. * centralized configuration. all view configuration is in the same file as your model code. * leverage Java syntax instead of custom DSL. easy for users to get up and going when they have autocomplete for annotation configuration. * annotations are metadata, and this configuration *is* metadata for the view layer. * configuration by exception works well with annotations. Hibernate applies the same principle. you only need to declare annotations when you want to change the default behavior. I do understand your disagreement. It's a very natural Java architecture to create abstractions and try to build to design patterns. Realistically though, there are times when it's just plain overboard. You could make the same argument that Hibernate annotations don't really belong in the model code since it's configuring the back end setup, but the beauty of annotations is that it's metadata that *any* layer has access to. I recently published a wicket/hibernate component that leverages the hibernate annotations to enforce view layer behavior (requiredness/max length). Talk about blurring the lines... I'm really impressed with your work, and just want to impart what's worked *really* well for me. Good luck with whatever direction you take. On 9/16/07, Dan Syrstad [EMAIL PROTECTED] wrote: Ryan: The WWB beanprops/metadata is a view abstraction, while your bean is a part of the model. It's my opinion that putting view-based annotations on your model is Not a Good Thing. It confuses the separation of concerns. -Dan On 9/16/07, Ryan Sonnek [EMAIL PROTECTED] wrote: For me databinder helps cut the boilerplate code, just as WWB. I just add annotations to my domain model, and databinder does the rest. It's WWB for the database side of the app! Imagine putting both working together. I was able to create CRUD pages with the least amount of code ever. Less than that and it would need to read my mind... ;) Annotations have been a big win for Java. Many of their success stories have come out of their usage for configuration or metadata. I think that WWB may be a cantidate for using annotations instead of the beanprops file! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0-rc1 Released
I'm really impressed with your work, and just want to impart what's worked *really* well for me. Good luck with whatever direction you take. One thing Dan could consider is to abstract enough so that both strategies could be supported. Doesn't mean he should ship annotations support, but it might help if things are set up in such a way that this can be build in. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0-rc1 Released
Ryan: One thing I started considering today after your comments was to place annotations, similar to beanprops, on the component level (e.g., Page). Currently beanprops are associated with the Page anyway, so this would be natural and provide type-safeness without bluring the view/model line. I think that Hibernate annotations suchs as required and max length are actually useful for both the model and the view. But possible annotations such as label', fieldType, and presentation order are definitely view-related. Jonathan and others have suggested a Java API and one of the consultants I have worked with actually started on this. But it needs to be finished. -Dan On 9/16/07, Eelco Hillenius [EMAIL PROTECTED] wrote: I'm really impressed with your work, and just want to impart what's worked *really* well for me. Good luck with whatever direction you take. One thing Dan could consider is to abstract enough so that both strategies could be supported. Doesn't mean he should ship annotations support, but it might help if things are set up in such a way that this can be build in. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0-rc1 Released
My suggestions to this nice compont: - allow beanprops files to be reloaded while app is running. How it stands now I have to restart the app everytime a change to beanprop file is made, it can be time consuming. - allow constructor to accept models besides beans too, if possible. I am trying to integrate WWB with databinder, and it would be useful to pass HibernateListModels to WWBs constructor. Congrats for such a nice and useful component! -- View this message in context: http://www.nabble.com/Re%3A-Wicket-Web-Beans-1.0-rc1-Released-tf4431603.html#a12690712 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 Web Beans 1.0-rc1 Released
Hi Zenrique: See below... -Dan On 9/15/07, Zenrique Steckelberg [EMAIL PROTECTED] wrote: My suggestions to this nice compont: - allow beanprops files to be reloaded while app is running. How it stands now I have to restart the app everytime a change to beanprop file is made, it can be time consuming. Tomcat will reload the application automatically right now if you change beanprops, much like a class change. This takes a second or two depending on the size of your app. If your not using Tomcat, I can look at having the file reload (it is currently cached). What app server/servlet engine are you using? - allow constructor to accept models besides beans too, if possible. I am trying to integrate WWB with databinder, and it would be useful to pass HibernateListModels to WWBs constructor. I'll have to look at this. I've only had a cursory look at Databinder and I'm not quite sure when I'll have time to look in depth. I'm alway looking for help too! ;-) Congrats for such a nice and useful component! Thank you!
Re: Wicket Web Beans 1.0-rc1 Released
In the current WWB strategy, required fields are enforced in your model/DAO layer. For example, if you click your Save action, the action on your page would be invoked. This, in turn, calls your DAO or model. Often fields are conditionally required based on use case and or data conditions. We're currently using the Spring validation framework to validate required fields on the bean via the DAO. In turn, messages are returned back to the page and we add them to the Wicket feedback via the error() method. However, it would be a fairly simple matter to add a required: true parameter for times when you know that a field will always be required. I'll add this to the features requests in sourceforge. -Dan On 9/15/07, Zenrique Steckelberg [EMAIL PROTECTED] wrote: How can I make one textfield required? Couldn't find it anywhere in the docs. Besides that, I susggest you put the JavaDocs somewhere in the framwork site too. Thanks in advance! -- View this message in context: http://www.nabble.com/Re%3A-Wicket-Web-Beans-1.0-rc1-Released-tf4431603.html#a12691422 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 Web Beans 1.0-rc1 Released
Hi Dan, Does your framework support drill down feature in case I have a ListBean as a property in my parent bean so that it can also generate a listview of form fields based on that properties of the Child Bean collection ? if there is also a way to customize the drill depth, it will also be nice On 9/13/07, Dan Syrstad [EMAIL PROTECTED] wrote: Hi Kent: Thank you for your kind comments! It's nice to see several months of work be useful to others. I've heard the why not Java instead of beanprops comment before. I may even do something about it ;-). Seriously, that may be offered as an alternative to the beanprops file. I chose the beanprops file for simplicity. It is declarative rather than procedural (e.g., Java). I believe that the exceptions can be specified in a more concise form than if they were to be written in Java. Plus, WWB contexts/use cases can override the default context by just specifying what's different. In fact, that's the whole WWB philosophy - programming by exception. I guess it similar to why you don't specify localization in Java - you use property files. It also why in Wicket you don't code HTML tags in Java to be output to the browser - HTML itself is more concise and direct. I actually worked with an in-house web framework that made you code the HTML tags in Java. No HTML, no JSP, just Java. It wasn't pretty ;-). -Dan Syrstad http://wicketwebbeans.sourceforge.com On 9/12/07, Kent Tong [EMAIL PROTECTED] wrote: Hi Dan, It looks very powerful! BTW, why chose to use a config file (beanprops) instead of Java code? I think doing in Java for everything other than the standard web stuff (HTML/CSS/js) is a basic principle of Wicket. -- View this message in context: http://www.nabble.com/Re%3A-Wicket-Web-Beans-1.0-rc1-Released-tf4431603.html#a12647439 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 Web Beans 1.0-rc1 Released
Hi Ayodeji: See my responses below... -Dan Syrstad http://wicketwebbeans.sourceforge.com On 9/13/07, Ayodeji Aladejebi [EMAIL PROTECTED] wrote: Hi Dan, Does your framework support drill down feature in case I have a ListBean as a property in my parent bean so that it can also generate a listview of form fields based on that properties of the Child Bean collection ? Yes, it does support collections of nested beans. Please see the Invoice/InvoiceLines example in the documentation. if there is also a way to customize the drill depth, it will also be nice I'm not exactly sure what you mean by this. If you mean limit how deep the nesting goes, the answer is yes. You can alway specify whether a bean or a bean property is displayed, thus controlling how deep the nesting goes.
Re: Wicket Web Beans 1.0-rc1 Released
Hey Dan, that looks very nice! Thanks for sharing. Eelco On 9/12/07, Dan Syrstad [EMAIL PROTECTED] wrote: In response to Jonathan Locke's blog entry entitled Wicket on Wheels ( http://web.mac.com/jonathan.locke/iWeb/JonathanLocke/Blog/6B9496DF-4AF1-455E-B94C-652709275041.html), I have released Wicket Web Beans 1.0-rc1. Although this project does not cover all of the functionality Jonathan spoke of, I believe it covers a good chunk of it. The project is hosted on Sourceforge at: http://wicketwebbeans.sourceforge.net . Summary: Wicket Web Beans (WWB) is a Wicket component toolkit for displaying and editing POJOs that conform to the JavaBeans specification. Web pages are automatically generated based on bean properties and certain conventions. If necessary, the layout, editability, and actions of these pages can be customized on an exception basis. In other words, the toolkit normally does what you'd expect, but when it doesn't, you can override its behavior. At the highest-level, WWB's BeanForm component provides rich AJAX form functionality. The Page design that the form is embedded on is left to you, this allows for customized page designs. Also, this allows multiple BeanForms may be incorporated on a single page. At your choosing, other lower-level components may be used independently of BeanForm (e.g., BeanGridPanel). WWB does not try to force you into a certain way of doing things, but BeanForm makes it very convenient to implement a bean-based form if you don't want to go to a lot of extra work. You focus on the model (beans), WWB handles the user interface. I welcome any feedback you may have. Please post feedback to the project forums at Sourceforge. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Web Beans 1.0-rc1 Released
Hi Dan, It looks very powerful! BTW, why chose to use a config file (beanprops) instead of Java code? I think doing in Java for everything other than the standard web stuff (HTML/CSS/js) is a basic principle of Wicket. -- View this message in context: http://www.nabble.com/Re%3A-Wicket-Web-Beans-1.0-rc1-Released-tf4431603.html#a12647439 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 Web Beans 1.0-rc1 Released
Hi Kent: Thank you for your kind comments! It's nice to see several months of work be useful to others. I've heard the why not Java instead of beanprops comment before. I may even do something about it ;-). Seriously, that may be offered as an alternative to the beanprops file. I chose the beanprops file for simplicity. It is declarative rather than procedural (e.g., Java). I believe that the exceptions can be specified in a more concise form than if they were to be written in Java. Plus, WWB contexts/use cases can override the default context by just specifying what's different. In fact, that's the whole WWB philosophy - programming by exception. I guess it similar to why you don't specify localization in Java - you use property files. It also why in Wicket you don't code HTML tags in Java to be output to the browser - HTML itself is more concise and direct. I actually worked with an in-house web framework that made you code the HTML tags in Java. No HTML, no JSP, just Java. It wasn't pretty ;-). -Dan Syrstad http://wicketwebbeans.sourceforge.com On 9/12/07, Kent Tong [EMAIL PROTECTED] wrote: Hi Dan, It looks very powerful! BTW, why chose to use a config file (beanprops) instead of Java code? I think doing in Java for everything other than the standard web stuff (HTML/CSS/js) is a basic principle of Wicket. -- View this message in context: http://www.nabble.com/Re%3A-Wicket-Web-Beans-1.0-rc1-Released-tf4431603.html#a12647439 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
