Re: [Wicket-user] VOTE on wicket:component
Hi Jonathan, What is the result of the vote then? Or was it just a poll? Seems like many users expressed the wish to remove that feature. Is there a JIRA issue for that? Thanks, -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE on wicket:component
wicket:container is available for 2.x. Juergen On 2/14/07, Rüdiger Schulz [EMAIL PROTECTED] wrote: Jonathan Locke schrieb: [X] Delete this unimportant and generally unsupported feature [ ] Keep wicket:component, but define its limits, document it on the wiki as fully supported and commit to supporting it in the future and a +1 for wicket:pseudo / wicket:container as well ;) Greetings, Rüdiger - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE on wicket:component
As a long-time Tapestry user (but very new Wicket user), I have a few thoughts about in-line component declaration. 1.) Even in a framework like Tapestry where the idiom is fully supported, it can lead to complex and difficult to maintain templates. In fact, it's generally discouraged in Tapestry for those reasons. 2.) Providing a fundamentally different, optional way to declare components in Wicket seems more like an unnecessary increase in ways to do it rather than a useful increase in flexibility. 3) The tooling support issue should not be underestimated. The author of the Spindle plugin for Tapestry eventually gave up on updating it for Tapestry 4 precisely because there were so many ways in which components could be defined (in the template, in the XML spec file or in Java via annotations). While experienced Tapestry users can get along just fine without that plugin, it was a big selling point for new users. In short, I think you should hold a hard line against increased functionality in templates and only make exceptions for the most compelling and common use cases (e.g. wicket:message). -Ryan On Feb 13, 2007, at 8:47 AM, Jonathan Locke wrote: Our Wiki describes the wicket:component tag as follows: wicket:component - Creates a Wicket component on the fly. Needs a class attribute. Though this has been in wicket for a long time, it is still kind of an unsupported feature, as most of the core developers believe that this may lead to misuse of the framework. Before heavily relying on this feature, you might want to contact the user list to discuss alternative strategies. It's unclear to me that anyone is using this. The utility is limited and unimportant. And for anyone creating tooling support for wicket, this will be a tripping point. I can't see any good reason to keep this feature as it is a way to instantiate a component in the markup and might server as the beginning of a bunch of requests to add component configuration or other code logic where we should only have nice clean markup. VOTE: [ ] Delete this unimportant and generally unsupported feature [ ] Keep wicket:component, but define its limits, document it on the wiki as fully supported and commit to supporting it in the future -- View this message in context: http://www.nabble.com/VOTE-on-wicket% 3Acomponent-tf3221780.html#a8948008 Sent from the Wicket - User mailing list archive at Nabble.com. -- --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel? cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE on wicket:component
On 2/14/07, Ryan Holmes [EMAIL PROTECTED] wrote: As a long-time Tapestry user (but very new Wicket user), I have a few thoughts about in-line component declaration. 1.) Even in a framework like Tapestry where the idiom is fully supported, it can lead to complex and difficult to maintain templates. In fact, it's generally discouraged in Tapestry for those reasons. 2.) Providing a fundamentally different, optional way to declare components in Wicket seems more like an unnecessary increase in ways to do it rather than a useful increase in flexibility. 3) The tooling support issue should not be underestimated. The author of the Spindle plugin for Tapestry eventually gave up on updating it for Tapestry 4 precisely because there were so many ways in which components could be defined (in the template, in the XML spec file or in Java via annotations). While experienced Tapestry users can get along just fine without that plugin, it was a big selling point for new users. It's good to read this from a 'regular user', and from actual experience. I'm changing my vote to: +1 for removing it. Thanks Ryan, Eelco - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE on wicket:component
On 2/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 2/14/07, Ryan Holmes [EMAIL PROTECTED] wrote: As a long-time Tapestry user (but very new Wicket user), I have a few thoughts about in-line component declaration. 1.) Even in a framework like Tapestry where the idiom is fully supported, it can lead to complex and difficult to maintain templates. In fact, it's generally discouraged in Tapestry for those reasons. 2.) Providing a fundamentally different, optional way to declare components in Wicket seems more like an unnecessary increase in ways to do it rather than a useful increase in flexibility. 3) The tooling support issue should not be underestimated. The author of the Spindle plugin for Tapestry eventually gave up on updating it for Tapestry 4 precisely because there were so many ways in which components could be defined (in the template, in the XML spec file or in Java via annotations). While experienced Tapestry users can get along just fine without that plugin, it was a big selling point for new users. It's good to read this from a 'regular user', and from actual experience. I'm changing my vote to: +1 for removing it. Yes that really nails it and also express how I feel about it. (can we remove wicket:link as well now we're at it ;o) +1 remove it Frank - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE on wicket:component
Didn't know about it before, so can't see a possible use case where it is necessary +1 remove. On 2/14/07, Frank Bille [EMAIL PROTECTED] wrote: On 2/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 2/14/07, Ryan Holmes [EMAIL PROTECTED] wrote: As a long-time Tapestry user (but very new Wicket user), I have a few thoughts about in-line component declaration. 1.) Even in a framework like Tapestry where the idiom is fully supported, it can lead to complex and difficult to maintain templates. In fact, it's generally discouraged in Tapestry for those reasons. 2.) Providing a fundamentally different, optional way to declare components in Wicket seems more like an unnecessary increase in ways to do it rather than a useful increase in flexibility. 3) The tooling support issue should not be underestimated. The author of the Spindle plugin for Tapestry eventually gave up on updating it for Tapestry 4 precisely because there were so many ways in which components could be defined (in the template, in the XML spec file or in Java via annotations). While experienced Tapestry users can get along just fine without that plugin, it was a big selling point for new users. It's good to read this from a 'regular user', and from actual experience. I'm changing my vote to: +1 for removing it. Yes that really nails it and also express how I feel about it. (can we remove wicket:link as well now we're at it ;o) +1 remove it Frank - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE on wicket:component
Stability and consistency is paramount in a good framework - delete. Jonathan Locke wrote: Our Wiki describes the wicket:component tag as follows: wicket:component - Creates a Wicket component on the fly. Needs a class attribute. Though this has been in wicket for a long time, it is still kind of an unsupported feature, as most of the core developers believe that this may lead to misuse of the framework. Before heavily relying on this feature, you might want to contact the user list to discuss alternative strategies. It's unclear to me that anyone is using this. The utility is limited and unimportant. And for anyone creating tooling support for wicket, this will be a tripping point. I can't see any good reason to keep this feature as it is a way to instantiate a component in the markup and might server as the beginning of a bunch of requests to add component configuration or other code logic where we should only have nice clean markup. VOTE: [ ] Delete this unimportant and generally unsupported feature [ ] Keep wicket:component, but define its limits, document it on the wiki as fully supported and commit to supporting it in the future -- View this message in context: http://www.nabble.com/VOTE-on-wicket%3Acomponent-tf3221780.html#a8967701 Sent from the Wicket - User mailing list archive at Nabble.com. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE on wicket:component
yep. yep. yep. could not have said it better. it takes real effort to restrain a maturing project from collapsing under its own weight. *less is more* Ryan Holmes wrote: As a long-time Tapestry user (but very new Wicket user), I have a few thoughts about in-line component declaration. 1.) Even in a framework like Tapestry where the idiom is fully supported, it can lead to complex and difficult to maintain templates. In fact, it's generally discouraged in Tapestry for those reasons. 2.) Providing a fundamentally different, optional way to declare components in Wicket seems more like an unnecessary increase in ways to do it rather than a useful increase in flexibility. 3) The tooling support issue should not be underestimated. The author of the Spindle plugin for Tapestry eventually gave up on updating it for Tapestry 4 precisely because there were so many ways in which components could be defined (in the template, in the XML spec file or in Java via annotations). While experienced Tapestry users can get along just fine without that plugin, it was a big selling point for new users. In short, I think you should hold a hard line against increased functionality in templates and only make exceptions for the most compelling and common use cases (e.g. wicket:message). -Ryan On Feb 13, 2007, at 8:47 AM, Jonathan Locke wrote: Our Wiki describes the wicket:component tag as follows: wicket:component - Creates a Wicket component on the fly. Needs a class attribute. Though this has been in wicket for a long time, it is still kind of an unsupported feature, as most of the core developers believe that this may lead to misuse of the framework. Before heavily relying on this feature, you might want to contact the user list to discuss alternative strategies. It's unclear to me that anyone is using this. The utility is limited and unimportant. And for anyone creating tooling support for wicket, this will be a tripping point. I can't see any good reason to keep this feature as it is a way to instantiate a component in the markup and might server as the beginning of a bunch of requests to add component configuration or other code logic where we should only have nice clean markup. VOTE: [ ] Delete this unimportant and generally unsupported feature [ ] Keep wicket:component, but define its limits, document it on the wiki as fully supported and commit to supporting it in the future -- View this message in context: http://www.nabble.com/VOTE-on-wicket% 3Acomponent-tf3221780.html#a8948008 Sent from the Wicket - User mailing list archive at Nabble.com. -- --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel? cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- View this message in context: http://www.nabble.com/VOTE-on-wicket%3Acomponent-tf3221780.html#a8968141 Sent from the Wicket - User mailing list archive at Nabble.com. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE on wicket:component
[X] Delete this unimportant and generally unsupported feature On 2/13/07, Jonathan Locke [EMAIL PROTECTED] wrote: Our Wiki describes the wicket:component tag as follows: wicket:component - Creates a Wicket component on the fly. Needs a class attribute. Though this has been in wicket for a long time, it is still kind of an unsupported feature, as most of the core developers believe that this may lead to misuse of the framework. Before heavily relying on this feature, you might want to contact the user list to discuss alternative strategies. It's unclear to me that anyone is using this. The utility is limited and unimportant. And for anyone creating tooling support for wicket, this will be a tripping point. I can't see any good reason to keep this feature as it is a way to instantiate a component in the markup and might server as the beginning of a bunch of requests to add component configuration or other code logic where we should only have nice clean markup. VOTE: [ ] Delete this unimportant and generally unsupported feature [ ] Keep wicket:component, but define its limits, document it on the wiki as fully supported and commit to supporting it in the future -- View this message in context: http://www.nabble.com/VOTE-on-wicket%3Acomponent-tf3221780.html#a8948008 Sent from the Wicket - User mailing list archive at Nabble.com. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Shawn Tumey Cofounder MT Web Productions LLC www.mtwebproduction.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE on wicket:component
Hi, I vote either: [X] Keep wicket:component, but define its limits, document it on the wiki as fully supported and commit to supporting it in the future or [X] Delete this unimportant and generally unsupported feature with the amendment that the case below is supported in some other way Like Timo I am using it in a number of places to keep my XHTML valid. For example: table wicket:component wicket:id=persons trtdRow 1 of person data/td/tr trtdRow 2 of person data/td/tr /wicket:component /table I do not know how to write this in valid XHTML without wicket:component. Regards, Erik. Jonathan Locke wrote: Our Wiki describes the wicket:component tag as follows: wicket:component - Creates a Wicket component on the fly. Needs a class attribute. Though this has been in wicket for a long time, it is still kind of an unsupported feature, as most of the core developers believe that this may lead to misuse of the framework. Before heavily relying on this feature, you might want to contact the user list to discuss alternative strategies. It's unclear to me that anyone is using this. The utility is limited and unimportant. And for anyone creating tooling support for wicket, this will be a tripping point. I can't see any good reason to keep this feature as it is a way to instantiate a component in the markup and might server as the beginning of a bunch of requests to add component configuration or other code logic where we should only have nice clean markup. VOTE: [ ] Delete this unimportant and generally unsupported feature [ ] Keep wicket:component, but define its limits, document it on the wiki as fully supported and commit to supporting it in the future -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE on wicket:component
Jonathan Locke schrieb: [X] Delete this unimportant and generally unsupported feature [ ] Keep wicket:component, but define its limits, document it on the wiki as fully supported and commit to supporting it in the future and a +1 for wicket:pseudo / wicket:container as well ;) Greetings, Rüdiger - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE on wicket:component
[X] Delete this unimportant and generally unsupported feature Juergen On 2/13/07, Jonathan Locke [EMAIL PROTECTED] wrote: Our Wiki describes the wicket:component tag as follows: wicket:component - Creates a Wicket component on the fly. Needs a class attribute. Though this has been in wicket for a long time, it is still kind of an unsupported feature, as most of the core developers believe that this may lead to misuse of the framework. Before heavily relying on this feature, you might want to contact the user list to discuss alternative strategies. It's unclear to me that anyone is using this. The utility is limited and unimportant. And for anyone creating tooling support for wicket, this will be a tripping point. I can't see any good reason to keep this feature as it is a way to instantiate a component in the markup and might server as the beginning of a bunch of requests to add component configuration or other code logic where we should only have nice clean markup. VOTE: [ ] Delete this unimportant and generally unsupported feature [ ] Keep wicket:component, but define its limits, document it on the wiki as fully supported and commit to supporting it in the future -- View this message in context: http://www.nabble.com/VOTE-on-wicket%3Acomponent-tf3221780.html#a8948008 Sent from the Wicket - User mailing list archive at Nabble.com. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE on wicket:component
i don't care to much, but i don't plan on supporting it at this time (personally) But maybe some comes up with a GREAT usecase? so +0 I do agree a bit that we maybe should say, it is really supported if we keep it. johan On 2/13/07, Jonathan Locke [EMAIL PROTECTED] wrote: Our Wiki describes the wicket:component tag as follows: wicket:component - Creates a Wicket component on the fly. Needs a class attribute. Though this has been in wicket for a long time, it is still kind of an unsupported feature, as most of the core developers believe that this may lead to misuse of the framework. Before heavily relying on this feature, you might want to contact the user list to discuss alternative strategies. It's unclear to me that anyone is using this. The utility is limited and unimportant. And for anyone creating tooling support for wicket, this will be a tripping point. I can't see any good reason to keep this feature as it is a way to instantiate a component in the markup and might server as the beginning of a bunch of requests to add component configuration or other code logic where we should only have nice clean markup. VOTE: [ ] Delete this unimportant and generally unsupported feature [ ] Keep wicket:component, but define its limits, document it on the wiki as fully supported and commit to supporting it in the future -- View this message in context: http://www.nabble.com/VOTE-on-wicket%3Acomponent-tf3221780.html#a8948008 Sent from the Wicket - User mailing list archive at Nabble.com. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE on wicket:component
[ ] Delete this unimportant and generally unsupported feature [ ] Keep wicket:component, but define its limits, document it on the wiki as fully supported and commit to supporting it in the future -0. I don't care much about this feature, but it's not in my way either. It's been in the project for over 2 years and it hasn't been giving us or our users (as far as we know) any problems, and I'm not crazy about just throwing away stuff because there might in a distant future be some problem with it while chances are that the feature actually is helpful for every 1 out of 100 Wicket users. If someone on this list (the VOTE is on the user instead of the dev list) uses it, could you please explain your use case? Eelco - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE on wicket:component
If wicket:component goes, please add wicket:pseudo http://www.nabble.com/%3Cwicket%3Apseudo%3E-tf2881952.html#a8052462 to be able to keep e.g. this kind of repeater markup valid when producing HTML tables with repeaters. wicket:component wicket:id=dataView wicket:component wicket:id=cols/wicket:component /wicket:component - Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE on wicket:component
I've havent used this feature.. And currently see no use for it. As long as one of the options are done, im happy:) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Locke Sent: 13. februar 2007 17:48 To: wicket-user@lists.sourceforge.net Subject: [Wicket-user] VOTE on wicket:component Our Wiki describes the wicket:component tag as follows: wicket:component - Creates a Wicket component on the fly. Needs a class attribute. Though this has been in wicket for a long time, it is still kind of an unsupported feature, as most of the core developers believe that this may lead to misuse of the framework. Before heavily relying on this feature, you might want to contact the user list to discuss alternative strategies. It's unclear to me that anyone is using this. The utility is limited and unimportant. And for anyone creating tooling support for wicket, this will be a tripping point. I can't see any good reason to keep this feature as it is a way to instantiate a component in the markup and might server as the beginning of a bunch of requests to add component configuration or other code logic where we should only have nice clean markup. VOTE: [ ] Delete this unimportant and generally unsupported feature [ ] Keep wicket:component, but define its limits, document it on the wiki as fully supported and commit to supporting it in the future -- View this message in context: http://www.nabble.com/VOTE-on-wicket%3Acomponent-tf3221780.html#a8948008 Sent from the Wicket - User mailing list archive at Nabble.com. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
We already have a getValue on formcomponent
that is the input value from the request or the model object as a string
(just the latest value)
So then that also has to be renamed. (and relearned)
I think getModelObject() is just what it says. (besides the getModel() call
we also have!)
else it should be getModelValue() not just getValue()
So i am -1 for changing getModelObject to getValue() that isn't descriptive
enough for me and will
collide with what we already have and that will result in even more renames.
I dont care to much +0 about changing the IModel interface itself (it
already has changed a bit because of the lost param in 2.0)
But i don't know if that really has much value.
johan
On 1/23/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere
or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since
our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived
from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first
paragraph
to be even more specific. Maybe it could be tweaked a little more,
but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in
turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.
In addition to rephrasing or rewriting a lot of material, and adding
a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more
advanced
More about
Models page.
igor.vaynberg wrote:
go ahead and edit the page...the wiki is versioned i think so we can
always
roll back.
when you are done with the majority let us know and we will review
the
changes.
-igor
On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:
When I first started using Wicket I found the information on models
a
little
hard to follow. So now I'd like to revise the Working with Wicket
models
wiki page
(
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
to improve this. I'd be happy to outline what I think should be
improved
(though this is a little hard to do in detail short of simply
annotating
the
page) or I can just plunge ahead and draft a revised page. If I do
the
latter I could potentially post it somewhere else for comment
instead
of
directly replacing the existing page on the wiki. Perhaps we need a
'in
draft' part of the wiki for working on long pages like this one.
Actually, another
Re: [Wicket-user] VOTE: IModel and 'model object' name change
Im -1.
As most of my models holds objects and not value, I've had no problem
understanding this part of the IModel.
I must admit that I may be blind to this because im used to the current naming,
and have been working with it for so long. I guess the new users would be the
ones best to tell us which would be better.
But I do think that getModelObject, is very descriptive.
It tells that you want to get the object that the model hold. getValue just
tells that you want to get a value, which value is it that you are getting is
an integer or what?
Regards Nino
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Locke
Sent: 23. januar 2007 07:51
To: wicket-user@lists.sourceforge.net
Subject: [Wicket-user] VOTE: IModel and 'model object' name change
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first paragraph
to be even more specific. Maybe it could be tweaked a little more, but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.
In addition to rephrasing or rewriting a lot of material, and adding a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more advanced
More about
Models page.
igor.vaynberg wrote:
go ahead and edit the page...the wiki is versioned i think so we can
always
roll back.
when you are done with the majority let us know and we will review the
changes.
-igor
On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:
When I first started using Wicket I found the information on models a
little
hard to follow. So now I'd like to revise the Working with Wicket
models
wiki page
(
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
to improve this. I'd be happy to outline what I think should be
improved
(though this is a little hard to do in detail short of simply
annotating
the
page) or I can just plunge ahead and draft a revised page. If I do
the
latter I could potentially post it somewhere else for comment instead
of
directly replacing the existing page on the wiki. Perhaps we need a
'in
draft' part
Re: [Wicket-user] VOTE: IModel and 'model object' name change
On 23/01/07, Jonathan Locke [EMAIL PROTECTED] wrote: ... in fact, that term is actually ambiguous since the object implementing IModel might be informally understood to be the model object (which is not what we mean)... You're very right. This is the major contributor to my confusion about models when I was first studying Wicket. I don't want to vote because I'm no one here and my vote is nothing. I just want to voice my opinion: I think the solution would be for the wiki and book writers to give more weight and clear explanations about models and relieve newbies from this confusion. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
If it is user opinion wanted, for what I am it is -1. I would be please with the change if I used wicket for a home hobby of making something easy. But the problem is that I'm working in a production environment. Every thing that will make 2.0 migration harder will make sure that it will not get used soon in the industry. The arguments are good, but I don't think it is worth it. Marc On 1/23/07, Otan [EMAIL PROTECTED] wrote: On 23/01/07, Jonathan Locke [EMAIL PROTECTED] wrote: ... in fact, that term is actually ambiguous since the object implementing IModel might be informally understood to be the model object (which is not what we mean)... You're very right. This is the major contributor to my confusion about models when I was first studying Wicket. I don't want to vote because I'm no one here and my vote is nothing. I just want to voice my opinion: I think the solution would be for the wiki and book writers to give more weight and clear explanations about models and relieve newbies from this confusion. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.
Eelco
On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first paragraph
to be even more specific. Maybe it could be tweaked a little more, but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.
In addition to rephrasing or rewriting a lot of material, and adding a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more advanced
More about
Models page.
igor.vaynberg wrote:
go ahead and edit the page...the wiki is versioned i think so we can
always
roll back.
when you are done with the majority let us know and we will review the
changes.
-igor
On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:
When I first started using Wicket I found the information on models a
little
hard to follow. So now I'd like to revise the Working with Wicket
models
wiki page
(
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
to improve this. I'd be happy to outline what I think should be
improved
(though this is a little hard to do in detail short of simply
annotating
the
page) or I can just plunge ahead and draft a revised page. If I do
the
latter I could potentially post it somewhere else for comment instead
of
directly replacing the existing page on the wiki. Perhaps we need a
'in
draft' part of the wiki for working on long pages like this one.
Actually, another alternative is for me to gradually introduce
changes to
the wiki page over a span of days, giving people a chance to comment
as I
go.
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8378321
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Take Surveys. Earn
Re: [Wicket-user] VOTE: IModel and 'model object' name change
-1 for changing the method signature
+1 for more model examples particularly contextual ones, i.e. with a form
you often use the form component itself as the model (I can work on this if
things go as I hope with our web ui proofs of concept -- otherwise I'll be
off learning JSF)
On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.
Eelco
On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for
a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since
our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived
from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model
object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if
this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing
something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and
more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first
paragraph
to be even more specific. Maybe it could be tweaked a little more,
but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given
model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in
turn
decouples the whole Wicket framework from any and all details of
model
storage, such as the details of a given persistence technology. As
far
as Wicket itself is concerned, a model is anything that implements
the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel
interface
since readers will be wondering what it looks like already. It
sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.
In addition to rephrasing or rewriting a lot of material, and
adding a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more
advanced
More about
Models page.
igor.vaynberg wrote:
go ahead and edit the page...the wiki is versioned i think so we
can
always
roll back.
when you are done with the majority let us know and we will review
the
changes.
-igor
On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:
When I first started using Wicket I found the information on
models a
little
hard to follow. So now I'd like to revise the Working with
Wicket
models
wiki page
(
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
to improve this. I'd be happy to outline what I think should be
improved
(though this is a little hard to do in detail short of simply
annotating
the
page) or I can just plunge ahead and draft a revised page. If I
do
the
latter I could potentially post it somewhere else for comment
instead
of
directly replacing the existing page on the wiki. Perhaps we need
a
'in
draft' part of the wiki for working on long pages like this one.
Actually, another alternative is for me to gradually introduce
changes to
the wiki page over a span of days, giving
Re: [Wicket-user] VOTE: IModel and 'model object' name change
+1 Don't know if my vote counts or not, but anyway.
I'm one of those users that had trouble with the ambiguity between model
object (as in the IModel instance) and modelObject (the object contained
by the model). Worse, In my project's team all the modelObjects were
classes with the naming convention XXXModel so we had IModels containing
modelObjects that were XXXModels. If that isn't an example of bad
naming, then what is? :D
In my opinion models containing values that are (of course) objects is
much clearer and would prevent this kind of madness. Luckily Eclipse has
great refactoring features, so XXXModel soon became XXXModelObject.
Matthijs
Eelco Hillenius wrote:
-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.
Eelco
On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first paragraph
to be even more specific. Maybe it could be tweaked a little more, but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.
In addition to rephrasing or rewriting a lot of material, and adding a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more advanced
More about
Models page.
igor.vaynberg wrote:
go ahead and edit the page...the wiki is versioned i think so we can
always
roll back.
when you are done with the majority let us know and we will review the
changes.
-igor
On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:
When I first started using Wicket I found the information on models a
little
hard to follow. So now I'd like to revise the Working with Wicket
models
wiki page
(
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
to improve this. I'd be happy to outline what I think should be
improved
(though this is a little hard to do in detail short of simply
annotating
the
page) or I can just plunge ahead and draft a revised page. If I do
the
latter I could
Re: [Wicket-user] VOTE: IModel and 'model object' name change
+0 for changing, except not sure it's what Johnathan suggested.
My problem is with using the word Model at all for the objects that
access model properties (maybe they should be ModelAccessors,
ModelExposer, ModelAdaptor, ModelBridge, ModelConnector, or something
along the lines... then ReflectionModelAccessor or
CompositeModelAccessor, ...). They're not really models in any sense
that existing software patterns might agree, except maybe from the
framework-only perspective. The methods wouldn't even have to change
that much then.
[]s Gus
On 1/23/07, Matthijs Wensveen [EMAIL PROTECTED] wrote:
+1 Don't know if my vote counts or not, but anyway.
I'm one of those users that had trouble with the ambiguity between model
object (as in the IModel instance) and modelObject (the object contained
by the model). Worse, In my project's team all the modelObjects were
classes with the naming convention XXXModel so we had IModels containing
modelObjects that were XXXModels. If that isn't an example of bad
naming, then what is? :D
In my opinion models containing values that are (of course) objects is
much clearer and would prevent this kind of madness. Luckily Eclipse has
great refactoring features, so XXXModel soon became XXXModelObject.
Matthijs
Eelco Hillenius wrote:
-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.
Eelco
On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere
or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived
from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first paragraph
to be even more specific. Maybe it could be tweaked a little more, but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.
In addition to rephrasing or rewriting a lot of material, and adding a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more advanced
More about
Models page.
igor.vaynberg wrote:
go ahead and edit the page...the wiki is versioned i think so we can
always
Re: [Wicket-user] VOTE: IModel and 'model object' name change
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
yeah. i agree. if we did anything it would be better to change IModel as i
said,
but then just deprecate getModelObject() and add a preferred version as
getModelValue() as johan suggested. this would only break code that
directly
uses IModel (a more limited number of users).
Eelco Hillenius wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere
or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8526349
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
it would be Component.getModelValue() not Component.getModelObject() i
think. what this disambiguates is what object you are referring to. the
problem is that IModel impl itself is an object, so when you say
component.getModelObject() what do you really want? the model object or the
object inside the model object?
-igor
On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
Agreed. We have been discussing that in the past as well.
IModelLocator for instance might have been a better name. And
IModelLocator could then have get/setModel, as that's the real model
value you're looking at.
Eelco
On 1/23/07, Gustavo Hexsel [EMAIL PROTECTED] wrote:
+0 for changing, except not sure it's what Johnathan suggested.
My problem is with using the word Model at all for the objects that
access model properties (maybe they should be ModelAccessors,
ModelExposer, ModelAdaptor, ModelBridge, ModelConnector, or something
along the lines... then ReflectionModelAccessor or
CompositeModelAccessor, ...). They're not really models in any sense
that existing software patterns might agree, except maybe from the
framework-only perspective. The methods wouldn't even have to change
that much then.
[]s Gus
On 1/23/07, Matthijs Wensveen [EMAIL PROTECTED] wrote:
+1 Don't know if my vote counts or not, but anyway.
I'm one of those users that had trouble with the ambiguity between model
object (as in the IModel instance) and modelObject (the object contained
by the model). Worse, In my project's team all the modelObjects were
classes with the naming convention XXXModel so we had IModels containing
modelObjects that were XXXModels. If that isn't an example of bad
naming, then what is? :D
In my opinion models containing values that are (of course) objects is
much clearer and would prevent this kind of madness. Luckily Eclipse has
great refactoring features, so XXXModel soon became XXXModelObject.
Matthijs
Eelco Hillenius wrote:
-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.
Eelco
On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since
our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived
from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if
this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first
paragraph
to be even more specific. Maybe it could be tweaked a little more,
but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in
turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
Re: [Wicket-user] VOTE: IModel and 'model object' name change
You make a good point. Something like IModelLocator would be a
clearer name for IModel. then its methods could be called get/setModel.
As you point out, IModel is only the model from the framework's
perspective. From the user's it is a model locator and the actual
model is the object returned by the locator interface. Maybe we
can consider this for 3.0 if there's strong agreement by then.
Gustavo Hexsel-3 wrote:
+0 for changing, except not sure it's what Johnathan suggested.
My problem is with using the word Model at all for the objects that
access model properties (maybe they should be ModelAccessors,
ModelExposer, ModelAdaptor, ModelBridge, ModelConnector, or something
along the lines... then ReflectionModelAccessor or
CompositeModelAccessor, ...). They're not really models in any sense
that existing software patterns might agree, except maybe from the
framework-only perspective. The methods wouldn't even have to change
that much then.
[]s Gus
On 1/23/07, Matthijs Wensveen [EMAIL PROTECTED] wrote:
+1 Don't know if my vote counts or not, but anyway.
I'm one of those users that had trouble with the ambiguity between model
object (as in the IModel instance) and modelObject (the object contained
by the model). Worse, In my project's team all the modelObjects were
classes with the naming convention XXXModel so we had IModels containing
modelObjects that were XXXModels. If that isn't an example of bad
naming, then what is? :D
In my opinion models containing values that are (of course) objects is
much clearer and would prevent this kind of madness. Luckily Eclipse has
great refactoring features, so XXXModel soon became XXXModelObject.
Matthijs
Eelco Hillenius wrote:
-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.
Eelco
On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's
very
late, but please at least read my argument below and think about it
for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString()
(or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters
since our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as
derived from
the IModel interface naming) is really not helping anyone to
understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model
object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn
may
very understandably not want to deal with that so i won't be upset if
this
change can't happen. but i'd like to see it if it's possible, so at
any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing
something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was
there
some crazy reason we didn't do this? It would be much easier and
more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first
paragraph
to be even more specific. Maybe it could be tweaked a little more,
but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given
model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in
turn
decouples the whole Wicket framework from any and all details of
model
storage, such as the details of a given persistence technology. As
far
as Wicket itself is concerned, a model is anything that implements
the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel
interface
since readers will be wondering what it looks like already. It
sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to complete newbies
are most
Re: [Wicket-user] VOTE: IModel and 'model object' name change
yes. that is the major concern.
for now, eelco could put a callout box in the book with a warning about
this ambiguity. we could also do the same in the javadoc for getModel()
and getModelObject() so any rare people who actually read the docs
won't be lost.
igor.vaynberg wrote:
it would be Component.getModelValue() not Component.getModelObject() i
think. what this disambiguates is what object you are referring to. the
problem is that IModel impl itself is an object, so when you say
component.getModelObject() what do you really want? the model object or
the
object inside the model object?
-igor
On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8526645
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
getModelValue would have been better than getModelObject yeah. That
said, imo (and I have stated this before), I think having those
methods in the first place is distracting, as it doesn't push people
in the direction of just letting the components and models work
directly for them.
Eelco
On 1/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
it would be Component.getModelValue() not Component.getModelObject() i
think. what this disambiguates is what object you are referring to. the
problem is that IModel impl itself is an object, so when you say
component.getModelObject () what do you really want? the model object or the
object inside the model object?
-igor
On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
geez, this makes so much sense like this! ;-)
Eelco Hillenius wrote:
Agreed. We have been discussing that in the past as well.
IModelLocator for instance might have been a better name. And
IModelLocator could then have get/setModel, as that's the real model
value you're looking at.
Eelco
On 1/23/07, Gustavo Hexsel [EMAIL PROTECTED] wrote:
+0 for changing, except not sure it's what Johnathan suggested.
My problem is with using the word Model at all for the objects that
access model properties (maybe they should be ModelAccessors,
ModelExposer, ModelAdaptor, ModelBridge, ModelConnector, or something
along the lines... then ReflectionModelAccessor or
CompositeModelAccessor, ...). They're not really models in any sense
that existing software patterns might agree, except maybe from the
framework-only perspective. The methods wouldn't even have to change
that much then.
[]s Gus
On 1/23/07, Matthijs Wensveen [EMAIL PROTECTED] wrote:
+1 Don't know if my vote counts or not, but anyway.
I'm one of those users that had trouble with the ambiguity between
model
object (as in the IModel instance) and modelObject (the object
contained
by the model). Worse, In my project's team all the modelObjects were
classes with the naming convention XXXModel so we had IModels
containing
modelObjects that were XXXModels. If that isn't an example of bad
naming, then what is? :D
In my opinion models containing values that are (of course) objects is
much clearer and would prevent this kind of madness. Luckily Eclipse
has
great refactoring features, so XXXModel soon became XXXModelObject.
Matthijs
Eelco Hillenius wrote:
-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.
Eelco
On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's
very
late, but please at least read my argument below and think about it
for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString()
(or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters
since our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as
derived from
the IModel interface naming) is really not helping anyone to
understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model
object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn
may
very understandably not want to deal with that so i won't be upset
if this
change can't happen. but i'd like to see it if it's possible, so at
any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing
something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was
there
some crazy reason we didn't do this? It would be much easier and
more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first
paragraph
to be even more specific. Maybe it could be tweaked a little
more, but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display
and/or
edit. How exactly this value is held is determined by a given
model's
implementation of the wicket.model.IModel interface. This
interface
decouples a component from the data which forms its value. This
in turn
decouples the whole Wicket framework from any and all details of
model
storage, such as the details of a given persistence technology.
As far
as Wicket itself is concerned, a model is anything that
implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel
interface
since readers will be wondering what it looks like already. It
sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to
Re: [Wicket-user] VOTE: IModel and 'model object' name change
I don't care much for getValue() because to me the word value suggests
atomic value (or even atomic constant) -- which is not the general
case.
At first I thought of recommending getBusinessObject() to distinguish
the result from the framework-oriented model classes, but that could be
confusing if it were common practices to embed wicket models inside of
wicket models (the Decorator pattern). If that's they case, I would
deprecate getModelObject() and replace it with getUnwrappedModel().
(Obviously, wicket documentation must somewhere explain the necessity of
_wrapping_ business objects in Wicket model classes to be accessed by
wicket components. Once that process is understood, multiple levels of
wrapping should not be too difficult to understand.)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan
Locke
Sent: Tuesday, January 23, 2007 11:35 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] VOTE: IModel and 'model object' name change
yeah. i agree. if we did anything it would be better to change IModel
as i said, but then just deprecate getModelObject() and add a preferred
version as
getModelValue() as johan suggested. this would only break code that
directly uses IModel (a more limited number of users).
Eelco Hillenius wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString()
(or
valueAsString() if preferred). there might be naming conflicts
somewhere
or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page
-tf3016921.html#a8526349
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
Yeah, the only real argument for that method other than brevity is that you
could override it.
It would be unreliable outside the core though and I can't think of a reason
to do that offhand.
Eelco Hillenius wrote:
getModelValue would have been better than getModelObject yeah. That
said, imo (and I have stated this before), I think having those
methods in the first place is distracting, as it doesn't push people
in the direction of just letting the components and models work
directly for them.
Eelco
On 1/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
it would be Component.getModelValue() not Component.getModelObject() i
think. what this disambiguates is what object you are referring to. the
problem is that IModel impl itself is an object, so when you say
component.getModelObject () what do you really want? the model object or
the
object inside the model object?
-igor
On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString()
(or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8526768
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
what do you think of gustav and eelco's IModelLocator / get/setModel idea?
Frank Silbermann wrote:
I don't care much for getValue() because to me the word value suggests
atomic value (or even atomic constant) -- which is not the general
case.
At first I thought of recommending getBusinessObject() to distinguish
the result from the framework-oriented model classes, but that could be
confusing if it were common practices to embed wicket models inside of
wicket models (the Decorator pattern). If that's they case, I would
deprecate getModelObject() and replace it with getUnwrappedModel().
(Obviously, wicket documentation must somewhere explain the necessity of
_wrapping_ business objects in Wicket model classes to be accessed by
wicket components. Once that process is understood, multiple levels of
wrapping should not be too difficult to understand.)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan
Locke
Sent: Tuesday, January 23, 2007 11:35 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] VOTE: IModel and 'model object' name change
yeah. i agree. if we did anything it would be better to change IModel
as i said, but then just deprecate getModelObject() and add a preferred
version as
getModelValue() as johan suggested. this would only break code that
directly uses IModel (a more limited number of users).
Eelco Hillenius wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString()
(or
valueAsString() if preferred). there might be naming conflicts
somewhere
or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page
-tf3016921.html#a8526349
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8526796
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Take Surveys. Earn Cash. Influence
Re: [Wicket-user] VOTE: IModel and 'model object' name change
Yes, perhaps a better way to avoid overloading the word Model or
ModelObject is to use those words to refer to that which is wrapped
(usually a non-wicket oriented business object), and use something else
for the class which does the wrapping and provides access to the wicket
page component.
However, I'm not that keen on the name IModelLocator, as the current
IModel does many things other than merely locating the model. It
provides string-based access methods to the model's parts; it handles
persistance or detachability, etc.
So I'd prefer to make get/setModel methods of an interface named
IModelManager or IModelWrapper.
The verbs Manage and Wrap are still somewhat vague, but there's only
so much that can be done to tersely document a class that does well lots
more than just one thing.
At least IModelManager or IModelWrapper are not ambiguous (as is
ModelObject), and avoids overloading the word Model.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan
Locke
Sent: Tuesday, January 23, 2007 11:55 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] VOTE: IModel and 'model object' name change
what do you think of gustav and eelco's IModelLocator / get/setModel
idea?
Frank Silbermann wrote:
I don't care much for getValue() because to me the word value
suggests atomic value (or even atomic constant) -- which is not
the general case.
At first I thought of recommending getBusinessObject() to distinguish
the result from the framework-oriented model classes, but that could
be confusing if it were common practices to embed wicket models inside
of wicket models (the Decorator pattern). If that's they case, I
would deprecate getModelObject() and replace it with
getUnwrappedModel().
(Obviously, wicket documentation must somewhere explain the necessity
of _wrapping_ business objects in Wicket model classes to be accessed
by wicket components. Once that process is understood, multiple
levels of wrapping should not be too difficult to understand.)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jonathan Locke
Sent: Tuesday, January 23, 2007 11:35 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] VOTE: IModel and 'model object' name change
yeah. i agree. if we did anything it would be better to change
IModel as i said, but then just deprecate getModelObject() and add a
preferred version as
getModelValue() as johan suggested. this would only break code that
directly uses IModel (a more limited number of users).
Eelco Hillenius wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable {
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString()
(or
valueAsString() if preferred). there might be naming conflicts
somewhere
or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than
Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
--
--
-
Take Surveys. Earn Cash. Influence the Future of IT Join
SourceForge.net's Techsay panel and you'll get the chance to
share
your
opinions on IT business topics through brief surveys - and earn
cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEV
DE
V
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-pa
ge
-tf3016921.html#a8526349
Sent from the Wicket - User mailing list archive at Nabble.com.
--
--
-
Take Surveys. Earn Cash. Influence the Future of IT Join
Re: [Wicket-user] VOTE: IModel and 'model object' name change
On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote: getModelValue would have been better than getModelObject yeah. That said, imo (and I have stated this before), I think having those methods in the first place is distracting, as it doesn't push people in the direction of just letting the components and models work directly for them. I would hate to see this method go because I've used it frequently in cases where I have inner classes and anonymous classes. Fixable with only mild annoyance, though. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
On 1/23/07, James McLaughlin [EMAIL PROTECTED] wrote: On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote: getModelValue would have been better than getModelObject yeah. That said, imo (and I have stated this before), I think having those methods in the first place is distracting, as it doesn't push people in the direction of just letting the components and models work directly for them. I would hate to see this method go because I've used it frequently in cases where I have inner classes and anonymous classes. Fixable with only mild annoyance, though. It won't go. I'm using it myself as well to be honest. It's just distracting. Eelco - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
With those names I am changing my vote to +1. Erik. Jonathan Locke wrote: what do you think of gustav and eelco's IModelLocator / get/setModel idea? -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
-1
I'm sorry, although I totally understand your argument, and how it may help
new users, but this will break already written code, will not add additional
level of functionality, and really it's just a matter of reading to
understand how IModel works, I did have difficulties when I started to
understand detachable models, but not the concept of the model itself.
Maybe new user need more detailed example and tutorials if they lack time
to read and understand the examples, which I still think they are available
around, and there is a book too, and there will be the long awaited wicket
book, that I can't really wait to get my hands on! :)
beside set value? what if it's not a value, I mean most of my models contain
an object with long list of values :)
One last thing, most of the programmers out there still don't use the OO
concept of programming, still don't implement proper patterns, and seriously
they don't think of interfaces for their design, I will have to include
myself with the lawzi ones (although I fully use OO even in database level),
I think we should not encourage this.
I'm sorry again
On 1/23/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere
or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since
our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived
from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first
paragraph
to be even more specific. Maybe it could be tweaked a little more,
but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in
turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.
In addition to rephrasing or rewriting a lot of material, and adding
a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more
advanced
More about
Models page.
igor.vaynberg wrote:
go ahead and edit the page...the wiki is versioned i think so we can
always
roll back.
when you are done with the majority let us know and we will review
the
changes.
-igor
On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:
When I first started using Wicket I found the information on models
a
little
hard to follow. So now I'd like to revise the Working with Wicket
models
wiki page
(
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
to improve this. I'd be happy to outline what I think
Re: [Wicket-user] VOTE: how should localized attributes work?
thus im quite new, 2[x] as its the only way to have a preview wich works in WYSIWYG editors and wont be ** up (hopefully...) by your next designer who changed the text so it looks better... On 8/3/06, Dirk Markert [EMAIL PROTECTED] wrote: 2 [x] 2006/8/3, Eelco Hillenius [EMAIL PROTECTED]: For localized attributes - so that you don't have to attach attribute modifiers all over the place for that sole reason - we have two alternative approaches in mind. For end-users this would either look like: 1) input type=submit value=wicket:i18n:my_key/ which is compact, or 2) input type=submit value=Default Value wicket:message=value:my_key/ which works better if you want to keep your components preview-able. What do you prefer (vote open to anyone that want to join in)? 1 [ ] 2 [ ] Eelco (I have to think about what I like a bit more myself, but currently I lean towards 2 as I think it is cleaner and supports preview-ability) -- --- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net 's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEV DEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- --- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEV DEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Scott Swank reformed mathematician -- --- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforge CID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
On Fri, 2006-08-04 at 08:50 +0200, Korbinian Bachl wrote: thus im quite new, 2[x] be ** up (hopefully...) by your next designer who changed the text so it looks better... This a good point, with option 1 it is likely that designers touch the value-attribute. In option 2, it doesn't matter. (i already voted, so don't recount this) Joni - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
1 [X]
Btw.
We are using ${key} everywhere (customized markup parsing) and it's much
more convenient than wicket:message :-)
-Matej
Eelco Hillenius wrote:
For localized attributes - so that you don't have to attach attribute
modifiers all over the place for that sole reason - we have two
alternative approaches in mind. For end-users this would either look
like:
1) input type=submit value=wicket:i18n:my_key/
which is compact, or
2) input type=submit value=Default Value wicket:message=value:my_key/
which works better if you want to keep your components preview-able.
What do you prefer (vote open to anyone that want to join in)?
1 [ ]
2 [ ]
Eelco
(I have to think about what I like a bit more myself, but currently I
lean towards 2 as I think it is cleaner and supports preview-ability)
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
1 [ ] 2 [X] input type=submit value=Default Value wicket:message=value:my_key/ If you want to express it without a default value, that would be written as: input type=submit value=my_key wicket:message=value/ And if Wicket is going to support multiple attributes: input type=submit value=my_value_key alt=my_alt_key wicket:message=value alt/ -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
But this:input type=submit value=my_key wicket:message=value/i really don't like.That is worsed of both worlds. You still don't have default/preview but you do have an extra input attribute to parse. Ok knowing that something must be i18n is easier.But you are right about that it looks neather when with multiply attributes.But this should also work fine:input type=submit value=Default Value alt=Test wicket:message=value:my_key alt:my_key2/ johanOn 8/4/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: 1 [ ]2 [X] input type=submit value=Default Value wicket:message=value:my_key/ If you want to express it without a default value, that would bewritten as:input type=submit value=my_key wicket:message=value/And if Wicket is going to support multiple attributes: input type=submit value=my_value_key alt=my_alt_key wicket:message=value alt/-- Jean-Baptiste QuenotakaJohn Banana Qwerty http://caraldi.com/jbq/-Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cashhttp://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
2 previewability is one of wicket's strong features Joni On Thu, 2006-08-03 at 11:10 -0700, Eelco Hillenius wrote: For localized attributes - so that you don't have to attach attribute modifiers all over the place for that sole reason - we have two alternative approaches in mind. For end-users this would either look like: 1) input type=submit value=wicket:i18n:my_key/ which is compact, or 2) input type=submit value=Default Value wicket:message=value:my_key/ which works better if you want to keep your components preview-able. What do you prefer (vote open to anyone that want to join in)? 1 [ ] 2 [ ] Eelco (I have to think about what I like a bit more myself, but currently I lean towards 2 as I think it is cleaner and supports preview-ability) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
2 [x] Eelco Hillenius a écrit : For localized attributes - so that you don't have to attach attribute modifiers all over the place for that sole reason - we have two alternative approaches in mind. For end-users this would either look like: 1) input type=submit value=wicket:i18n:my_key/ which is compact, or 2) input type=submit value=Default Value wicket:message=value:my_key/ which works better if you want to keep your components preview-able. What do you prefer (vote open to anyone that want to join in)? 1 [ ] 2 [ ] Eelco (I have to think about what I like a bit more myself, but currently I lean towards 2 as I think it is cleaner and supports preview-ability) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
1 [x]-IgorOn 8/3/06, Eelco Hillenius [EMAIL PROTECTED] wrote: For localized attributes - so that you don't have to attach attributemodifiers all over the place for that sole reason - we have twoalternative approaches in mind. For end-users this would either looklike: 1) input type=submit value=wicket:i18n:my_key/which is compact, or2) input type=submit value=Default Value wicket:message=value:my_key/ which works better if you want to keep your components preview-able.What do you prefer (vote open to anyone that want to join in)?1 []2 []Eelco(I have to think about what I like a bit more myself, but currently I lean towards 2 as I think it is cleaner and supports preview-ability)-Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net 's Techsay panel and you'll get the chance to share youropinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
if we have to choose for one then 2but i think we can support both, i think it can just be a markupfilter/parser implementation per option.johanOn 8/3/06, Eelco Hillenius [EMAIL PROTECTED] wrote: For localized attributes - so that you don't have to attach attributemodifiers all over the place for that sole reason - we have twoalternative approaches in mind. For end-users this would either looklike: 1) input type=submit value=wicket:i18n:my_key/which is compact, or2) input type=submit value=Default Value wicket:message=value:my_key/ which works better if you want to keep your components preview-able.What do you prefer (vote open to anyone that want to join in)?1 []2 []Eelco(I have to think about what I like a bit more myself, but currently I lean towards 2 as I think it is cleaner and supports preview-ability)-Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net 's Techsay panel and you'll get the chance to share youropinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
Yeah, but we have to choose a default here. Unless you want to support those two options at the same time. Eelco On 8/3/06, Johan Compagner [EMAIL PROTECTED] wrote: if we have to choose for one then 2 but i think we can support both, i think it can just be a markupfilter/parser implementation per option. johan On 8/3/06, Eelco Hillenius [EMAIL PROTECTED] wrote: For localized attributes - so that you don't have to attach attribute modifiers all over the place for that sole reason - we have two alternative approaches in mind. For end-users this would either look like: 1) input type=submit value=wicket:i18n:my_key/ which is compact, or 2) input type=submit value=Default Value wicket:message=value:my_key/ which works better if you want to keep your components preview-able. What do you prefer (vote open to anyone that want to join in)? 1 [ ] 2 [ ] Eelco (I have to think about what I like a bit more myself, but currently I lean towards 2 as I think it is cleaner and supports preview-ability) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net 's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
If you want the opinion of non-committers, here's a strong preference for 2 [X] The thought of seeing the wicket... text in preview mode really goes against the grain to me. -- Scott Eelco Hillenius wrote: For localized attributes - so that you don't have to attach attribute modifiers all over the place for that sole reason - we have two alternative approaches in mind. For end-users this would either look like: 1) input type=submit value=wicket:i18n:my_key/ which is compact, or 2) input type=submit value=Default Value wicket:message=value:my_key/ which works better if you want to keep your components preview-able. What do you prefer (vote open to anyone that want to join in)? 1 [ ] 2 [ ] Eelco (I have to think about what I like a bit more myself, but currently I lean towards 2 as I think it is cleaner and supports preview-ability) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
All votes count for this thread as far as I am concerned. Eelco On 8/3/06, Scott Sauyet [EMAIL PROTECTED] wrote: If you want the opinion of non-committers, here's a strong preference for 2 [X] The thought of seeing the wicket... text in preview mode really goes against the grain to me. -- Scott Eelco Hillenius wrote: For localized attributes - so that you don't have to attach attribute modifiers all over the place for that sole reason - we have two alternative approaches in mind. For end-users this would either look like: 1) input type=submit value=wicket:i18n:my_key/ which is compact, or 2) input type=submit value=Default Value wicket:message=value:my_key/ which works better if you want to keep your components preview-able. What do you prefer (vote open to anyone that want to join in)? 1 [ ] 2 [ ] Eelco (I have to think about what I like a bit more myself, but currently I lean towards 2 as I think it is cleaner and supports preview-ability) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
2 [x] Wilko -- View this message in context: http://www.nabble.com/VOTE%3A-how-should-localized-attributes-work--tf2047179.html#a5639800 Sent from the Wicket - User forum at Nabble.com. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
2 [ X ] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
2 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
2 [x] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
2 [x] On 8/3/06, Frank Bille [EMAIL PROTECTED] wrote: 2 [x] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
2[x] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
2 [X] --- Eelco Hillenius [EMAIL PROTECTED] wrote: For localized attributes - so that you don't have to attach attribute modifiers all over the place for that sole reason - we have two alternative approaches in mind. For end-users this would either look like: 1) input type=submit value=wicket:i18n:my_key/ which is compact, or 2) input type=submit value=Default Value wicket:message=value:my_key/ which works better if you want to keep your components preview-able. What do you prefer (vote open to anyone that want to join in)? 1 [ ] 2 [ ] Eelco (I have to think about what I like a bit more myself, but currently I lean towards 2 as I think it is cleaner and supports preview-ability) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
2 [X]On 8/3/06, MK Tan [EMAIL PROTECTED] wrote: 2 [X]--- Eelco Hillenius [EMAIL PROTECTED] wrote: For localized attributes - so that you don't have to attach attribute modifiers all over the place for that sole reason - we have two alternative approaches in mind. For end-users this would either look like: 1) input type=submit value=wicket:i18n:my_key/ which is compact, or 2) input type=submit value=Default Value wicket:message=value:my_key/ which works better if you want to keep your components preview-able. What do you prefer (vote open to anyone that want to join in)? 1 [] 2 [] Eelco (I have to think about what I like a bit more myself, but currently I lean towards 2 as I think it is cleaner and supports preview-ability)- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user__ Do You Yahoo!?Tired of spam?Yahoo! Mail has the best spam protection aroundhttp://mail.yahoo.com- Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay panel and you'll get the chance to share youropinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
2 [x]2006/8/3, Eelco Hillenius [EMAIL PROTECTED]: For localized attributes - so that you don't have to attach attributemodifiers all over the place for that sole reason - we have twoalternative approaches in mind. For end-users this would either looklike: 1) input type=submit value=wicket:i18n:my_key/which is compact, or2) input type=submit value=Default Value wicket:message=value:my_key/ which works better if you want to keep your components preview-able.What do you prefer (vote open to anyone that want to join in)?1 []2 []Eelco(I have to think about what I like a bit more myself, but currently I lean towards 2 as I think it is cleaner and supports preview-ability)-Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net 's Techsay panel and you'll get the chance to share youropinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
2 [x] On 8/3/06, Dirk Markert [EMAIL PROTECTED] wrote: 2 [x] 2006/8/3, Eelco Hillenius [EMAIL PROTECTED]: For localized attributes - so that you don't have to attach attribute modifiers all over the place for that sole reason - we have two alternative approaches in mind. For end-users this would either look like: 1) input type=submit value=wicket:i18n:my_key/ which is compact, or 2) input type=submit value=Default Value wicket:message=value:my_key/ which works better if you want to keep your components preview-able. What do you prefer (vote open to anyone that want to join in)? 1 [ ] 2 [ ] Eelco (I have to think about what I like a bit more myself, but currently I lean towards 2 as I think it is cleaner and supports preview-ability) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net 's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Scott Swank reformed mathematician - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
2 - Original Message - From: Dirk Markert To: wicket-user@lists.sourceforge.net Sent: Friday, August 04, 2006 12:32 PM Subject: Re: [Wicket-user] VOTE: how should localized attributes work? 2 [x] 2006/8/3, Eelco Hillenius [EMAIL PROTECTED]: For localized attributes - so that you don't have to attach attributemodifiers all over the place for that sole reason - we have twoalternative approaches in mind. For end-users this would either looklike:1) input type="submit" value="wicket:i18n:my_key"/which is compact, or2) input type="submit" value="Default Value" wicket:message="value:my_key"/ which works better if you want to keep your components preview-able.What do you prefer (vote open to anyone that want to join in)?1 []2 []Eelco(I have to think about what I like a bit more myself, but currently I lean towards 2 as I think it is cleaner and supports preview-ability)-Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net 's Techsay panel and you'll get the chance to share youropinions on IT business topics through brief surveys -- and earn cashhttp://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay panel and you'll get the chance to share youropinions on IT business topics through brief surveys -- and earn cashhttp://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
2 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
1 [X] as in this case every attribute would be assignable from java Imran - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
Hey, you cheat! You voted twice! :) Eelco On 8/3/06, Nick Heudecker [EMAIL PROTECTED] wrote: 2 [X] On 8/3/06, MK Tan [EMAIL PROTECTED] wrote: 2 [X] --- Eelco Hillenius [EMAIL PROTECTED] wrote: For localized attributes - so that you don't have to attach attribute modifiers all over the place for that sole reason - we have two alternative approaches in mind. For end-users this would either look like: 1) input type=submit value=wicket:i18n:my_key/ which is compact, or 2) input type=submit value=Default Value wicket:message=value:my_key/ which works better if you want to keep your components preview-able. What do you prefer (vote open to anyone that want to join in)? 1 [ ] 2 [ ] Eelco (I have to think about what I like a bit more myself, but currently I lean towards 2 as I think it is cleaner and supports preview-ability) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: how should localized attributes work?
he is a witch! throw him in the lake! if he floats that will prove he is a witch and then we burn him. if he drowns he wasnt a witch, we let him go.-IgorOn 8/3/06, Eelco Hillenius [EMAIL PROTECTED] wrote: Hey, you cheat! You voted twice! :)Eelco - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: ListView.setUseOptimizedItemRemoval()
+1 depricate the oldOn 4/21/06, Juergen Donnerstag [EMAIL PROTECTED] wrote: +1On 4/21/06, Martijn Dashorst [EMAIL PROTECTED] wrote: +1 On 4/21/06, Vincent Jenks [EMAIL PROTECTED] wrote: +1 - it's certainly easier on the eyes. On 4/21/06, Igor Vaynberg [EMAIL PROTECTED] wrote: +1 we can deprecate the existing one and have it forward to the new one as not to break the api. then remove the deprecated method once 1.2 is out of the door. -Igor On 4/21/06, cowwoc [EMAIL PROTECTED] wrote: I vote in favor of renaming setUseOptimizedItemRemoval() to setReuseItems() because I feel it is more descriptive of what itactually does. What do the rest of you think? Thanks,Gili --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmdlnkkid0709bid3057dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Wicket 1.2 is coming! Write Ajax applications without touching _javascript_! -- http://wicketframework.org---Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimohttp://sel.as-us.falkag.net/sel?cmdlnkkid0709bid3057dat1642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: ListView.setUseOptimizedItemRemoval()
doneOn 4/22/06, Johan Compagner [EMAIL PROTECTED] wrote: +1 depricate the oldOn 4/21/06, Juergen Donnerstag [EMAIL PROTECTED] wrote: +1On 4/21/06, Martijn Dashorst [EMAIL PROTECTED] wrote: +1 On 4/21/06, Vincent Jenks [EMAIL PROTECTED] wrote: +1 - it's certainly easier on the eyes. On 4/21/06, Igor Vaynberg [EMAIL PROTECTED] wrote: +1 we can deprecate the existing one and have it forward to the new one as not to break the api. then remove the deprecated method once 1.2 is out of the door. -Igor On 4/21/06, cowwoc [EMAIL PROTECTED] wrote: I vote in favor of renaming setUseOptimizedItemRemoval() to setReuseItems() because I feel it is more descriptive of what itactually does. What do the rest of you think? Thanks,Gili --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmdlnkkid0709bid3057dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Wicket 1.2 is coming! Write Ajax applications without touching _javascript_! -- http://wicketframework.org---Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmdlnkkid0709bid3057dat1642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: ListView.setUseOptimizedItemRemoval()
I'm not sure setReuseItems is the best name, but I not a friend of setUseOptimizedItemRemoval. Eelco On 4/21/06, Igor Vaynberg [EMAIL PROTECTED] wrote: +1 we can deprecate the existing one and have it forward to the new one as not to break the api. then remove the deprecated method once 1.2 is out of the door. -Igor On 4/21/06, cowwoc [EMAIL PROTECTED] wrote: I vote in favor of renaming setUseOptimizedItemRemoval() to setReuseItems() because I feel it is more descriptive of what it actually does. What do the rest of you think? Thanks, Gili --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: ListView.setUseOptimizedItemRemoval()
+1we can deprecate the existing one and have it forward to the new one as not to break the api. then remove the deprecated method once 1.2 is out of the door.-Igor On 4/21/06, cowwoc [EMAIL PROTECTED] wrote: I vote in favor of renaming setUseOptimizedItemRemoval() tosetReuseItems() because I feel it is more descriptive of what itactually does. What do the rest of you think?Thanks,Gili
Re: [Wicket-user] VOTE: ListView.setUseOptimizedItemRemoval()
+1On 4/21/06, Vincent Jenks [EMAIL PROTECTED] wrote: +1 - it's certainly easier on the eyes.On 4/21/06, Igor Vaynberg [EMAIL PROTECTED] wrote: +1 we can deprecate the existing one and have it forward to the new one as not to break the api. then remove the deprecated method once 1.2 is out of the door. -IgorOn 4/21/06, cowwoc [EMAIL PROTECTED] wrote: I vote in favor of renaming setUseOptimizedItemRemoval() to setReuseItems() because I feel it is more descriptive of what it actually does. What do the rest of you think? Thanks, Gili---Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmdlnkkid0709bid3057dat1642___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user-- Wicket 1.2 is coming! Write Ajax applications without touching _javascript_! -- http://wicketframework.org
Re: [Wicket-user] VOTE: One refactor to do in 1.2 if possible: String Param or Returntype to its interface CharSequence..
+1 to do it now. if this does affect 1.2 only interfaces a lot then we should do this before we actually release those interfaces into the wild. -Igor On 4/1/06, Johan Compagner [EMAIL PROTECTED] wrote: Currently almost all our interfaces that makes the output or Response writing code are using Stringsas parameters or return typesI would like to change all those methods to use Charsequence because this would mean that we don't have to do toString() every where and just passing directly the buffer that was madeThis will greatly reduce String char array copies.This does mean that for example:Response.write(String) - Response.write(CharSequence)andprotected final void replaceComponentTagBody(final MarkupStream markupStream, final ComponentTag tag, final String body)protected final void replaceComponentTagBody(final MarkupStream markupStream, final ComponentTag tag, final CharSequence body)for calling methods nothing will really change because the String maps on its interface.Only when users have implemented such a method they should also convert so for the above replaceComponentTagBody this is not a problem because it is final anywayBut for Response.write() subclasses should also be refactored.Don't know currently yet how many overridable methods really would be affected. But it could enhance performance quite a bit.Many of the interfaces that would affected are 1.2 only interfaces so if we change them nowthose interfaces never made it to a final version.So what should we do: [ ] do it in 1.2[ ] do it in 2.0/1.3 with another big refactor? (then interfaces introduced in 1.2 will change again)[ ] never do it.johan
Re: [Wicket-user] VOTE: One refactor to do in 1.2 if possible: String Param or Returntype to its interface CharSequence..
if it is it is a final methodso it doesn't matter it can only be called onso calling it with the same code that is a string just compiles fineand you can't override it (that would be a problem because then they also need to change the signature) johanOn 4/1/06, Juergen Donnerstag [EMAIL PROTECTED] wrote: +1 for now. For all new 1.2 interfaces and methods and for internalmethods (incl. pre 1.2).Did we add replaceComponentTagBody in 1.2? If not, that should not(yet) be changed. Especially as I can imagine that this function is used by some users.JuergenOn 4/1/06, Igor Vaynberg [EMAIL PROTECTED] wrote: +1 to do it now. if this does affect 1.2 only interfaces a lot then we should do this before we actually release those interfaces into the wild.-Igor On 4/1/06, Johan Compagner [EMAIL PROTECTED] wrote: Currently almost all our interfaces that makes the output or Response writing code are using Strings as parameters or return types I would like to change all those methods to use Charsequence because this would mean that we don't have to do toString() every where and just passing directly the buffer that was made This will greatly reduce String char array copies. This does mean that for example: Response.write(String) - Response.write(CharSequence) and protected final void replaceComponentTagBody(final MarkupStream markupStream, final ComponentTag tag, final String body) protected final void replaceComponentTagBody(final MarkupStream markupStream, final ComponentTag tag, final CharSequence body) for calling methods nothing will really change because the String maps on its interface. Only when users have implemented such a method they should also convert so for the above replaceComponentTagBody this is not a problem because it is final anyway But for Response.write() subclasses should also be refactored. Don't know currently yet how many overridable methods really would be affected. But it could enhance performance quite a bit. Many of the interfaces that would affected are 1.2 only interfaces so if we change them now those interfaces never made it to a final version. So what should we do: [ ] do it in 1.2 [ ] do it in 2.0/1.3 with another big refactor? (then interfaces introduced in 1.2 will change again) [ ] never do it.johan ---This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!http://sel.as-us.falkag.net/sel?cmdlnkkid0944bid$1720dat1642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: One refactor to do in 1.2 if possible: String Param or Returntype to its interface CharSequence..
+1 for now. For all new 1.2 interfaces and methods and for internal methods (incl. pre 1.2). Did we add replaceComponentTagBody in 1.2? If not, that should not (yet) be changed. Especially as I can imagine that this function is used by some users. Juergen On 4/1/06, Igor Vaynberg [EMAIL PROTECTED] wrote: +1 to do it now. if this does affect 1.2 only interfaces a lot then we should do this before we actually release those interfaces into the wild. -Igor On 4/1/06, Johan Compagner [EMAIL PROTECTED] wrote: Currently almost all our interfaces that makes the output or Response writing code are using Strings as parameters or return types I would like to change all those methods to use Charsequence because this would mean that we don't have to do toString() every where and just passing directly the buffer that was made This will greatly reduce String char array copies. This does mean that for example: Response.write(String) - Response.write(CharSequence) and protected final void replaceComponentTagBody(final MarkupStream markupStream, final ComponentTag tag, final String body) protected final void replaceComponentTagBody(final MarkupStream markupStream, final ComponentTag tag, final CharSequence body) for calling methods nothing will really change because the String maps on its interface. Only when users have implemented such a method they should also convert so for the above replaceComponentTagBody this is not a problem because it is final anyway But for Response.write() subclasses should also be refactored. Don't know currently yet how many overridable methods really would be affected. But it could enhance performance quite a bit. Many of the interfaces that would affected are 1.2 only interfaces so if we change them now those interfaces never made it to a final version. So what should we do: [ ] do it in 1.2 [ ] do it in 2.0/1.3 with another big refactor? (then interfaces introduced in 1.2 will change again) [ ] never do it. johan --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: One refactor to do in 1.2 if possible: String Param or Returntype to its interface CharSequence..
+1 for now. Eelco On 4/1/06, Johan Compagner [EMAIL PROTECTED] wrote: Currently almost all our interfaces that makes the output or Response writing code are using Strings as parameters or return types I would like to change all those methods to use Charsequence because this would mean that we don't have to do toString() every where and just passing directly the buffer that was made This will greatly reduce String char array copies. This does mean that for example: Response.write(String) - Response.write(CharSequence) and protected final void replaceComponentTagBody(final MarkupStream markupStream, final ComponentTag tag, final String body) protected final void replaceComponentTagBody(final MarkupStream markupStream, final ComponentTag tag, final CharSequence body) for calling methods nothing will really change because the String maps on its interface. Only when users have implemented such a method they should also convert so for the above replaceComponentTagBody this is not a problem because it is final anyway But for Response.write() subclasses should also be refactored. Don't know currently yet how many overridable methods really would be affected. But it could enhance performance quite a bit. Many of the interfaces that would affected are 1.2 only interfaces so if we change them now those interfaces never made it to a final version. So what should we do: [ ] do it in 1.2 [ ] do it in 2.0/1.3 with another big refactor? (then interfaces introduced in 1.2 will change again) [ ] never do it. johan --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: One refactor to do in 1.2 if possible: String Param or Returntype to its interface CharSequence..
+1, not breaking existing 1.1 api's.MartijnOn 4/1/06, Eelco Hillenius [EMAIL PROTECTED] wrote:+1 for now.EelcoOn 4/1/06, Johan Compagner [EMAIL PROTECTED] wrote: Currently almost all our interfaces that makes the output or Response writing code are using Strings as parameters or return types I would like to change all those methods to use Charsequence because this would mean that we don't have to do toString() every where and just passing directly the buffer that was made This will greatly reduce String char array copies. This does mean that for example: Response.write(String) - Response.write(CharSequence) and protected final void replaceComponentTagBody(final MarkupStream markupStream, final ComponentTag tag, final String body) protected final void replaceComponentTagBody(final MarkupStream markupStream, final ComponentTag tag, final CharSequence body) for calling methods nothing will really change because the String maps on its interface. Only when users have implemented such a method they should also convert so for the above replaceComponentTagBody this is not a problem because it is final anyway But for Response.write() subclasses should also be refactored. Don't know currently yet how many overridable methods really would be affected. But it could enhance performance quite a bit. Many of the interfaces that would affected are 1.2 only interfaces so if we change them now those interfaces never made it to a final version. So what should we do: [ ] do it in 1.2 [ ] do it in 2.0/1.3 with another big refactor? (then interfaces introduced in 1.2 will change again) [ ] never do it. johan--- This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcastand join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmdlnkkid0944bid$1720dat1642___ Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user -- Wicket 1.2 is coming! Write Ajax applications without touching _javascript_!-- http://wicketframework.org
Re: [Wicket-user] VOTE: One refactor to do in 1.2 if possible: String Param or Returntype to its interface CharSequence..
I think i have it all in now.There isn't much outside used api touched because if i just look what lines i needed to change over all the contrib libs (didn't check those in yet)it where only a very few and it was just adding toString() or changing String to CharSequence. And also another project iridium (topicus) just compiles it doesn't complain at allI think this is because i just stopped at one point and that are 2 methods that could be a CharSequence return type but i kept them as strings (FormComponent.getValue() and Component.getModelObjectAsString())Because that did break to much so i didn't alter themjohanOn 4/1/06, Eelco Hillenius [EMAIL PROTECTED] wrote: +1 for now.EelcoOn 4/1/06, Johan Compagner [EMAIL PROTECTED] wrote: Currently almost all our interfaces that makes the output or Response writing code are using Strings as parameters or return types I would like to change all those methods to use Charsequence because this would mean that we don't have to do toString() every where and just passing directly the buffer that was made This will greatly reduce String char array copies. This does mean that for example: Response.write(String) - Response.write(CharSequence) and protected final void replaceComponentTagBody(final MarkupStream markupStream, final ComponentTag tag, final String body) protected final void replaceComponentTagBody(final MarkupStream markupStream, final ComponentTag tag, final CharSequence body) for calling methods nothing will really change because the String maps on its interface. Only when users have implemented such a method they should also convert so for the above replaceComponentTagBody this is not a problem because it is final anyway But for Response.write() subclasses should also be refactored. Don't know currently yet how many overridable methods really would be affected. But it could enhance performance quite a bit. Many of the interfaces that would affected are 1.2 only interfaces so if we change them now those interfaces never made it to a final version. So what should we do: [ ] do it in 1.2 [ ] do it in 2.0/1.3 with another big refactor? (then interfaces introduced in 1.2 will change again) [ ] never do it. johan---This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!http://sel.as-us.falkag.net/sel?cmdlnkkid0944bid$1720dat1642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: Results so far (was Re: [Wicket-user] VOTE)
Is the voting officially closed ? :) and does that mean 'constructor and JDK5' will come packaged as one release wicket 2.0? On 2/21/06, Al Maw [EMAIL PROTECTED] wrote: Alexandru Popescu wrote: I know that this might be early considering the lenght of the thread, but what is the voting result? :-). So far I count: 40 votes for both at once (constructor and JDK5) 17 votes for split releases (16 plus me, I'm voting now. :-) ) Al --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- -- karthik -- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: Results so far (was Re: [Wicket-user] VOTE)
The vote isn't officially closed. We didn't set a time limit at beforehand. It is probably dead though :)In this case, the vote was NON-binding. That basically means that the core team can do whatever we want, ignoring everything and build Wicket 2 on dolphin (Java 7). Surpise! We haven't started discussing the benefits of either option, and I'm not starting to do so here. :-) That is for another thread.And AFAICR I haven't voted yet... and I'm still torn between the two choices. MartijnOn 2/22/06, karthik Guru [EMAIL PROTECTED] wrote: Is the voting officially closed ? :)and does that mean 'constructor and JDK5' will come packaged as one releasewicket 2.0?On 2/21/06, Al Maw [EMAIL PROTECTED] wrote: Alexandru Popescu wrote: I know that this might be early considering the lenght of the thread, but what is the voting result? :-). So far I count:40 votes for both at once (constructor and JDK5) 17 votes for split releases (16 plus me, I'm voting now. :-) ) Al --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user-- -- karthik -- ---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___ Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user -- Living a wicket life...Martijn Dashorst - http://www.jroller.com/page/dashorstWicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
Re: Results so far (was Re: [Wicket-user] VOTE)
and we could interpreted the results this way that there are still quite a number of persons that can't use 1.5 yet.So it is not a pure democratic vote but just the get a feeling how many people would be really set backed by directly 1.5I still believe that you can live without it, but you can't live with it if the jvm choice is not in youre hands.johanOn 2/22/06, Martijn Dashorst [EMAIL PROTECTED] wrote: The vote isn't officially closed. We didn't set a time limit at beforehand. It is probably dead though :)In this case, the vote was NON-binding. That basically means that the core team can do whatever we want, ignoring everything and build Wicket 2 on dolphin (Java 7). Surpise! We haven't started discussing the benefits of either option, and I'm not starting to do so here. :-) That is for another thread.And AFAICR I haven't voted yet... and I'm still torn between the two choices. MartijnOn 2/22/06, karthik Guru [EMAIL PROTECTED] wrote: Is the voting officially closed ? :)and does that mean 'constructor and JDK5' will come packaged as one releasewicket 2.0?On 2/21/06, Al Maw [EMAIL PROTECTED] wrote: Alexandru Popescu wrote: I know that this might be early considering the lenght of the thread, but what is the voting result? :-). So far I count:40 votes for both at once (constructor and JDK5) 17 votes for split releases (16 plus me, I'm voting now. :-) ) Al --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- -- karthik -- ---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___ Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Living a wicket life...Martijn Dashorst - http://www.jroller.com/page/dashorstWicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
Re: Results so far (was Re: [Wicket-user] VOTE)
and yeah more expected to come in :) On 2/22/06, karthik Guru [EMAIL PROTECTED] wrote: Ok for the benefit of others, the summary of vote that actually matters - . Igor - 1 Johan - 2 Eelco - 1 So , 2 votes for both at once (constructor and JDK5) 1 vote for split releases -- -- karthik -- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: Results so far (was Re: [Wicket-user] VOTE)
I agree with Johan here. I want to start discussing it on the admin list shortly. But it looks like there are enough for 2 - not the majority, but enough - to make seperate releases. We should decide on whether 1.2. (we might call that version differently actually, but that's another question) or 1.3. is going to be our long running supported version. I think the latter, and 1.2. based on requests, but we have yet to discuss that. Btw Jonathan's vote was #2 - he sent me that offline. We'll give you an update later this week or this weekend. Thanks for voting all! Eelco On 2/22/06, karthik Guru [EMAIL PROTECTED] wrote: and yeah more expected to come in :) On 2/22/06, karthik Guru [EMAIL PROTECTED] wrote: Ok for the benefit of others, the summary of vote that actually matters - . Igor - 1 Johan - 2 Eelco - 1 So , 2 votes for both at once (constructor and JDK5) 1 vote for split releases -- -- karthik -- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
RE: Results so far (was Re: [Wicket-user] VOTE)
I may be offering an opinion on something already decided, but it seems to me that if we change the constructors in an earlier release, and then go to Java 1.5 on a subsequent release, if that makes maintenance of two versions easier (post-1.5 and pre-1.5) easier. Advantages: (1) Less future work for the developers means faster improvement to Wicket in the long run. (2) The applications produced by users who cannot upgrade to 1.5 yet will be easier to upgrade when they finally can do so -- the obsolete user code they're accumulating won't be quite so obsolete. (3) The inconvenience of upgrading user code in two phases (for those who have no impediments to using Java 1.5 now) is a transitory problem. Of course, one could make this argument about any code-breaking change to the API, delaying the upgrade to Java 1.5 indefinitely. But I'm assuming that the constructor changes are an unusually severe break in the API. /Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eelco Hillenius Sent: Wednesday, February 22, 2006 10:15 AM To: wicket-user@lists.sourceforge.net Subject: Re: Results so far (was Re: [Wicket-user] VOTE) I agree with Johan here. I want to start discussing it on the admin list shortly. But it looks like there are enough for 2 - not the majority, but enough - to make seperate releases. We should decide on whether 1.2. (we might call that version differently actually, but that's another question) or 1.3. is going to be our long running supported version. I think the latter, and 1.2. based on requests, but we have yet to discuss that. Btw Jonathan's vote was #2 - he sent me that offline. We'll give you an update later this week or this weekend. Thanks for voting all! Eelco On 2/22/06, karthik Guru [EMAIL PROTECTED] wrote: and yeah more expected to come in :) On 2/22/06, karthik Guru [EMAIL PROTECTED] wrote: Ok for the benefit of others, the summary of vote that actually matters - . Igor - 1 Johan - 2 Eelco - 1 So , 2 votes for both at once (constructor and JDK5) 1 vote for split releases -- -- karthik -- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: Results so far (was Re: [Wicket-user] VOTE)
assuming that the constructor changes are an unusually severe break in the API. It's a severe break indeed. BUT to the upside, with a very easy fix. It's just big because it'll break most of your code instead of just a few areas. Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: Results so far (was Re: [Wicket-user] VOTE)
an easy fix in /most/ cases. there will be situations that are harder to fix then others.-IgorOn 2/22/06, Eelco Hillenius [EMAIL PROTECTED] wrote: assuming that the constructor changes are an unusually severe break in the API.It's a severe break indeed. BUT to the upside, with a very easy fix.It's just big because it'll break most of your code instead of just afew areas.Eelco--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___ Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: Results so far (was Re: [Wicket-user] VOTE)
Which ones? Do we have a list? Eelco On 2/22/06, Igor Vaynberg [EMAIL PROTECTED] wrote: an easy fix in /most/ cases. there will be situations that are harder to fix then others. -Igor On 2/22/06, Eelco Hillenius [EMAIL PROTECTED] wrote: assuming that the constructor changes are an unusually severe break in the API. It's a severe break indeed. BUT to the upside, with a very easy fix. It's just big because it'll break most of your code instead of just a few areas. Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: Results so far (was Re: [Wicket-user] VOTE)
i havent thought about it /that/ much. but for example if you have a factory, the factory will need to be refactored.also situations where you are creating components but not yet adding them to the parent will have to be refactored to work differently. although i think this is an edge case. -IgorOn 2/22/06, Eelco Hillenius [EMAIL PROTECTED] wrote: Which ones? Do we have a list?EelcoOn 2/22/06, Igor Vaynberg [EMAIL PROTECTED] wrote: an easy fix in /most/ cases. there will be situations that are harder to fix then others. -Igor On 2/22/06, Eelco Hillenius [EMAIL PROTECTED] wrote:assuming that the constructor changes are an unusually severe break in the API. It's a severe break indeed. BUT to the upside, with a very easy fix. It's just big because it'll break most of your code instead of just a few areas. Eelco--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___ Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: Results so far (was Re: [Wicket-user] VOTE)
It's not about not wanting to go for Java 1.5. But more a I can't or my company can't. I have no choice here. On 2/21/06, Christian Hvid [EMAIL PROTECTED] wrote: I am one for a move to Java 5 as fast as possible. From my perspective Wicket is a young framework and if we are adventurously enough to choose Wicket, we are adventurously enough to be on Java 5. On 21 Feb 2006, at 00:27, Al Maw wrote: Alexandru Popescu wrote: I know that this might be early considering the lenght of the thread, but what is the voting result? :-). So far I count: 40 votes for both at once (constructor and JDK5) 17 votes for split releases (16 plus me, I'm voting now. :-) ) Al --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel? cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE
1. Give me the constructor change and the Java 5 functionality in one pass (Wicket 2.0)+1 -- The more life's risk you take, the more life's reward you get - Me
Re: [Wicket-user] VOTE
#QuoteI vote for 2. 2. Do the constructor change in a seperate release (Wicket 1.3) andput Java 5 in the next (Wicket 2.0)On 2/16/06, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi all,This is a non-binding (the developers ultimately decide) call votesconcerning whether we should fold the upcomming constructor changeswith our move to Java 5 or not. See for a discussion of those changes other threads, please use this thread for voting only.1. Give me the constructor change and the Java 5 functionality in onepass (Wicket 2.0)2. Do the constructor change in a seperate release (Wicket 1.3 ) andput Java 5 in the next (Wicket 2.0)3. I don't want either one and I want to stay on Wicket 1.2.This last option has no real effect except that you explicitly saythat you prefer a long lasting support on 1.2 over new features.Also, take into consideration that the less versions we have tomaintain seperately, the quicker we probably can implement them.Your votes please?Btw, it is still our plan to be up-to-date with Wicket In Action. Eelco---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE
I vote for #1. I want the latest and greatest -- thats why I'm into wicket! /Fredrik --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE
Eelco Hillenius wrote: 1. Give me the constructor change and the Java 5 functionality in one pass (Wicket 2.0) 2. Do the constructor change in a seperate release (Wicket 1.3) and put Java 5 in the next (Wicket 2.0) 3. I don't want either one and I want to stay on Wicket 1.2. I vote for #2 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE
I know that this might be early considering the lenght of the thread, but what is the voting result? :-). BR, ./alex -- .w( the_mindstorm )p. On 2/17/06, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi all, This is a non-binding (the developers ultimately decide) call votes concerning whether we should fold the upcomming constructor changes with our move to Java 5 or not. See for a discussion of those changes other threads, please use this thread for voting only. 1. Give me the constructor change and the Java 5 functionality in one pass (Wicket 2.0) 2. Do the constructor change in a seperate release (Wicket 1.3) and put Java 5 in the next (Wicket 2.0) 3. I don't want either one and I want to stay on Wicket 1.2. This last option has no real effect except that you explicitly say that you prefer a long lasting support on 1.2 over new features. Also, take into consideration that the less versions we have to maintain seperately, the quicker we probably can implement them. Your votes please? Btw, it is still our plan to be up-to-date with Wicket In Action. Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Good news. We've just decided you're not trolls. bahrahrhum. Alexandru Popescu wrote: I know that this might be early considering the lenght of the thread, but what is the voting result? :-). BR, ./alex -- .w( the_mindstorm )p. On 2/17/06, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi all, This is a non-binding (the developers ultimately decide) call votes concerning whether we should fold the upcomming constructor changes with our move to Java 5 or not. See for a discussion of those changes other threads, please use this thread for voting only. 1. Give me the constructor change and the Java 5 functionality in one pass (Wicket 2.0) 2. Do the constructor change in a seperate release (Wicket 1.3) and put Java 5 in the next (Wicket 2.0) 3. I don't want either one and I want to stay on Wicket 1.2. This last option has no real effect except that you explicitly say that you prefer a long lasting support on 1.2 over new features. Also, take into consideration that the less versions we have to maintain seperately, the quicker we probably can implement them. Your votes please? Btw, it is still our plan to be up-to-date with Wicket In Action. Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - -- Justin Lee http://www.antwerkz.com AIM : evan chooly 720.299.0101 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) iD8DBQFD+kaXJnQfEGuJ90MRA2isAKDGMK3tTb0aegTc+OakUyIJ/BRCOgCgrm9B 0QFkqzqFBPGXRpRcO8dHM7I= =EmWT -END PGP SIGNATURE- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Results so far (was Re: [Wicket-user] VOTE)
Alexandru Popescu wrote: I know that this might be early considering the lenght of the thread, but what is the voting result? :-). So far I count: 40 votes for both at once (constructor and JDK5) 17 votes for split releases (16 plus me, I'm voting now. :-) ) Al --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: Results so far (was Re: [Wicket-user] VOTE)
I am one for a move to Java 5 as fast as possible. From my perspective Wicket is a young framework and if we are adventurously enough to choose Wicket, we are adventurously enough to be on Java 5. On 21 Feb 2006, at 00:27, Al Maw wrote: Alexandru Popescu wrote: I know that this might be early considering the lenght of the thread, but what is the voting result? :-). So far I count: 40 votes for both at once (constructor and JDK5) 17 votes for split releases (16 plus me, I'm voting now. :-) ) Al --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel? cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE
My vote goes to 1. 1. Give me the constructor change and the Java 5 functionality in one pass (Wicket 2.0) 2. Do the constructor change in a seperate release (Wicket 1.3) and put Java 5 in the next (Wicket 2.0) 3. I don't want either one and I want to stay on Wicket 1.2. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE
+1 1. Give me the constructor change and the Java 5 functionality in one pass (Wicket 2.0)
Re: [Wicket-user] VOTE
2. Do the constructor change in a seperate release (Wicket 1.3) andput Java 5 in the next (Wicket 2.0)I would like to see the constructor change as soon as possible, as it is a bit of a thorn in the paw when using wicket. Watching the cvs commits, the rate of development on wicket is impressive. I'm afraid once you guys get your hands on java 5, you won't be able to hold back on new features and the joint release will be a long time coming.
