Re: [Wicket-user] ui framework choice
I was able to test some ajax functionality by firing events with WicketTester, but something related to forms not. The problematic form thing I just tested with Wicket Bench then. If anyone is interested I can cook up a quickstart representing the WicketTester-with-ajaxified-form problem. On Fri, 02 Feb 2007, Johan Compagner wrote: please do make a issue for this in jira Here it is: https://issues.apache.org/jira/browse/WICKET-254 - 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] ui framework choice
I also had hair-pulling moments at first trying to understand static vs. dynamic models. It was one of my principal motivations for re-writing the wiki page. Scott Swank wrote: Read it? I have it printed off sitting on my desk. The key point I was missing was that a static model for, lets say, a label holds the value in question. For Ajax refreshes a dynamic model, such as a PropertyModel, knows how to get the value and hence updates the label's contents on refresh. For no good reason I just wasn't getting that right out of the gate. Cheers, Scott On 2/1/07, Jonathan Locke [EMAIL PROTECTED] wrote: Models are actually simpler than they look. If you haven't already read it, this is a good primer: http://cwiki.apache.org/WICKET/working-with-wicket-models.html Scott Swank wrote: Thank you to both of you. And for anyone who's been paying any attention to my questions it's pretty clear that I don't know Wicket particularly well yet. I'm still fumbling around a bit with models. Further, the other three folk had never set eyes on Wicket before last Monday. Scott - 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/-Wicket-user--ui-framework-choice-tf3137969.html#a8753476 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 -- Scott Swank reformed mathematician - 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 -- View this message in context: http://www.nabble.com/-Wicket-user--ui-framework-choice-tf3137969.html#a8812385 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
Re: [Wicket-user] ui framework choice
On Thu, 01 Feb 2007, Scott Swank wrote: And we just got WicketTester up running. Very nice stuff. Its I checked yesterday and our .ui package had a line coverage of 96 % or something such, slightly more than the overall for the whole software :) capabilities are already impressing folk. Are there any known things to be aware of with respect to Ajax-ified apps WicketTester? I was able to test some ajax functionality by firing events with WicketTester, but something related to forms not. The problematic form thing I just tested with Wicket Bench then. If anyone is interested I can cook up a quickstart representing the WicketTester-with-ajaxified-form problem. -- 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] ui framework choice
I was able to test some ajax functionality by firing events with WicketTester, but something related to forms not. The problematic form thing I just tested with Wicket Bench then. If anyone is interested I can cook up a quickstart representing the WicketTester-with-ajaxified-form problem. please do make a issue for this in jira johan - 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] ui framework choice
Very interesting to hear. Thank you. On 1/31/07, beboris [EMAIL PROTECTED] wrote: We have done some performance testing between JSF, JSP, Wicket and Stripes when choosing a framework to develop Ajax-enabled WebUI. You may find it interesting to know that our results showed JSF is at least 3-4 times slower than JSP on simple pages (exactly as described at http://www.mail-archive.com/users@myfaces.apache.org/msg24571.html), while wicket's performance is on par with JSP for the same pages... Actually, those performance testing results was the main reason why we have chosen Wicket over JSF despite the fact the cumulative team experience with JSF in terms of projects made and time spent was significantly greater than with Wicket (the latter being around zero...) Eelco Hillenius wrote: That would be interesting yeah. I'm not sure if there would be a clear winner. Eelco On 1/29/07, Christopher Gardner [EMAIL PROTECTED] wrote: I apologize if this has been mentioned, but is comparative performance and load testing planned? I'd love to see Wicket rule on this. On 1/29/07, Scott Swank [EMAIL PROTECTED] wrote: One week (of two) into the JSF vs. Wicket comparison here at Vegas.com things are going nicely -- team Wicket is finished while team JSF is trying to get Ajax functionality working. There were four people working on each implementation, but JSF is so far behind that an additional person was added to the JSF team and one of the Wicket folk was moved from Wicket to JSF -- i.e. three folk working on Wicket and 6 on JSF in an effort to catch up. The three of us remaining are working on: * overriding components' css -- i.e. a custom look/feel for ModalWindow * unit test integration * cleaner use of dynamic models Cheers, Scott -- 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 - 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/-Wicket-user--ui-framework-choice-tf3137969.html#a8743585 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 -- Scott Swank reformed mathematician - 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] ui framework choice
If our JSF v. Wicket shakedown continues to clearly favor Wicket then I imagine you'll see some from our corner of the web. Scott On 1/31/07, Igor Vaynberg [EMAIL PROTECTED] wrote: and what we expect from our users are patches :) -igor On 1/31/07, Carfield Yim [EMAIL PROTECTED] wrote: On 2/1/07, Igor Vaynberg [EMAIL PROTECTED] wrote: you are free to write your own if the one we provide doesnt fit your needs :) we didnt use any api you dont have access to to create this one. Sure, no offence, in fact I am happy to use ModalWindow. I just say what we expect for our software some time is a lot difference from what user expected - 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 -- Scott Swank reformed mathematician - 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] ui framework choice
And we just got WicketTester up running. Very nice stuff. Its capabilities are already impressing folk. Are there any known things to be aware of with respect to Ajax-ified apps WicketTester? Continually impressed, Scott On 2/1/07, Scott Swank [EMAIL PROTECTED] wrote: If our JSF v. Wicket shakedown continues to clearly favor Wicket then I imagine you'll see some from our corner of the web. Scott On 1/31/07, Igor Vaynberg [EMAIL PROTECTED] wrote: and what we expect from our users are patches :) -igor On 1/31/07, Carfield Yim [EMAIL PROTECTED] wrote: On 2/1/07, Igor Vaynberg [EMAIL PROTECTED] wrote: you are free to write your own if the one we provide doesnt fit your needs :) we didnt use any api you dont have access to to create this one. Sure, no offence, in fact I am happy to use ModalWindow. I just say what we expect for our software some time is a lot difference from what user expected - 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 -- Scott Swank reformed mathematician -- Scott Swank reformed mathematician - 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] ui framework choice
Models are actually simpler than they look. If you haven't already read it, this is a good primer: http://cwiki.apache.org/WICKET/working-with-wicket-models.html Scott Swank wrote: Thank you to both of you. And for anyone who's been paying any attention to my questions it's pretty clear that I don't know Wicket particularly well yet. I'm still fumbling around a bit with models. Further, the other three folk had never set eyes on Wicket before last Monday. Scott - 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/-Wicket-user--ui-framework-choice-tf3137969.html#a8753476 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
Re: [Wicket-user] ui framework choice
Read it? I have it printed off sitting on my desk. The key point I was missing was that a static model for, lets say, a label holds the value in question. For Ajax refreshes a dynamic model, such as a PropertyModel, knows how to get the value and hence updates the label's contents on refresh. For no good reason I just wasn't getting that right out of the gate. Cheers, Scott On 2/1/07, Jonathan Locke [EMAIL PROTECTED] wrote: Models are actually simpler than they look. If you haven't already read it, this is a good primer: http://cwiki.apache.org/WICKET/working-with-wicket-models.html Scott Swank wrote: Thank you to both of you. And for anyone who's been paying any attention to my questions it's pretty clear that I don't know Wicket particularly well yet. I'm still fumbling around a bit with models. Further, the other three folk had never set eyes on Wicket before last Monday. Scott - 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/-Wicket-user--ui-framework-choice-tf3137969.html#a8753476 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 -- Scott Swank reformed mathematician - 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] ui framework choice
Heh, models take a while to grok. I guess most people have the same problem at the beginning (I was no exception :)) -Matej Scott Swank wrote: Read it? I have it printed off sitting on my desk. The key point I was missing was that a static model for, lets say, a label holds the value in question. For Ajax refreshes a dynamic model, such as a PropertyModel, knows how to get the value and hence updates the label's contents on refresh. For no good reason I just wasn't getting that right out of the gate. Cheers, Scott On 2/1/07, *Jonathan Locke* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Models are actually simpler than they look. If you haven't already read it, this is a good primer: http://cwiki.apache.org/WICKET/working-with-wicket-models.html Scott Swank wrote: Thank you to both of you. And for anyone who's been paying any attention to my questions it's pretty clear that I don't know Wicket particularly well yet. I'm still fumbling around a bit with models. Further, the other three folk had never set eyes on Wicket before last Monday. Scott - 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 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- View this message in context: http://www.nabble.com/-Wicket-user--ui-framework-choice-tf3137969.html#a8753476 http://www.nabble.com/-Wicket-user--ui-framework-choice-tf3137969.html#a8753476 Sent from the Wicket - User mailing list archive at Nabble.com http://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 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Scott Swank reformed mathematician - 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] ui framework choice
Matej! Even you!? I can't believe that! you are making fun of me! johan On 2/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Heh, models take a while to grok. I guess most people have the same problem at the beginning (I was no exception :)) -Matej Scott Swank wrote: Read it? I have it printed off sitting on my desk. The key point I was missing was that a static model for, lets say, a label holds the value in question. For Ajax refreshes a dynamic model, such as a PropertyModel, knows how to get the value and hence updates the label's contents on refresh. For no good reason I just wasn't getting that right out of the gate. Cheers, Scott On 2/1/07, *Jonathan Locke* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Models are actually simpler than they look. If you haven't already read it, this is a good primer: http://cwiki.apache.org/WICKET/working-with-wicket-models.html Scott Swank wrote: Thank you to both of you. And for anyone who's been paying any attention to my questions it's pretty clear that I don't know Wicket particularly well yet. I'm still fumbling around a bit with models. Further, the other three folk had never set eyes on Wicket before last Monday. Scott - 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 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- View this message in context: http://www.nabble.com/-Wicket-user--ui-framework-choice-tf3137969.html#a8753476 http://www.nabble.com/-Wicket-user--ui-framework-choice-tf3137969.html#a8753476 Sent from the Wicket - User mailing list archive at Nabble.com http://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 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Scott Swank reformed mathematician - 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 - 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] ui framework choice
Yeah, well, it took me some time to realize the potential of wicket models :) I believe the way wicket models are is both blessing and curse. The model interface is very simple and flexible, but on the other hand, the possibilities (like nested and compound models) are not entirely obvious. -Matej Johan Compagner wrote: Matej! Even you!? I can't believe that! you are making fun of me! johan On 2/1/07, *Matej Knopp* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Heh, models take a while to grok. I guess most people have the same problem at the beginning (I was no exception :)) -Matej Scott Swank wrote: Read it? I have it printed off sitting on my desk. The key point I was missing was that a static model for, lets say, a label holds the value in question. For Ajax refreshes a dynamic model, such as a PropertyModel, knows how to get the value and hence updates the label's contents on refresh. For no good reason I just wasn't getting that right out of the gate. Cheers, Scott On 2/1/07, *Jonathan Locke* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Models are actually simpler than they look. If you haven't already read it, this is a good primer: http://cwiki.apache.org/WICKET/working-with-wicket-models.html Scott Swank wrote: Thank you to both of you. And for anyone who's been paying any attention to my questions it's pretty clear that I don't know Wicket particularly well yet. I'm still fumbling around a bit with models. Further, the other three folk had never set eyes on Wicket before last Monday. Scott - 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 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net mailto: Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- View this message in context: http://www.nabble.com/-Wicket-user--ui-framework-choice-tf3137969.html#a8753476 http://www.nabble.com/-Wicket-user--ui-framework-choice-tf3137969.html#a8753476 http://www.nabble.com/-Wicket-user--ui-framework-choice-tf3137969.html#a8753476 Sent from the Wicket - User mailing list archive at Nabble.com http://Nabble.com http://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 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Scott Swank reformed mathematician - Using
Re: [Wicket-user] ui framework choice
The wiki needs more examples that use a particular model in one or two situations and then explain why that model is a good fit for the situation at hand. Once I feel like I have a bit more solid grasp I'll volunteer my time to such an effort. Matej -- By nested do you mean what is referred to as chaining models in the wiki? Scott On 2/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Yeah, well, it took me some time to realize the potential of wicket models :) I believe the way wicket models are is both blessing and curse. The model interface is very simple and flexible, but on the other hand, the possibilities (like nested and compound models) are not entirely obvious. -Matej - 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] ui framework choice
Mmm, here's the rather frustrated response from the developer who's been
working on re-skinning DatePicker ModalWindow to get them to more
seamlessly fit our UI look/feel. Apart from this hitch the demo
implementation has been proceeded so well that we're trying to figure out
what else to do to take up the rest of the week -- so things really are
coming along rather well. I'm open to any/all advice on how best to give
our html/css team reasonably straight-forward access to the look/feel of
components that come packages with their own css.
Many thanks again,
Scott
--
Team,
Here is my findings and final thoughts on Wicket and CSS for components.
Please let me know if you really want me to get the CSS changed on a
component. I can do just that, but the path to get there isn't entirely
easy. Here are my thoughts:
Firstly, to answer Scotts question How easy would it be to just sub-class
ModalWindow to one that has our css attached?. The answer is not that
easy. We can subclass sure, but telling wicket to use our own CSS with a
member function call would require changing the code that implements that
component. The components I have seen have a function called setStyle().
The problem is that style assumes you are setting one of its predefined
styles that exist in the package directory.
By convention components have their CSS at the class level (inside the
package) . Worse than that, some times the CSS (or in the case of the
DatePicker) reference a handful of other content like images in the same
class package. In that case you would have to move every referenced piece
of content relative to where you made your changes.
Here are the following ways that make it possible to override Wicket
components CSS:
*1)* Change the source for the desired component(s) to allow better
flexibility in choosing external CSS.
*2)* Override the CSS by either of the following 2 ways:
*a)* Insert a wicket-head tag on the page and override CSS attributes
on the desired component page. To find out what the CSS looks like, you
still have to unzip the wicket JAR or wicket-extensions JAR to get to the
CSS:
wicket:head
style type=text/cssdiv.calendar {position: absolute;z-index:
10;top:150;left:100;}/style
/wicket:head
*b)* Do what I did for the DatePicker, and force the component to add a
new Header to the page (overriding its original components CSS). I was able
to put the CSS in our content directory which in practive gives a designer
the ability to change any CSS properties at will without redeploying our
app:
*add(HeaderContributor.forCss(../../css/cyllenius_cal.css));*
**
Note: In any case we are going to want designers to be able to access CSS
files without digging into a Java package structure.
*The ModalWindow Problems with styes*
**
I started looking into modifying the ModalWindows CSS just to show we have
control over the component. In order to change its behavior, we would have
to modify Javascript. In order to change its look we need to modify a
tightly coupled component to its CSS.
What has made this a mess is that the ModalWindow has 2 choices, grey and
blue based CSS. By default it uses the blue css (blue borders, etc). In
order for me to override any of the CSS attributes, such as if i want to
have no blue borders and simple black lines, I need to apply choice 1 or 2
above. If we don't modify the source code, we would have to give the
designer the CSS and they would be required to override CSS classes called
div.wicket-modal div.w_blue in order to change to new properties. Just
looks ugly to change a property with the word blue in it, but its not blue
now its black.
Another silly issue that demonstrates the coupling of a component to its CSS
is that the modal window uses CSS's background-image in for its blue/grey
border. We can only override the image not remove it so that we simply have
a black line. Bottom line is that the relationship of the CSS and the
component is pure infatuation. That intense desire needs to be broken up in
order to achieve the true love that is often seen with the concept of
Windows application - its called Skinning.
*Summary*
Wicket's component nature introduces the tight relationship with to CSS and
silly convention of housing the CSS in the packages themselves. After this
exercise I am convinced component UI frameworks (at least Wicket) fall short
in allow the developer to skin or change the look of a component with
ease. It is obvious these components are written with the thought that that
their look is your desired look. Until this problem can be solved, I
believe this is a major weakness of the component framework.
chris
-
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
Re: [Wicket-user] ui framework choice
Ok, I dug into the DatePickerSettings and figured out that we can very
easily:
1. Apply our own css that overrides part of the existing css like so:
this.add(HeaderContributor.forCss(../../css/cyllenius_cal.css));
2. Apply our own css _instead of_ the existing css like so:
settings.setStyle(new ResourceReference(DatePickerSettings.class,
css/cyllenius_cal.css));
I'm still researching ModalWindow...
Cheers,
Scott
On 1/31/07, Scott Swank [EMAIL PROTECTED] wrote:
Mmm, here's the rather frustrated response from the developer who's been
working on re-skinning DatePicker ModalWindow to get them to more
seamlessly fit our UI look/feel. Apart from this hitch the demo
implementation has been proceeded so well that we're trying to figure out
what else to do to take up the rest of the week -- so things really are
coming along rather well. I'm open to any/all advice on how best to give
our html/css team reasonably straight-forward access to the look/feel of
components that come packages with their own css.
Many thanks again,
Scott
--
Team,
Here is my findings and final thoughts on Wicket and CSS for components.
Please let me know if you really want me to get the CSS changed on a
component. I can do just that, but the path to get there isn't entirely
easy. Here are my thoughts:
Firstly, to answer Scotts question How easy would it be to just sub-class
ModalWindow to one that has our css attached?. The answer is not that
easy. We can subclass sure, but telling wicket to use our own CSS with a
member function call would require changing the code that implements that
component. The components I have seen have a function called setStyle().
The problem is that style assumes you are setting one of its predefined
styles that exist in the package directory.
By convention components have their CSS at the class level (inside the
package) . Worse than that, some times the CSS (or in the case of the
DatePicker) reference a handful of other content like images in the same
class package. In that case you would have to move every referenced piece
of content relative to where you made your changes.
Here are the following ways that make it possible to override Wicket
components CSS:
*1)* Change the source for the desired component(s) to allow better
flexibility in choosing external CSS.
*2)* Override the CSS by either of the following 2 ways:
*a)* Insert a wicket-head tag on the page and override CSS
attributes on the desired component page. To find out what the CSS looks
like, you still have to unzip the wicket JAR or wicket-extensions JAR to get
to the CSS:
wicket:head
style type=text/cssdiv.calendar {position: absolute;z-index:
10;top:150;left:100;}/style
/wicket:head
*b)* Do what I did for the DatePicker, and force the component to add
a new Header to the page (overriding its original components CSS). I was
able to put the CSS in our content directory which in practive gives a
designer the ability to change any CSS properties at will without
redeploying our app:
*add(HeaderContributor.forCss(../../css/cyllenius_cal.css));*
**
Note: In any case we are going to want designers to be able to access CSS
files without digging into a Java package structure.
*The ModalWindow Problems with styes*
**
I started looking into modifying the ModalWindows CSS just to show we have
control over the component. In order to change its behavior, we would have
to modify Javascript. In order to change its look we need to modify a
tightly coupled component to its CSS.
What has made this a mess is that the ModalWindow has 2 choices, grey and
blue based CSS. By default it uses the blue css (blue borders, etc). In
order for me to override any of the CSS attributes, such as if i want to
have no blue borders and simple black lines, I need to apply choice 1 or 2
above. If we don't modify the source code, we would have to give the
designer the CSS and they would be required to override CSS classes called
div.wicket-modal div.w_blue in order to change to new properties. Just
looks ugly to change a property with the word blue in it, but its not blue
now its black.
Another silly issue that demonstrates the coupling of a component to its
CSS is that the modal window uses CSS's background-image in for its
blue/grey border. We can only override the image not remove it so that we
simply have a black line. Bottom line is that the relationship of the CSS
and the component is pure infatuation. That intense desire needs to be
broken up in order to achieve the true love that is often seen with the
concept of Windows application - its called Skinning.
*Summary*
Wicket's component nature introduces the tight relationship with to CSS
and silly convention of housing the CSS in the packages themselves. After
this exercise I am convinced component UI frameworks (at least Wicket) fall
short in allow the developer to skin or change the look of a component
Re: [Wicket-user] ui framework choice
Correction. Step #1 is on the DatePicker itself, while step #2 is on the
DatePickerSettings. Dumb cut/paste mistake.
On 1/31/07, Scott Swank [EMAIL PROTECTED] wrote:
Ok, I dug into the DatePickerSettings and figured out that we can very
easily:
1. Apply our own css that overrides part of the existing css like so:
this.add(HeaderContributor.forCss(../../css/cyllenius_cal.css));
2. Apply our own css _instead of_ the existing css like so:
settings.setStyle(new ResourceReference(DatePickerSettings.class,
css/cyllenius_cal.css));
I'm still researching ModalWindow...
Cheers,
Scott
On 1/31/07, Scott Swank [EMAIL PROTECTED] wrote:
Mmm, here's the rather frustrated response from the developer who's been
working on re-skinning DatePicker ModalWindow to get them to more
seamlessly fit our UI look/feel. Apart from this hitch the demo
implementation has been proceeded so well that we're trying to figure out
what else to do to take up the rest of the week -- so things really are
coming along rather well. I'm open to any/all advice on how best to give
our html/css team reasonably straight-forward access to the look/feel of
components that come packages with their own css.
Many thanks again,
Scott
--
Team,
Here is my findings and final thoughts on Wicket and CSS for
components. Please let me know if you really want me to get the CSS changed
on a component. I can do just that, but the path to get there isn't
entirely easy. Here are my thoughts:
Firstly, to answer Scotts question How easy would it be to just
sub-class ModalWindow to one that has our css attached?. The answer is not
that easy. We can subclass sure, but telling wicket to use our own CSS
with a member function call would require changing the code that implements
that component. The components I have seen have a function called
setStyle(). The problem is that style assumes you are setting one of its
predefined styles that exist in the package directory.
By convention components have their CSS at the class level (inside the
package) . Worse than that, some times the CSS (or in the case of the
DatePicker) reference a handful of other content like images in the same
class package. In that case you would have to move every referenced piece
of content relative to where you made your changes.
Here are the following ways that make it possible to override Wicket
components CSS:
*1)* Change the source for the desired component(s) to allow better
flexibility in choosing external CSS.
*2)* Override the CSS by either of the following 2 ways:
*a)* Insert a wicket-head tag on the page and override CSS
attributes on the desired component page. To find out what the CSS looks
like, you still have to unzip the wicket JAR or wicket-extensions JAR to get
to the CSS:
wicket:head
style type=text/cssdiv.calendar {position: absolute;z-index:
10;top:150;left:100;}/style
/wicket:head
*b)* Do what I did for the DatePicker, and force the component to
add a new Header to the page (overriding its original components CSS). I
was able to put the CSS in our content directory which in practive gives a
designer the ability to change any CSS properties at will without
redeploying our app:
*add(HeaderContributor.forCss(../../css/cyllenius_cal.css));*
**
Note: In any case we are going to want designers to be able to access
CSS files without digging into a Java package structure.
*The ModalWindow Problems with styes*
**
I started looking into modifying the ModalWindows CSS just to show we
have control over the component. In order to change its behavior, we would
have to modify Javascript. In order to change its look we need to modify a
tightly coupled component to its CSS.
What has made this a mess is that the ModalWindow has 2 choices, grey
and blue based CSS. By default it uses the blue css (blue borders, etc).
In order for me to override any of the CSS attributes, such as if i want to
have no blue borders and simple black lines, I need to apply choice 1 or 2
above. If we don't modify the source code, we would have to give the
designer the CSS and they would be required to override CSS classes called
div.wicket-modal div.w_blue in order to change to new properties. Just
looks ugly to change a property with the word blue in it, but its not blue
now its black.
Another silly issue that demonstrates the coupling of a component to its
CSS is that the modal window uses CSS's background-image in for its
blue/grey border. We can only override the image not remove it so that we
simply have a black line. Bottom line is that the relationship of the CSS
and the component is pure infatuation. That intense desire needs to be
broken up in order to achieve the true love that is often seen with the
concept of Windows application - its called Skinning.
*Summary*
Wicket's component nature introduces the tight
Re: [Wicket-user] ui framework choice
one thing to keep in mind is that the modalwindow was _not meant_ to be very
customizable. it was meant to be a dropin component that you would use as
is. that is why we put so much work into making it look really good. what we
need to do is to extract an AbstractModalWindow that doesnt have all the
bells and whistles but lets you customize the look more.
also can you not simply do modalwindow.setcssclassname(mine) and then
include an additional stylesheet that looks like one of modal window's but
uses the div.mine as a prefix so it overrides the other styles?
-igor
On 1/31/07, Scott Swank [EMAIL PROTECTED] wrote:
Ok, I dug into the DatePickerSettings and figured out that we can very
easily:
1. Apply our own css that overrides part of the existing css like so:
this.add(HeaderContributor.forCss(../../css/cyllenius_cal.css));
2. Apply our own css _instead of_ the existing css like so:
settings.setStyle(new ResourceReference(DatePickerSettings.class,
css/cyllenius_cal.css));
I'm still researching ModalWindow...
Cheers,
Scott
On 1/31/07, Scott Swank [EMAIL PROTECTED] wrote:
Mmm, here's the rather frustrated response from the developer who's been
working on re-skinning DatePicker ModalWindow to get them to more
seamlessly fit our UI look/feel. Apart from this hitch the demo
implementation has been proceeded so well that we're trying to figure out
what else to do to take up the rest of the week -- so things really are
coming along rather well. I'm open to any/all advice on how best to give
our html/css team reasonably straight-forward access to the look/feel of
components that come packages with their own css.
Many thanks again,
Scott
--
Team,
Here is my findings and final thoughts on Wicket and CSS for
components. Please let me know if you really want me to get the CSS changed
on a component. I can do just that, but the path to get there isn't
entirely easy. Here are my thoughts:
Firstly, to answer Scotts question How easy would it be to just
sub-class ModalWindow to one that has our css attached?. The answer is not
that easy. We can subclass sure, but telling wicket to use our own CSS
with a member function call would require changing the code that implements
that component. The components I have seen have a function called
setStyle(). The problem is that style assumes you are setting one of its
predefined styles that exist in the package directory.
By convention components have their CSS at the class level (inside the
package) . Worse than that, some times the CSS (or in the case of the
DatePicker) reference a handful of other content like images in the same
class package. In that case you would have to move every referenced piece
of content relative to where you made your changes.
Here are the following ways that make it possible to override Wicket
components CSS:
*1)* Change the source for the desired component(s) to allow better
flexibility in choosing external CSS.
*2)* Override the CSS by either of the following 2 ways:
*a)* Insert a wicket-head tag on the page and override CSS
attributes on the desired component page. To find out what the CSS looks
like, you still have to unzip the wicket JAR or wicket-extensions JAR to get
to the CSS:
wicket:head
style type=text/cssdiv.calendar {position: absolute;z-index:
10;top:150;left:100;}/style
/wicket:head
*b)* Do what I did for the DatePicker, and force the component to
add a new Header to the page (overriding its original components CSS). I
was able to put the CSS in our content directory which in practive gives a
designer the ability to change any CSS properties at will without
redeploying our app:
*add(HeaderContributor.forCss(../../css/cyllenius_cal.css));*
**
Note: In any case we are going to want designers to be able to access
CSS files without digging into a Java package structure.
*The ModalWindow Problems with styes*
**
I started looking into modifying the ModalWindows CSS just to show we
have control over the component. In order to change its behavior, we would
have to modify Javascript. In order to change its look we need to modify a
tightly coupled component to its CSS.
What has made this a mess is that the ModalWindow has 2 choices, grey
and blue based CSS. By default it uses the blue css (blue borders, etc).
In order for me to override any of the CSS attributes, such as if i want to
have no blue borders and simple black lines, I need to apply choice 1 or 2
above. If we don't modify the source code, we would have to give the
designer the CSS and they would be required to override CSS classes called
div.wicket-modal div.w_blue in order to change to new properties. Just
looks ugly to change a property with the word blue in it, but its not blue
now its black.
Another silly issue that demonstrates the coupling of a component to its
CSS is that the modal
Re: [Wicket-user] ui framework choice
On 1/31/07, Scott Swank [EMAIL PROTECTED] wrote: Another silly issue that demonstrates the coupling of a component to its CSS is that the modal window uses CSS's background-image in for its blue/grey border. We can only override the image not remove it so that we simply have a black line. if you can override it why do you need to remove it? Bottom line is that the relationship of the CSS and the component is pure infatuation. components and css work together, of course there will be tight coupling. That intense desire needs to be broken up in order to achieve the true love that is often seen with the concept of Windows application - its called Skinning. heh...windows applications consist of a set of predefined components defined by the OS. i have plenty of applications where custom components do not skin properly. they match the colors sure, but they look out of place. we can provide great skinning support if we will stop letting you create your own components. not to mention that html+css is a much more flexible canvas then windows (before WFP), so i dont think you can draw the parallel very well. *Summary* Wicket's component nature introduces the tight relationship with to CSS and silly convention of housing the CSS in the packages themselves. is this really that silly? you had to use a datepicker, what did you have to do? just add a datepicker component. did you have to unzip some zip that housed datepicker related css+images into some folder in your webapp? no. why? because datepicker could get them from the jar so there is no configuration you had to do. of course if you are going to start overriding css yourself then you have to do that, but then you probably have your own images to provide anyways. btw, you dont have to have all your images in the package. nothing is stopping you from adding an absolute link to your css, and that css having absolute links to any image urls. of course if you later wanted to reuse this component in another project you would have to copy over the jar AND any resources you created as opposed to just dropping in the jar. After this exercise I am convinced component UI frameworks (at least Wicket) fall short in allow the developer to skin or change the look of a component with ease. it really depends on how you approach this. my general approach has been to change the css class of the top level component via attribute modifier or something else, and then have my global stylesheet include any css for that component based on that class. take a look at datatable example in wicket-examples. It is obvious these components are written with the thought that that their look is your desired look. with the exception of modal window i would have to disagree. -igor Until this problem can be solved, I believe this is a major weakness of the component framework. chris - 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 - 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] ui framework choice
what we need to do is to extract an AbstractModalWindow that doesnt have all the bells and whistles but lets you customize the look more. +1 -- if we go with Wicket we might even contribute this ourselves also can you not simply do modalwindow.setcssclassname(mine) and then include an additional stylesheet that looks like one of modal window's but uses the div.mine as a prefix so it overrides the other styles? We're doing that, and embedding it in the constructor of a sub-class of ModalWindow. -igor Igor rocks. - 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] ui framework choice
Hi.
I guess someone should write a how to customize modal window article to
wiki :)
You don't have to use blue or grey css. You can specify your own style
selector in modal window (ModalWindow.setCssClassName). If you set it to
e.g. black, you won't even have the background images loaded.
As for adding images through background-image - there really is no other
way. This is the only way you can have repeated image. Plus this was the
only way to reduce number of images loaded (modal window loads only two
images, so that it appears rather quickly).
-Matej
Scott Swank wrote:
Mmm, here's the rather frustrated response from the developer who's been
working on re-skinning DatePicker ModalWindow to get them to more
seamlessly fit our UI look/feel. Apart from this hitch the demo
implementation has been proceeded so well that we're trying to figure
out what else to do to take up the rest of the week -- so things really
are coming along rather well. I'm open to any/all advice on how best to
give our html/css team reasonably straight-forward access to the
look/feel of components that come packages with their own css.
Many thanks again,
Scott
--
Team,
Here is my findings and final thoughts on Wicket and CSS for
components. Please let me know if you really want me to get the CSS
changed on a component. I can do just that, but the path to get there
isn't entirely easy. Here are my thoughts:
Firstly, to answer Scotts question How easy would it be to just
sub-class ModalWindow to one that has our css attached?. The answer is
not that easy. We can subclass sure, but telling wicket to use our own
CSS with a member function call would require changing the code that
implements that component. The components I have seen have a function
called setStyle(). The problem is that style assumes you are setting
one of its predefined styles that exist in the package directory.
By convention components have their CSS at the class level (inside the
package) . Worse than that, some times the CSS (or in the case of the
DatePicker) reference a handful of other content like images in the same
class package. In that case you would have to move every referenced
piece of content relative to where you made your changes.
Here are the following ways that make it possible to override Wicket
components CSS:
*1)* Change the source for the desired component(s) to allow better
flexibility in choosing external CSS.
*2)* Override the CSS by either of the following 2 ways:
*a)* Insert a wicket-head tag on the page and override CSS
attributes on the desired component page. To find out what the CSS
looks like, you still have to unzip the wicket JAR or wicket-extensions
JAR to get to the CSS:
wicket:head
style type=text/cssdiv.calendar {position:
absolute;z-index: 10;top:150;left:100;}/style
/wicket:head
*b)* Do what I did for the DatePicker, and force the component to
add a new Header to the page (overriding its original components CSS).
I was able to put the CSS in our content directory which in practive
gives a designer the ability to change any CSS properties at will
without redeploying our app:
*add(HeaderContributor./forCss/(../../css/cyllenius_cal.css));*
**
Note: In any case we are going to want designers to be able to access
CSS files without digging into a Java package structure.
*The ModalWindow Problems with styes*
**
I started looking into modifying the ModalWindows CSS just to show we
have control over the component. In order to change its behavior, we
would have to modify Javascript. In order to change its look we need to
modify a tightly coupled component to its CSS.
What has made this a mess is that the ModalWindow has 2 choices, grey
and blue based CSS. By default it uses the blue css (blue borders,
etc). In order for me to override any of the CSS attributes, such as if
i want to have no blue borders and simple black lines, I need to apply
choice 1 or 2 above. If we don't modify the source code, we would have
to give the designer the CSS and they would be required to override CSS
classes called div.wicket-modal div.w_blue in order to change to new
properties. Just looks ugly to change a property with the word blue
in it, but its not blue now its black.
Another silly issue that demonstrates the coupling of a component to its
CSS is that the modal window uses CSS's background-image in for its
blue/grey border. We can only override the image not remove it so that
we simply have a black line. Bottom line is that the relationship of
the CSS and the component is pure infatuation. That intense desire
needs to be broken up in order to achieve the true love that is often
seen with the concept of Windows application - its called Skinning.
*Summary*
Wicket's component nature
Re: [Wicket-user] ui framework choice
Eelco Igor,
I'm in agreement on the broad component-packaging approach and had much the
same conversation with our developer (Chris). Mostly he was frustrated.
We're sub-classes both DatePicker ModalWindow so that they have our
look/feel for the prototype. Things really aren't nearly so bad as he made
them out to be, and my phobia of css stopped me from digging into the
particulars before I passed his commentary along. I am suitably chastised.
:)
Scott
On 1/31/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Hi,
By convention components have their CSS at the class level (inside the
package) . Worse than that, some times the CSS (or in the case of the
DatePicker) reference a handful of other content like images in the same
class package. In that case you would have to move every referenced
piece
of content relative to where you made your changes.
Wicket's component nature introduces the tight relationship with to CSS
and silly convention of housing the CSS in the packages themselves.
After this exercise I am convinced component UI frameworks (at least
Wicket)
fall short in allow the developer to skin or change the look of a
component with ease.
It is obvious these components are written with the thought that that
their look is your
desired look. Until this problem can be solved, I believe this is a
major weakness
of the component framework.
The main reason for Wicket to put markup and resources in packages
*and* facilitate such use (which is something most frameworks do not
provide) is to enable users to create components that you can put in a
jar and enable your users to use it without them having to worry about
what resources they need to put in the web app dir.
I am surprised this ability of writing encapsulated components is
marked as a major weakness; it is quite the opposite if you ask me.
I'm also surprised that the fact that a couple of existing components
depend heavily on packaged resources is taken as a framework weakness.
It is *very easy* to write your own date picker component if you don't
care about the encapsulation. Just get your favorite javascript
widget, wrap a Wicket component around it so that you'd have the
proper header contribution (HeaderContributor#forJavaScript/
HeaderContributor#forCss with the single string argument) and
initialization of the specific widget (e.g. by doing another header
contribution of a little script that initializes the widget using the
component (markup) id). My estimate is that doing this is less than an
hour work! If you follow the user/ dev lists, you can see that we keep
repeating that one of Wicket's major features is the ability to create
custom components easily yourself. This saves us from having to write
kitchen sink components, and others from going through the frustration
that a certain component doesn't do what they want.
It is obvious these components are written with the thought that that
their look is your
desired look
Huh? DatePicker packages all the skins that the original javascript
component packages, and creating your own style for this is as easy as
creating your own folder (and subfolders if you want) with css and
images etc and then doing something like:
public class MyPicker extends DatePicker {
private static class Settings extends DatePickerSettings {
public DatePickerSettings() {
setStyle(new ResourceReference(MyPicker.class,
mystyle.css));
}
}
public MyPicker(String id, Component target) {
super(id, target, new Settings());
}
and you're done! The only thing DatePicker isn't flexible in, is that
it is not written with the idea in mind that people want it to use
resources from a web app dir (and thus break encapsulation). There's
nothing wrong with doing that for your own project (in fact the
project I'm working on has many of such components), but like I
stated, writing such a component yourself would be so easy it would be
better letting people do it themselves so that they have exactly what
they need.
I think we have some work to do getting this message across louder, so
I opened up http://issues.apache.org/jira/browse/WICKET-249
Cheers,
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
--
Scott Swank
reformed mathematician
-
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
Re: [Wicket-user] ui framework choice
That someone may well be me -- once I have a better idea about how the
moving pieces (js css) fit together.
On 1/31/07, Matej Knopp [EMAIL PROTECTED] wrote:
Hi.
I guess someone should write a how to customize modal window article to
wiki :)
You don't have to use blue or grey css. You can specify your own style
selector in modal window (ModalWindow.setCssClassName). If you set it to
e.g. black, you won't even have the background images loaded.
As for adding images through background-image - there really is no other
way. This is the only way you can have repeated image. Plus this was the
only way to reduce number of images loaded (modal window loads only two
images, so that it appears rather quickly).
-Matej
Scott Swank wrote:
Mmm, here's the rather frustrated response from the developer who's been
working on re-skinning DatePicker ModalWindow to get them to more
seamlessly fit our UI look/feel. Apart from this hitch the demo
implementation has been proceeded so well that we're trying to figure
out what else to do to take up the rest of the week -- so things really
are coming along rather well. I'm open to any/all advice on how best to
give our html/css team reasonably straight-forward access to the
look/feel of components that come packages with their own css.
Many thanks again,
Scott
--
Team,
Here is my findings and final thoughts on Wicket and CSS for
components. Please let me know if you really want me to get the CSS
changed on a component. I can do just that, but the path to get there
isn't entirely easy. Here are my thoughts:
Firstly, to answer Scotts question How easy would it be to just
sub-class ModalWindow to one that has our css attached?. The answer is
not that easy. We can subclass sure, but telling wicket to use our own
CSS with a member function call would require changing the code that
implements that component. The components I have seen have a function
called setStyle(). The problem is that style assumes you are setting
one of its predefined styles that exist in the package directory.
By convention components have their CSS at the class level (inside the
package) . Worse than that, some times the CSS (or in the case of the
DatePicker) reference a handful of other content like images in the same
class package. In that case you would have to move every referenced
piece of content relative to where you made your changes.
Here are the following ways that make it possible to override Wicket
components CSS:
*1)* Change the source for the desired component(s) to allow better
flexibility in choosing external CSS.
*2)* Override the CSS by either of the following 2 ways:
*a)* Insert a wicket-head tag on the page and override CSS
attributes on the desired component page. To find out what the CSS
looks like, you still have to unzip the wicket JAR or wicket-extensions
JAR to get to the CSS:
wicket:head
style type=text/cssdiv.calendar {position:
absolute;z-index: 10;top:150;left:100;}/style
/wicket:head
*b)* Do what I did for the DatePicker, and force the component to
add a new Header to the page (overriding its original components CSS).
I was able to put the CSS in our content directory which in practive
gives a designer the ability to change any CSS properties at will
without redeploying our app:
*add(HeaderContributor./forCss/(../../css/cyllenius_cal.css));*
**
Note: In any case we are going to want designers to be able to access
CSS files without digging into a Java package structure.
*The ModalWindow Problems with styes*
**
I started looking into modifying the ModalWindows CSS just to show we
have control over the component. In order to change its behavior, we
would have to modify Javascript. In order to change its look we need to
modify a tightly coupled component to its CSS.
What has made this a mess is that the ModalWindow has 2 choices, grey
and blue based CSS. By default it uses the blue css (blue borders,
etc). In order for me to override any of the CSS attributes, such as if
i want to have no blue borders and simple black lines, I need to apply
choice 1 or 2 above. If we don't modify the source code, we would have
to give the designer the CSS and they would be required to override CSS
classes called div.wicket-modal div.w_blue in order to change to new
properties. Just looks ugly to change a property with the word blue
in it, but its not blue now its black.
Another silly issue that demonstrates the coupling of a component to its
CSS is that the modal window uses CSS's background-image in for its
blue/grey border. We can only override the image not remove it so that
we simply have a black line. Bottom line is that the relationship of
the CSS and the component is pure infatuation. That intense desire
needs to be broken up in order to achieve the true love that is often
seen with the concept of Windows
Re: [Wicket-user] ui framework choice
take a look at datatable example in wicket-examples. Nice example, thank you. - 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] ui framework choice
On 2/1/07, Igor Vaynberg [EMAIL PROTECTED] wrote: one thing to keep in mind is that the modalwindow was _not meant_ to be very customizable. it was meant to be a dropin component that you would use as However, people like every component to be very customizable, that is what client expect from our software :-/ - 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] ui framework choice
you are free to write your own if the one we provide doesnt fit your needs :) we didnt use any api you dont have access to to create this one. -igor On 1/31/07, Carfield Yim [EMAIL PROTECTED] wrote: On 2/1/07, Igor Vaynberg [EMAIL PROTECTED] wrote: one thing to keep in mind is that the modalwindow was _not meant_ to be very customizable. it was meant to be a dropin component that you would use as However, people like every component to be very customizable, that is what client expect from our software :-/ - 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] ui framework choice
On 2/1/07, Igor Vaynberg [EMAIL PROTECTED] wrote: you are free to write your own if the one we provide doesnt fit your needs :) we didnt use any api you dont have access to to create this one. Sure, no offence, in fact I am happy to use ModalWindow. I just say what we expect for our software some time is a lot difference from what user expected - 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] ui framework choice
and what we expect from our users are patches :) -igor On 1/31/07, Carfield Yim [EMAIL PROTECTED] wrote: On 2/1/07, Igor Vaynberg [EMAIL PROTECTED] wrote: you are free to write your own if the one we provide doesnt fit your needs :) we didnt use any api you dont have access to to create this one. Sure, no offence, in fact I am happy to use ModalWindow. I just say what we expect for our software some time is a lot difference from what user expected - 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] ui framework choice
We have done some performance testing between JSF, JSP, Wicket and Stripes when choosing a framework to develop Ajax-enabled WebUI. You may find it interesting to know that our results showed JSF is at least 3-4 times slower than JSP on simple pages (exactly as described at http://www.mail-archive.com/users@myfaces.apache.org/msg24571.html), while wicket's performance is on par with JSP for the same pages... Actually, those performance testing results was the main reason why we have chosen Wicket over JSF despite the fact the cumulative team experience with JSF in terms of projects made and time spent was significantly greater than with Wicket (the latter being around zero...) Eelco Hillenius wrote: That would be interesting yeah. I'm not sure if there would be a clear winner. Eelco On 1/29/07, Christopher Gardner [EMAIL PROTECTED] wrote: I apologize if this has been mentioned, but is comparative performance and load testing planned? I'd love to see Wicket rule on this. On 1/29/07, Scott Swank [EMAIL PROTECTED] wrote: One week (of two) into the JSF vs. Wicket comparison here at Vegas.com things are going nicely -- team Wicket is finished while team JSF is trying to get Ajax functionality working. There were four people working on each implementation, but JSF is so far behind that an additional person was added to the JSF team and one of the Wicket folk was moved from Wicket to JSF -- i.e. three folk working on Wicket and 6 on JSF in an effort to catch up. The three of us remaining are working on: * overriding components' css -- i.e. a custom look/feel for ModalWindow * unit test integration * cleaner use of dynamic models Cheers, Scott -- 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 - 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/-Wicket-user--ui-framework-choice-tf3137969.html#a8743585 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
Re: [Wicket-user] ui framework choice
Scott Swank wrote: The stylesheet is not very simple though. -- Yup, that's that stage we're at. :) It's much easier to change modal window markup by overriding javascript function Wicket.Window.getMarkup. -- Andrew Klochkov - 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] ui framework choice
Very kind, thank you. On 1/29/07, Jonathan Locke [EMAIL PROTECTED] wrote: Sounds very smart. I firmly believe that Wicket can peform and scale as well as being productive and maintainable. Let me know if you run into a need for consulting help in this arena (or any other). Scott Swank wrote: Right now we're focused on developer productivity, code-to-weight ratio and code clarity. If this goes over then we'll look at performance. Scott On 1/29/07, Christopher Gardner [EMAIL PROTECTED] wrote: I apologize if this has been mentioned, but is comparative performance and load testing planned? I'd love to see Wicket rule on this. On 1/29/07, Scott Swank [EMAIL PROTECTED] wrote: One week (of two) into the JSF vs. Wicket comparison here at Vegas.comthings are going nicely -- team Wicket is finished while team JSF is trying to get Ajax functionality working. There were four people working on each implementation, but JSF is so far behind that an additional person was added to the JSF team and one of the Wicket folk was moved from Wicket to JSF -- i.e. three folk working on Wicket and 6 on JSF in an effort to catch up. The three of us remaining are working on: * overriding components' css -- i.e. a custom look/feel for ModalWindow * unit test integration * cleaner use of dynamic models Cheers, Scott -- 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 - 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 -- View this message in context: http://www.nabble.com/-Wicket-user--ui-framework-choice-tf3137969.html#a8703686 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 -- 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] ui framework choice
Interesting, I'll dig into that a bit. (Or more accurately, I'll pass this on to the fellow who's actually working on the ModalWindow DatePicker css for our demo). Cheers, Scott On 1/30/07, Andrew Klochkov [EMAIL PROTECTED] wrote: Scott Swank wrote: The stylesheet is not very simple though. -- Yup, that's that stage we're at. :) It's much easier to change modal window markup by overriding javascript function Wicket.Window.getMarkup. -- Andrew Klochkov - 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
[Wicket-user] ui framework choice
One week (of two) into the JSF vs. Wicket comparison here at Vegas.comthings are going nicely -- team Wicket is finished while team JSF is trying to get Ajax functionality working. There were four people working on each implementation, but JSF is so far behind that an additional person was added to the JSF team and one of the Wicket folk was moved from Wicket to JSF -- i.e. three folk working on Wicket and 6 on JSF in an effort to catch up. The three of us remaining are working on: * overriding components' css -- i.e. a custom look/feel for ModalWindow * unit test integration * cleaner use of dynamic models Cheers, Scott -- 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] ui framework choice
I have a grin on my face that stretches from my left ear to my right... Gogogo! Martijn On 1/29/07, Scott Swank [EMAIL PROTECTED] wrote: One week (of two) into the JSF vs. Wicket comparison here at Vegas.com things are going nicely -- team Wicket is finished while team JSF is trying to get Ajax functionality working. There were four people working on each implementation, but JSF is so far behind that an additional person was added to the JSF team and one of the Wicket folk was moved from Wicket to JSF -- i.e. three folk working on Wicket and 6 on JSF in an effort to catch up. The three of us remaining are working on: * overriding components' css -- i.e. a custom look/feel for ModalWindow * unit test integration * cleaner use of dynamic models Cheers, Scott -- 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 -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now! http://wicketframework.org - 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] ui framework choice
Thank you to both of you. And for anyone who's been paying any attention to my questions it's pretty clear that I don't know Wicket particularly well yet. I'm still fumbling around a bit with models. Further, the other three folk had never set eyes on Wicket before last Monday. Scott - 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] ui framework choice
I wish I could help you in person :) Unfortunately I'm not from US. I'm afraid there's not much that can be done about ModalWindow feel, unless you want to mess with the javascript :) As for Look, you can specify custom stylesheet though. Actually, you can set the CSS class modal window would use (using ModalWindow.setCssClassName()) You can have your own style, simple copying and modifying the modal.css file that comes with wicket. The stylesheet is not very simple though. -Matej Scott Swank wrote: One week (of two) into the JSF vs. Wicket comparison here at Vegas.com http://Vegas.com things are going nicely -- team Wicket is finished while team JSF is trying to get Ajax functionality working. There were four people working on each implementation, but JSF is so far behind that an additional person was added to the JSF team and one of the Wicket folk was moved from Wicket to JSF -- i.e. three folk working on Wicket and 6 on JSF in an effort to catch up. The three of us remaining are working on: * overriding components' css -- i.e. a custom look/feel for ModalWindow * unit test integration * cleaner use of dynamic models Cheers, Scott -- 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 - 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] ui framework choice
The stylesheet is not very simple though. -- Yup, that's that stage we're at. :) On 1/29/07, Matej Knopp [EMAIL PROTECTED] wrote: I wish I could help you in person :) Unfortunately I'm not from US. I'm afraid there's not much that can be done about ModalWindow feel, unless you want to mess with the javascript :) As for Look, you can specify custom stylesheet though. Actually, you can set the CSS class modal window would use (using ModalWindow.setCssClassName()) You can have your own style, simple copying and modifying the modal.css file that comes with wicket. The stylesheet is not very simple though. -Matej Scott Swank wrote: One week (of two) into the JSF vs. Wicket comparison here at Vegas.com http://Vegas.com things are going nicely -- team Wicket is finished while team JSF is trying to get Ajax functionality working. There were four people working on each implementation, but JSF is so far behind that an additional person was added to the JSF team and one of the Wicket folk was moved from Wicket to JSF -- i.e. three folk working on Wicket and 6 on JSF in an effort to catch up. The three of us remaining are working on: * overriding components' css -- i.e. a custom look/feel for ModalWindow * unit test integration * cleaner use of dynamic models Cheers, Scott -- 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 - 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] ui framework choice
But none the less, thank you very kindly. On 1/29/07, Scott Swank [EMAIL PROTECTED] wrote: The stylesheet is not very simple though. -- Yup, that's that stage we're at. :) On 1/29/07, Matej Knopp [EMAIL PROTECTED] wrote: I wish I could help you in person :) Unfortunately I'm not from US. I'm afraid there's not much that can be done about ModalWindow feel, unless you want to mess with the javascript :) As for Look, you can specify custom stylesheet though. Actually, you can set the CSS class modal window would use (using ModalWindow.setCssClassName()) You can have your own style, simple copying and modifying the modal.css file that comes with wicket. The stylesheet is not very simple though. -Matej Scott Swank wrote: One week (of two) into the JSF vs. Wicket comparison here at Vegas.com http://Vegas.com things are going nicely -- team Wicket is finished while team JSF is trying to get Ajax functionality working. There were four people working on each implementation, but JSF is so far behind that an additional person was added to the JSF team and one of the Wicket folk was moved from Wicket to JSF -- i.e. three folk working on Wicket and 6 on JSF in an effort to catch up. The three of us remaining are working on: * overriding components' css -- i.e. a custom look/feel for ModalWindow * unit test integration * cleaner use of dynamic models Cheers, Scott -- 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 - 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 -- 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] ui framework choice
whooohooo! On 1/29/07, Scott Swank [EMAIL PROTECTED] wrote: One week (of two) into the JSF vs. Wicket comparison here at Vegas.comthings are going nicely -- team Wicket is finished while team JSF is trying to get Ajax functionality working. There were four people working on each implementation, but JSF is so far behind that an additional person was added to the JSF team and one of the Wicket folk was moved from Wicket to JSF -- i.e. three folk working on Wicket and 6 on JSF in an effort to catch up. The three of us remaining are working on: * overriding components' css -- i.e. a custom look/feel for ModalWindow * unit test integration * cleaner use of dynamic models Cheers, Scott -- 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 - 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] ui framework choice
Yeah gogogo. :) On 1/29/07, Matej Knopp [EMAIL PROTECTED] wrote: As for Look, you can specify custom stylesheet though. Actually, you can set the CSS class modal window would use (using ModalWindow.setCssClassName()) You can have your own style, simple copying and modifying the modal.css file that comes with wicket. The stylesheet is not very simple though. I don't think it's that bad. I provided a new stylesheet (plus images, and I'm not a designer so pretty slow on making images) in about 5-6 hours. And the biggest part was the images. You did a good job IMHO :) 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] ui framework choice
I apologize if this has been mentioned, but is comparative performance and load testing planned? I'd love to see Wicket rule on this. On 1/29/07, Scott Swank [EMAIL PROTECTED] wrote: One week (of two) into the JSF vs. Wicket comparison here at Vegas.comthings are going nicely -- team Wicket is finished while team JSF is trying to get Ajax functionality working. There were four people working on each implementation, but JSF is so far behind that an additional person was added to the JSF team and one of the Wicket folk was moved from Wicket to JSF -- i.e. three folk working on Wicket and 6 on JSF in an effort to catch up. The three of us remaining are working on: * overriding components' css -- i.e. a custom look/feel for ModalWindow * unit test integration * cleaner use of dynamic models Cheers, Scott -- 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 - 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] ui framework choice
That would be interesting yeah. I'm not sure if there would be a clear winner. Eelco On 1/29/07, Christopher Gardner [EMAIL PROTECTED] wrote: I apologize if this has been mentioned, but is comparative performance and load testing planned? I'd love to see Wicket rule on this. On 1/29/07, Scott Swank [EMAIL PROTECTED] wrote: One week (of two) into the JSF vs. Wicket comparison here at Vegas.com things are going nicely -- team Wicket is finished while team JSF is trying to get Ajax functionality working. There were four people working on each implementation, but JSF is so far behind that an additional person was added to the JSF team and one of the Wicket folk was moved from Wicket to JSF -- i.e. three folk working on Wicket and 6 on JSF in an effort to catch up. The three of us remaining are working on: * overriding components' css -- i.e. a custom look/feel for ModalWindow * unit test integration * cleaner use of dynamic models Cheers, Scott -- 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 - 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] ui framework choice
Right now we're focused on developer productivity, code-to-weight ratio and code clarity. If this goes over then we'll look at performance. Scott On 1/29/07, Christopher Gardner [EMAIL PROTECTED] wrote: I apologize if this has been mentioned, but is comparative performance and load testing planned? I'd love to see Wicket rule on this. On 1/29/07, Scott Swank [EMAIL PROTECTED] wrote: One week (of two) into the JSF vs. Wicket comparison here at Vegas.comthings are going nicely -- team Wicket is finished while team JSF is trying to get Ajax functionality working. There were four people working on each implementation, but JSF is so far behind that an additional person was added to the JSF team and one of the Wicket folk was moved from Wicket to JSF -- i.e. three folk working on Wicket and 6 on JSF in an effort to catch up. The three of us remaining are working on: * overriding components' css -- i.e. a custom look/feel for ModalWindow * unit test integration * cleaner use of dynamic models Cheers, Scott -- 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 - 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] ui framework choice
On 1/29/07, Christopher Gardner [EMAIL PROTECTED] wrote: I apologize if this has been mentioned, but is comparative performance and load testing planned? I'd love to see Wicket rule on this. You can read: http://jroller.com/page/JonathanLocke where we posted some basic, non-representative performance tests with wicket 1.3 and Tapestry 4.1. This test doesn't tell absolute answers other than that Wicket's performance doesn't suck. Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now! http://wicketframework.org - 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] ui framework choice
is tapestry performance a good benchmark? :) -igor On 1/29/07, Martijn Dashorst [EMAIL PROTECTED] wrote: On 1/29/07, Christopher Gardner [EMAIL PROTECTED] wrote: I apologize if this has been mentioned, but is comparative performance and load testing planned? I'd love to see Wicket rule on this. You can read: http://jroller.com/page/JonathanLocke where we posted some basic, non-representative performance tests with wicket 1.3 and Tapestry 4.1. This test doesn't tell absolute answers other than that Wicket's performance doesn't suck. Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now! http://wicketframework.org - 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] ui framework choice
On 1/29/07, Igor Vaynberg [EMAIL PROTECTED] wrote: is tapestry performance a good benchmark? :) Wait until we have an example that runs JSF... Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now! http://wicketframework.org - 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] ui framework choice
Sounds very smart. I firmly believe that Wicket can peform and scale as well as being productive and maintainable. Let me know if you run into a need for consulting help in this arena (or any other). Scott Swank wrote: Right now we're focused on developer productivity, code-to-weight ratio and code clarity. If this goes over then we'll look at performance. Scott On 1/29/07, Christopher Gardner [EMAIL PROTECTED] wrote: I apologize if this has been mentioned, but is comparative performance and load testing planned? I'd love to see Wicket rule on this. On 1/29/07, Scott Swank [EMAIL PROTECTED] wrote: One week (of two) into the JSF vs. Wicket comparison here at Vegas.comthings are going nicely -- team Wicket is finished while team JSF is trying to get Ajax functionality working. There were four people working on each implementation, but JSF is so far behind that an additional person was added to the JSF team and one of the Wicket folk was moved from Wicket to JSF -- i.e. three folk working on Wicket and 6 on JSF in an effort to catch up. The three of us remaining are working on: * overriding components' css -- i.e. a custom look/feel for ModalWindow * unit test integration * cleaner use of dynamic models Cheers, Scott -- 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 - 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 -- View this message in context: http://www.nabble.com/-Wicket-user--ui-framework-choice-tf3137969.html#a8703686 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
