Re: Modal window - chagne width and height
Hi, actually there is now JS function resizeTo :-( V. 2009/1/4 Sébastien Piller > Hi, > > I doubt such a feature is implemented in the wicket code > > most likely, you will need to call the javascript function > "window.resizeTo" yourself, with an AjaxBehavior (ie > AjaxAbstractDefaultBehavior#respond and AjaxRequestTarget#appendJavascript) > > > > Vitek Tajzich wrote: > >> Hi, >> >> >> Is it possible to resize Modal Window by ajax? >> >> >> I need for some reason to resize currently opened window. I've been >> looking >> on google and mailing list and I didn't found anything usable. I also >> looked >> into javascript for modal window and I think It should be possible.. >> >> >> Thanks.. >> >> >> V. >> >> >> >> > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: What is your experience on the time of development ?
Well, funny you should mention this... I had a thought a few weeks ago about starting a blog to show how I have been doing TDD with Wicket. It seems like it is quite easy to do, but there were not many posts discussing ways do do some testing or examples of testing things ajax components etc I have a couple of posts, just getting some of the basics set up... http://empty-your-cup.blogspot.com/ Hopefully I can get some time to demonstrate some simple page and component tests soon. Page testing can be fairly easy because you can just use the WicketTester to start the page. Testing a component can be a bit trickier sometimes because you need to use something like the TestPageSource. Tests generally cover behaviour, for example "if I press this button a panel X should be shown", "The name text field should contain the name of the user", "Changing the first name updates the name in the model", "Errors should have a CSS class of 'error' added". All of these things are quite straight forward to test. We rely on some components working correctly eg that the TextField will generate a valid html textfield, so we shouldn't have to test that. We can test the behaviour of ajax calls - as long as the behaviour is something simple like the component should be updated/hidden/shown by checking it is in the ajax response. The unit tests won't check that the CSS class 'error' shows the text in red with twinkling lights, but that isn't a behaviour. So we still have perhaps some manual testing, in various browsers, to make sure it looks ok. If someone changes some java code which stops a component displaying our unit tests should be able to fail and show us the cause. If someone changes the CSS and makes errors appear green... well, hopefully someone will notice that quickly. I hope that gives you a hint. Stay tuned for more in the blog... today was my first day back at work in the new year so it might have to wait a short time! ZedroS wrote: Jason Lea wrote: We decided to do Test Driven Development because we could use the WicketTester to help in development of our pages/components. Hum, very interesting : the wicket testers classes are really functional and efficient. I didn't look deep into them, considering (wrongly apparently) that even if the tests would pass I couldn't be sure that the page would be rendered fine. What's your feedback on this point ? Furthermore, is it easy as well to test only components ? Or do you have to do "unit component tests" ? To sum up my mail, I would love to have more insight of Wicket and TDD... :$ Thanks in advance ;) cheers zedros -- Jason Lea
Re: What is your experience on the time of development ?
Hi Curtis You cant really compare wicket against Grails, Wicket is not a full stack framework (Wicket is only a webframework).. And actually Grails can run with wicket too[1]... Or are you saying that dynamic languages are better than type safety? Not that I want to start a religious war though, im not that well wandered in neither Grails, Rails etc to know whats better or not.. I guess what you are saying are that the Spring plus hibernate combo could be better..? There are a lot of alternatives to that combo.. Or is it that Grails has better templating support? Anyhow what I am seeing are that Wicket are always the least of my troubles, it's always something else and usually it's not Spring either so that only leaves the ORM as trouble maker, or is it the programmet :) On larger projects you kind of develop your own framework (with Wicket+.*) for the business logic and when you get there speed really picks up. [1]=http://grails.org/Wicket+Plugin Curtis Cooley wrote: Martin Sachs wrote: I'm looking for a little comparison of the development-time for Applications in Wicket against other Technologies. I think the development with Wicket is two times faster than Struts. But what are your experiences on JSF, Rails/Grails, SpringMVC/SpringWebFlow. Anyone you know the development-time from experience ? (P.S.: The applications must use AJAX and many custom components or tags in JSP, not just a hello world sample) I built a small database driven application in about 4 days using Grails then my boss freaked about using a "4GL" and made me rewrite it in Wicket. That took me about 3 weeks. Now, I started at 0 with both frameworks and used Wicket+Spring+Hibernate which I got Spring and Hibernate wiring for free with Grails. My Spring and Hibernate experience was 0, so grails really pulled through in that area. I also have experience with Ruby and Rails which helped with the Grails work, but I'd also built a few (4-5) Wicket pages for another app, so I think that about balances starting points. My really rough guess is that I'd be 50 to 75 percent more effective in Grails than Wicket now that I know what I learned during the three weeks of Wicket work. If I had my druthers, I'd build our app using Grails. I much prefer Groovy/Ruby to Java, and I've been writing Java since 1.1! Confidential/Privileged information may be contained in this email. If you are not the intended recipient, please do not copy, distribute or use it for any purpose, nor disclose its contents to any other person. Please notify the sender immediately if you receive this in error. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Modal window - chagne width and height
Hi, I doubt such a feature is implemented in the wicket code most likely, you will need to call the javascript function "window.resizeTo" yourself, with an AjaxBehavior (ie AjaxAbstractDefaultBehavior#respond and AjaxRequestTarget#appendJavascript) Vitek Tajzich wrote: Hi, Is it possible to resize Modal Window by ajax? I need for some reason to resize currently opened window. I've been looking on google and mailing list and I didn't found anything usable. I also looked into javascript for modal window and I think It should be possible.. Thanks.. V. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Modal window - chagne width and height
Hi, Is it possible to resize Modal Window by ajax? I need for some reason to resize currently opened window. I've been looking on google and mailing list and I didn't found anything usable. I also looked into javascript for modal window and I think It should be possible.. Thanks.. V.
Re: What is your experience on the time of development ?
Jason Lea wrote: > We decided to do Test Driven Development because > we could use the WicketTester to help in development of our > pages/components. > Hum, very interesting : the wicket testers classes are really functional and efficient. I didn't look deep into them, considering (wrongly apparently) that even if the tests would pass I couldn't be sure that the page would be rendered fine. What's your feedback on this point ? Furthermore, is it easy as well to test only components ? Or do you have to do "unit component tests" ? To sum up my mail, I would love to have more insight of Wicket and TDD... :$ Thanks in advance ;) cheers zedros -- View this message in context: http://www.nabble.com/What-is-your-experience-on-the-time-of-development---tp20971605p21280942.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Twenty Six Wicket Tricks
Jonathan Locke wrote: > > yeah. good one. > oh oh... so I'll have to buy this book ;) lol bye zedros -- View this message in context: http://www.nabble.com/Twenty-Six-Wicket-Tricks-tp21214357p21280822.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: What is your experience on the time of development ?
This is a very interesting and surprising post in this forum. Do you have further explanation about your superior productivity using Grails? Is this due to the kind of applications you developp or to special tools that comes with this framework? Is the key stone groovy? Thanks for your enlighments! Curtis Cooley-2 wrote: > > Martin Sachs wrote: >>> I'm looking for a little comparison of the development-time for >>> Applications in Wicket against other Technologies. >>> >>> I think the development with Wicket is two times faster than Struts. But >>> what are your experiences on JSF, Rails/Grails, SpringMVC/SpringWebFlow. >>> >>> Anyone you know the development-time from experience ? >>> >>> >>> (P.S.: The applications must use AJAX and many custom components or tags >>> in JSP, not just a hello world sample) >>> >>> > I built a small database driven application in about 4 days using Grails > then my boss freaked about using a "4GL" and made me rewrite it in > Wicket. That took me about 3 weeks. > > Now, I started at 0 with both frameworks and used > Wicket+Spring+Hibernate which I got Spring and Hibernate wiring for free > with Grails. My Spring and Hibernate experience was 0, so grails really > pulled through in that area. I also have experience with Ruby and Rails > which helped with the Grails work, but I'd also built a few (4-5) Wicket > pages for another app, so I think that about balances starting points. > > My really rough guess is that I'd be 50 to 75 percent more effective in > Grails than Wicket now that I know what I learned during the three weeks > of Wicket work. > > If I had my druthers, I'd build our app using Grails. I much prefer > Groovy/Ruby to Java, and I've been writing Java since 1.1! > > > > Confidential/Privileged information may be contained in this email. If you > are not the intended recipient, please do not copy, distribute or use it > for any purpose, nor disclose its contents to any other person. Please > notify the sender immediately if you receive this in error. > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > -- View this message in context: http://www.nabble.com/What-is-your-experience-on-the-time-of-development---tp20971605p21280228.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
pb to access to this on event onchange on the AutoCompleteTextField
I would like create a component that extends AjaxEditableLabel with replace TextField with AjaxEditableAutoComplete. And I discovert a problem in the wicket-autocomplete.js when the event onchange is rewriting (line 83) : // WICKET-1280 objonchangeoriginal=obj.onchange; obj.onchange=function(event){ if(mouseactive==1)return false; if(typeof objonchangeoriginal=="function")objonchangeoriginal(); } objonchange=obj.onchange; the problem is that the objonchangeoriginal function can't access to the this object, and it's necessary because I change the onchange event on AjaxEditableAutoComplete in case I extends AjaxEditableLabel with this : editor.add(new EditorAjaxBehavior() { private static final long serialVersionUID = 1L; @Override protected void onComponentTag(ComponentTag tag) { super.onComponentTag(tag); final String saveCall = "{wicketAjaxGet('" + getCallbackUrl() + "&save=true&'+this.name+'='+wicketEncode(this.value)); return true;}"; tag.put("onchange", saveCall); } }); then the best way to solve the problem is to change the invocation of objonchangeoriginal function with that : 84// WICKET-1280 85objonchangeoriginal=obj.onchange; 86obj.onchange=function(event){ 87 if(mouseactive==1)return false; 88 if(typeof objonchangeoriginal=="function")objonchangeoriginal.apply(this, [event]); 89 } 90objonchange=obj.onchange; all invocation of function need to be change this with new invocation on the wicket-autocomplete.js file. -- View this message in context: http://www.nabble.com/pb-to-access-to-this-on-event-onchange-on-the-AutoCompleteTextField-tp21278638p21278638.html Sent from the Wicket - User mailing list archive at Nabble.com.
Re: TabbedPanel customization ?
Use CSS for styling customization. Piotr Jakubowski wrote: > > Hi, > Is it possible to tell TabbedPanel where to put its inner elements and > override the default action? I would like to have the tab content in some > other place than it is usually. And I am thinking whether it is possible > somehow using TabbedPanel or I should write the whole thing from scratch. > -- View this message in context: http://www.nabble.com/TabbedPanel-customization---tp21276126p21278346.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
TabbedPanel customization ?
Hi, Is it possible to tell TabbedPanel where to put its inner elements and override the default action? I would like to have the tab content in some other place than it is usually. And I am thinking whether it is possible somehow using TabbedPanel or I should write the whole thing from scratch. -- View this message in context: http://www.nabble.com/TabbedPanel-customization---tp21276126p21276126.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org