Re: Should Duration be deprecated?
My keyboard on has 2 keys: 0 and 1. Thats all i need when i code :) NM On Wed, Jan 27, 2010 at 10:32 AM, Chris Colman chr...@stepaheadsoftware.com wrote: While we're on the subject of 1's and 0's: Did you know this? There are only 10 types of people in the world: Those who understand binary, and those who don't. Back in my day we didn't need Tapestry, or Wicket or WebObjects, or even Servlets, or for that matter Java! We just coded in plain assembly language. And before that we had to just type in 1's and 0's. Sometimes we didn't even have 1's. I once had to code for an entire month, barefoot, in the dead of winter, using just 0's... but you didn't hear me complaining. Regards, Chris Colman Step Ahead Software http://stepaheadsoftware.com you're thinking of windows. Martijn Dashorst wrote: On Tue, Jan 26, 2010 at 10:00 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i thought they were all stored as electrons My vote goes to Umpalumpa's shifting miniature pumpkins on scales Martijn -- - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: functional testing
Consider using Junit for business layer and Selenium for view layer. I use that,but my project is small. And don't use watir, i had a bad experience with it. NM On Fri, Jan 22, 2010 at 4:20 PM, Marzia Forli marzia.fo...@yahoo.comwrote: Hi to all wicketers, My current assignment is a pretty big web application to build with wicket. Right now I am studying the framework and in my background thread thinking about the possible problems... One of my biggest concerns is a testing, better said functional testing. As many of you are very experienced with wicket and possibly with big web apps, could you give some advices in this area ? Using WicketTester will be sufficient or we will have to something like selenium/webdriver ? why using WicketTester in the first place ? How to organize a tests ? What is your opinion about http://code.google.com/p/enhancedwickettester/? Some pitfalls and or tricks ? Thank you... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket mentioned in Maven book...
cool! On Wed, Jan 20, 2010 at 7:22 AM, nino martinez wael nino.martinez.w...@gmail.com wrote: Hi Guys Just wanted to tell that wicket are mentioned here as a noticeable archetype ( the quickstart ) http://www.sonatype.com/books/mvnref-book/reference/archetype-sect-third-party.html And good words from the book : Apache Wicket is a component-oriented web framework which focused on managing the server-side state of a number of components written in Java and simple HTML. Where a framework like Spring MVC or Ruby on Rails focuses on merging objects within a request with a series of page templates, Wicket is very strongly focused on capturing interactions and page structure in a series of POJO Java classes. In an age where hype-driven tech media outlets are proclaiming the Death of Java, Wicket is a contrarian approach to the design and assembly of web applications. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Thanks for wicket: it is awesome and I'm just getting to know it
yes, looks like real desktop application code but it is web :)
On Tue, Jan 19, 2010 at 6:23 PM, Chuck Brinkman chasb1...@gmail.com wrote:
Just wanted to say thanks for wicket.
I have a ListMultipleChoice and wanted to update the page based on at least
one item selected or no items selected. It took a while for me to locate
lmc.add(new AjaxFormComponentUpdatingBehavior(onChange) {
@Override
protected void onUpdate(AjaxRequestTarget target) {
// do the right thing here!
}
});
but once I did it just worked. I like things that just work. I don't know
js very well so just java and just html if real attractive to me.
Thanks again for wicket.
Chuck
Re: Wicket feedback
It is HTTP! and we can use OOP very well. Wicket makes it possible. +1 for wicket :) NM On Wed, Dec 23, 2009 at 1:51 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: and where is this more OO? -igor On Wed, Dec 23, 2009 at 7:24 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: I vote +1 for more OO Wicket. Way to go Ricardo! ** Martin 2009/12/23 Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com: Hi Igor, Thanks for your response. Here goes my observations: Em 22/12/2009 14:41, Igor Vaynberg escreveu: On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com wrote: Hi all, We've just finished with success a wicket project for a large online retailer. I think wicket is the best framework out there, but as any other project there is room for improvement. I will talk about some topics bellow, I hope it can help in some way. - Separation of corcerns I think we could get a better separation of concerns if page class were focused more in behavior and html were more focused in display (or view). What I mean is, some times we have components that the main purpose is to add behavior, and we have to add extra markup just to satisfy wicket 1:1 mapping. Take CheckGroup for exaple, it is a component focused on behavior, even though we have to add a reference to it in HTML. a redesigned CheckGroup is welcome, but that component is the exception and not the rule. Yes, but how do we deal with the requirement of all components having a HTML representation? The same happens with RadioGroup, even with wicket-1055 solved, the HTML reference is still there. When creating composite input fields (like date), the usual way is to create a panel even if you are not interested in reusability. A interesting aproach is to insert a hidden text field in HTML mapped to a component that controls other components input. It makes easier to integrate with designer and to preview in browser. If we didn't have this limitation the hidden input would not be necessary and the development of behavior focused components would be easier. i dont really understand this..the usual way would be to extend a FormComponentPanel, not a Panel. are you saying that because the Panel derivatives are just adiv in the markup it makes it difficult for the designers? You're right, I meant FormComponentPanel. I think it would be better not being constrained to have a separate markup just because server side processing will be different. After all in HTML terms, a composite input is the same as a single input. Another example of unecessary coupling IMO is that text area and input text fields are mapped to different components, even behaving the same. Even if there are internals when manipulating one or another, I think it should be handled by wicket because for the programmer it makes no difference. One thing that bothers me is when our designer move things around in HTML and we get added a component in code but forgot to reference it in the markup error, because of component hierarchy. Html tags position is a view problem not a behavior problem, so why bother in java? it *is* a behavior problem. markup is what drives the rendering order so if you move things around and change the nesting order of components then you can have a component that is a child of another render *before* the parent which will cause things to go seriously out of whack. in my company the designers understand that they cannot change the nesting of tags with wicket:id attributes, it took an hour to explain it to them, and we have not had any problems since. in practice, there is no need to do that often anyways... IMO learning how to deal with a restriction, isn't better than removing that restriction. Even if it doens't happen often, I would be happier if it never happens :) Render order seems a wicket internal concern to me not a business or application behavior concern. Another issue, is when we want to change the class of a div, for example, and have to change our whole page hierarchy in java, just to manipulate that tag. you dont have to change the hierarchy, just make the component attached to that div a transparent resolver by overriding isTransparentResolver() and returning true. So I think a hierarchy more focused on components behavior (for example taking care of inherited models and inputs), rather than tags position in HTML would be better. This would make wicket more flexible and easier to work with. once again, this is only a problem when you change the *nesting* of components. if a component can be safely moved outside the parent, then why is there a nesting to begin with? why arent the two components siblings? the *nesting* is usually there *because* there is a functional
Re: Wicket feedback
i think it is a trade off. we synchronize with the markup and lose some OOP, but we gain in desing. Have you ever change the look and feel of your application? with wicket it is really easy, in other frameworks it is a nightmare. NM On Wed, Dec 23, 2009 at 3:53 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: More OO is less synchronization between markup and wicket. It should be sufficient that the artist thinks the gfx are immacculate and that the java developer thinks the code is immacculate. Why do we need to couple java with html hierarchies and stuff? Some namespace attribute could suffice to allow nested components. ** Martin On Wed, Dec 23, 2009 at 1:51 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: and where is this more OO? -igor On Wed, Dec 23, 2009 at 7:24 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: I vote +1 for more OO Wicket. Way to go Ricardo! ** Martin 2009/12/23 Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com: Hi Igor, Thanks for your response. Here goes my observations: Em 22/12/2009 14:41, Igor Vaynberg escreveu: On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer ricardo.ekm.lis...@gmail.com wrote: Hi all, We've just finished with success a wicket project for a large online retailer. I think wicket is the best framework out there, but as any other project there is room for improvement. I will talk about some topics bellow, I hope it can help in some way. - Separation of corcerns I think we could get a better separation of concerns if page class were focused more in behavior and html were more focused in display (or view). What I mean is, some times we have components that the main purpose is to add behavior, and we have to add extra markup just to satisfy wicket 1:1 mapping. Take CheckGroup for exaple, it is a component focused on behavior, even though we have to add a reference to it in HTML. a redesigned CheckGroup is welcome, but that component is the exception and not the rule. Yes, but how do we deal with the requirement of all components having a HTML representation? The same happens with RadioGroup, even with wicket-1055 solved, the HTML reference is still there. When creating composite input fields (like date), the usual way is to create a panel even if you are not interested in reusability. A interesting aproach is to insert a hidden text field in HTML mapped to a component that controls other components input. It makes easier to integrate with designer and to preview in browser. If we didn't have this limitation the hidden input would not be necessary and the development of behavior focused components would be easier. i dont really understand this..the usual way would be to extend a FormComponentPanel, not a Panel. are you saying that because the Panel derivatives are just adiv in the markup it makes it difficult for the designers? You're right, I meant FormComponentPanel. I think it would be better not being constrained to have a separate markup just because server side processing will be different. After all in HTML terms, a composite input is the same as a single input. Another example of unecessary coupling IMO is that text area and input text fields are mapped to different components, even behaving the same. Even if there are internals when manipulating one or another, I think it should be handled by wicket because for the programmer it makes no difference. One thing that bothers me is when our designer move things around in HTML and we get added a component in code but forgot to reference it in the markup error, because of component hierarchy. Html tags position is a view problem not a behavior problem, so why bother in java? it *is* a behavior problem. markup is what drives the rendering order so if you move things around and change the nesting order of components then you can have a component that is a child of another render *before* the parent which will cause things to go seriously out of whack. in my company the designers understand that they cannot change the nesting of tags with wicket:id attributes, it took an hour to explain it to them, and we have not had any problems since. in practice, there is no need to do that often anyways... IMO learning how to deal with a restriction, isn't better than removing that restriction. Even if it doens't happen often, I would be happier if it never happens :) Render order seems a wicket internal concern to me not a business or application behavior concern. Another issue, is when we want to change the class of a div, for example, and have to change our whole page hierarchy in java, just to manipulate
Re: [announce] Wicket 1.4.4
great! los re banco muchachos is what we would say in argentina :) NM On Fri, Dec 11, 2009 at 3:35 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: and now with a working changelog link: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310561fixfor=12314323sorter/field=prioritysorter/order=DESC -igor On Fri, Dec 11, 2009 at 10:16 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: The Apache Wicket project is proud to announce the fourth maintenance release of Apache Wicket 1.4. Download Apache Wicket 1.4 -- You can download the release here: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 Or use this in your Maven pom's to upgrade to the new version: dependency groupIdorg.apache.wicket/groupId artifactIdwicket/artifactId version1.4.4/version /dependency Changes - A complete list of changes can be found here: https://issues.apache.org/jira/secure/IssueNavigator.jspa?fixfor=12314323 We thank you for your patience and support. -The Wicket Team - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Very Basic Hello World - Applet
do that : I'd say get your applet working in a non-wicket, java webapp (with a static HTML page) first. Then, wicketize it. then make panel using your working applet html and add it to a WebPage with it own html NM On Wed, Dec 9, 2009 at 1:37 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Guys i am a bit confused now... Take it slow :) I am trying to have an Applet displayed in a wicket website... That's fine. It is just like displaying an IMAGE in a html page. The applet has nothing to do with wicket. should i create a JAR as HelloWorld.jar and put it in to the WEBAPP folder NO. Just make a quickstart WORK and try to make IMAGE (img) work with the image in webapp/ directory. Then put your applet.class file into the webapp/directory and add the applet html tag next to your img tag. Restart if necessary. Furthermore: it should work even from file system without wicket running. Remember: applet has nothing to do with wicket. ** Martin MartinM wrote: The jar is a library for the applet code. Baybe you do not need it. ** Martin 2009/12/9 local_shamil shaena...@gmail.com: Ok... this is the code i used to create my Maven Wicket project mvn archetype:create -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.4.3 -DgroupId=com.mycompany -DartifactId=myproject and i used the above example to create http://journals.ecs.soton.ac.uk/java/tutorial/getStarted/applet/index.html my applet So what i did was i added the HelloWorld.java and HelloWorld.html file in the com.mycompany pakage.. have i done correctly up to this point ?? then i dont undestand what archive=/xyz.jar that u have quoted in your reply ... Should i have to create a HelloWorl.jar file and have it in the com.mycompany package ?? Please help ... :( :( -- View this message in context: http://old.nabble.com/Very-Basic-Hello-World---Applet-tp26712682p26712974.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://old.nabble.com/Very-Basic-Hello-World---Applet-tp26712682p26713212.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
