RE: VOTE: Rename Apache Wicket to Apache WicketFX
+1 -Original Message- From: martijn.dasho...@gmail.com [mailto:martijn.dasho...@gmail.com] On Behalf Of Martijn Dashorst Sent: Wednesday, April 01, 2009 3:03 AM To: d...@wicket.apache.org; users@wicket.apache.org Subject: VOTE: Rename Apache Wicket to Apache WicketFX The Wicket PMC has discussed the following action. Because I think it is prudent that the Wicket community keeps evolving with the state of Java, I've created a board resolution to rename Wicket to WicketFX (thanks Igor for the suggestion!) WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and the Apache Wicket community to rename Apache Wicket to Apache WicketFX to get presentation slots at the JavaOne conference, and make it easier to obtain JSR status. NOW, THEREFORE, BE IT RESOLVED, that the project formerly known as the Apache Wicket project, be and hereby is renamed to Apache WicketFX; and be it further RESOLVED, that the Apache WicketFX PMC be and hereby is responsible to submit or propose new presentations and tutorials to the JavaOne Conference concerning Wicket and FX; and be it further RESOLVED, that the Apache WicketFX PMC be and hereby is responsible to submit the Apache WicketFX project to the JCP and obtain JSR status; and be it further RESOLVED, that the original Apache Wicket PMC be and hereby is dissolved of its responsibilities for this day, April 1st, 2009. [ ] +1, accept above resolution [ ] -1, don't accept above resolution, because ... This vote runs for just today, otherwise we won't be able to get it accepted by the board this month. Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket at ApacheCon EU'09 in Amsterdam
That is a good point... That is the very reason why they are now trying to push WebBeans as part of the standard profile ;o) -Original Message- From: Oleg Taranenko [mailto:taranenko.for...@googlemail.com] Sent: Friday, February 13, 2009 4:05 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam Hmm... some time ago (approx 1,5 year ) was attempts to marry JBoss Seam and Wicket. Was it successful? May be this is an example, why wicket should to be treated as a standard? Oleg On Fri, Feb 13, 2009 at 4:59 PM, Hoover, William whoo...@nemours.orgwrote: First of all, thank you for entertaining this idea :o) See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 9:38 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam From a developers point-of-view standardization can often be a thorn in our side, but for management it can offer a vendor-independent/implementation-independent solution. Maintaining/upgrading infrastructure is difficult, expensive and time consuming. From the point-of-view of management a standard can often minimize the risk of vender lock-in. But the examples you gave me have multiply implementations. But wicket doesnt have multiply implementations, what would that mean? That we have IComponent, IRequestCycle, ISession and IApplication and so on? And that IBM would make its own implementation of all the components including the base? And JBoss and X and Y? Answer: They do not have multiple implementations now, but they could potentially have them in the future. It would mean that other communities could follow a standard and mangement could be satisfied that Wicket has the backing of a recognized standard. There is no vendor locking for wicket.. (and all other open source web frameworks by the way) what is the locking? Answer: I agree that other frameworks that have a standard have been disastrous as far as portability between implementations (such as the loosly organized JSF specification), but the locking I'm referring to is in realation to the vendor (Wicket in this case) from a business standpoint. I for one do not have an issue with being tightly coupled to Wicket, but I can see why managment may have an issue with it. A question we need to ask ourselves from a management standpoit is if for whatever reason we had to migrate from Wicket to another framework, what revenue impact would that have on our organization in doing so? If we chose a standards base solution would this minimize the risk due to multiple vendor offerings? And wicket runs pretty much on all simple servlet containers.. Some bugs in some not counting... So give me a concreet example what a standardized wicket would look like. What vendor-independent/implementation-independent solutions there would be then.. Answer: This is a preliminary concept, but the Swing-like architecture for the web could be a starting point? Another thing to consider is that a broader multi-community involvement could also bread innovation. There may be other innovators from other communities that may have valuable input that could improve Wicket in ways that may have not been previously considered. IMHO, the biggest argument for JSR/JCP is that there is often a broader involvement in the process. Hibernate, for instance, was in a similar position a few years back when they introduced a new persistence concept. They have since become heavily involved in the JPA specification process. When I first worked with Hibernate, like many, I was very impressed (similar to the first time I worked with Wicket :o), but looking back at how Hiberante initially did things to how they do them now there are some huge improvements due to the JPA specification. look hibernate is an implementation of a persistence.. And they adapted (and where involved) into the specifications yes Ok now translate that to wicket.. What is wicket an implementation of? a webframework? ahh.. tapestry is also a webframework and struts is also a webframework They all implement the standard webframework spec.. which is the servlet spec.. So JPA Spec == Servlet Spec Hibernate == Wicket TopLink == Tapestry So wicket is already in the JSR/JCP ! we are an enhancement/implementation of the servlet spec :) ok ok. Maybe you say.. sevlet spec implementation == servlet .jar and tomcat ;) not the thing you would build on top of that again But then if you have wicket,tapestry and struts (and x and y) and then you want to define a Web Framework spec that all of them can adapt to what would that then be? What would that then gain? Would that mean that tapestry components/pages could run inside wicket? It is just not as easy to do as with a persistence spec. Which is pretty easy
RE: Wicket at ApacheCon EU'09 in Amsterdam
http://opensource.atlassian.com/confluence/spring/display/JSR168/2008/04 /18/Plans+for+JSR+286+Support -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, February 13, 2009 4:15 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam how will having wicket as a standard help this? look at spring, it is no jsr but a lot of projects integrate with it, and it in return integrates with other projects. anyways, there is already a start of wicket seam support by the seam folks. http://in.relation.to/Bloggers/SeamlessWicket -igor On Fri, Feb 13, 2009 at 1:05 PM, Oleg Taranenko taranenko.for...@googlemail.com wrote: Hmm... some time ago (approx 1,5 year ) was attempts to marry JBoss Seam and Wicket. Was it successful? May be this is an example, why wicket should to be treated as a standard? Oleg On Fri, Feb 13, 2009 at 4:59 PM, Hoover, William whoo...@nemours.orgwrote: First of all, thank you for entertaining this idea :o) See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 9:38 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam From a developers point-of-view standardization can often be a thorn in our side, but for management it can offer a vendor-independent/implementation-independent solution. Maintaining/upgrading infrastructure is difficult, expensive and time consuming. From the point-of-view of management a standard can often minimize the risk of vender lock-in. But the examples you gave me have multiply implementations. But wicket doesnt have multiply implementations, what would that mean? That we have IComponent, IRequestCycle, ISession and IApplication and so on? And that IBM would make its own implementation of all the components including the base? And JBoss and X and Y? Answer: They do not have multiple implementations now, but they could potentially have them in the future. It would mean that other communities could follow a standard and mangement could be satisfied that Wicket has the backing of a recognized standard. There is no vendor locking for wicket.. (and all other open source web frameworks by the way) what is the locking? Answer: I agree that other frameworks that have a standard have been disastrous as far as portability between implementations (such as the loosly organized JSF specification), but the locking I'm referring to is in realation to the vendor (Wicket in this case) from a business standpoint. I for one do not have an issue with being tightly coupled to Wicket, but I can see why managment may have an issue with it. A question we need to ask ourselves from a management standpoit is if for whatever reason we had to migrate from Wicket to another framework, what revenue impact would that have on our organization in doing so? If we chose a standards base solution would this minimize the risk due to multiple vendor offerings? And wicket runs pretty much on all simple servlet containers.. Some bugs in some not counting... So give me a concreet example what a standardized wicket would look like. What vendor-independent/implementation-independent solutions there would be then.. Answer: This is a preliminary concept, but the Swing-like architecture for the web could be a starting point? Another thing to consider is that a broader multi-community involvement could also bread innovation. There may be other innovators from other communities that may have valuable input that could improve Wicket in ways that may have not been previously considered. IMHO, the biggest argument for JSR/JCP is that there is often a broader involvement in the process. Hibernate, for instance, was in a similar position a few years back when they introduced a new persistence concept. They have since become heavily involved in the JPA specification process. When I first worked with Hibernate, like many, I was very impressed (similar to the first time I worked with Wicket :o), but looking back at how Hiberante initially did things to how they do them now there are some huge improvements due to the JPA specification. look hibernate is an implementation of a persistence.. And they adapted (and where involved) into the specifications yes Ok now translate that to wicket.. What is wicket an implementation of? a webframework? ahh.. tapestry is also a webframework and struts is also a webframework They all implement the standard webframework spec.. which is the servlet spec.. So JPA Spec == Servlet Spec Hibernate == Wicket TopLink == Tapestry So wicket is already in the JSR/JCP ! we are an enhancement/implementation of the servlet spec :) ok ok. Maybe you say.. sevlet spec implementation == servlet .jar and tomcat ;) not the thing you would build on top
RE: Wicket at ApacheCon EU'09 in Amsterdam
Rod Johnson (creator of spring) talks about JCP, JEE, and Spring: http://java.sys-con.com/node/732455 -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, February 13, 2009 4:15 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam how will having wicket as a standard help this? look at spring, it is no jsr but a lot of projects integrate with it, and it in return integrates with other projects. anyways, there is already a start of wicket seam support by the seam folks. http://in.relation.to/Bloggers/SeamlessWicket -igor On Fri, Feb 13, 2009 at 1:05 PM, Oleg Taranenko taranenko.for...@googlemail.com wrote: Hmm... some time ago (approx 1,5 year ) was attempts to marry JBoss Seam and Wicket. Was it successful? May be this is an example, why wicket should to be treated as a standard? Oleg On Fri, Feb 13, 2009 at 4:59 PM, Hoover, William whoo...@nemours.orgwrote: First of all, thank you for entertaining this idea :o) See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 9:38 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam From a developers point-of-view standardization can often be a thorn in our side, but for management it can offer a vendor-independent/implementation-independent solution. Maintaining/upgrading infrastructure is difficult, expensive and time consuming. From the point-of-view of management a standard can often minimize the risk of vender lock-in. But the examples you gave me have multiply implementations. But wicket doesnt have multiply implementations, what would that mean? That we have IComponent, IRequestCycle, ISession and IApplication and so on? And that IBM would make its own implementation of all the components including the base? And JBoss and X and Y? Answer: They do not have multiple implementations now, but they could potentially have them in the future. It would mean that other communities could follow a standard and mangement could be satisfied that Wicket has the backing of a recognized standard. There is no vendor locking for wicket.. (and all other open source web frameworks by the way) what is the locking? Answer: I agree that other frameworks that have a standard have been disastrous as far as portability between implementations (such as the loosly organized JSF specification), but the locking I'm referring to is in realation to the vendor (Wicket in this case) from a business standpoint. I for one do not have an issue with being tightly coupled to Wicket, but I can see why managment may have an issue with it. A question we need to ask ourselves from a management standpoit is if for whatever reason we had to migrate from Wicket to another framework, what revenue impact would that have on our organization in doing so? If we chose a standards base solution would this minimize the risk due to multiple vendor offerings? And wicket runs pretty much on all simple servlet containers.. Some bugs in some not counting... So give me a concreet example what a standardized wicket would look like. What vendor-independent/implementation-independent solutions there would be then.. Answer: This is a preliminary concept, but the Swing-like architecture for the web could be a starting point? Another thing to consider is that a broader multi-community involvement could also bread innovation. There may be other innovators from other communities that may have valuable input that could improve Wicket in ways that may have not been previously considered. IMHO, the biggest argument for JSR/JCP is that there is often a broader involvement in the process. Hibernate, for instance, was in a similar position a few years back when they introduced a new persistence concept. They have since become heavily involved in the JPA specification process. When I first worked with Hibernate, like many, I was very impressed (similar to the first time I worked with Wicket :o), but looking back at how Hiberante initially did things to how they do them now there are some huge improvements due to the JPA specification. look hibernate is an implementation of a persistence.. And they adapted (and where involved) into the specifications yes Ok now translate that to wicket.. What is wicket an implementation of? a webframework? ahh.. tapestry is also a webframework and struts is also a webframework They all implement the standard webframework spec.. which is the servlet spec.. So JPA Spec == Servlet Spec Hibernate == Wicket TopLink == Tapestry So wicket is already in the JSR/JCP ! we are an enhancement/implementation of the servlet spec :) ok ok. Maybe you say.. sevlet spec implementation == servlet .jar and tomcat ;) not the thing you would build on top
RE: Wicket at ApacheCon EU'09 in Amsterdam
I hear the arguments and I completely agree with the notion that innovation usually happens elsewhere and a JSR/JCP would slow that process down. I just want to objectively view the other side of the spectrum :o) From a developers point-of-view standardization can often be a thorn in our side, but for management it can offer a vendor-independent/implementation-independent solution. Maintaining/upgrading infrastructure is difficult, expensive and time consuming. From the point-of-view of management a standard can often minimize the risk of vender lock-in. Another thing to consider is that a broader multi-community involvement could also bread innovation. There may be other innovators from other communities that may have valuable input that could improve Wicket in ways that may have not been previously considered. IMHO, the biggest argument for JSR/JCP is that there is often a broader involvement in the process. Hibernate, for instance, was in a similar position a few years back when they introduced a new persistence concept. They have since become heavily involved in the JPA specification process. When I first worked with Hibernate, like many, I was very impressed (similar to the first time I worked with Wicket :o), but looking back at how Hiberante initially did things to how they do them now there are some huge improvements due to the JPA specification. My hope is that the Wicket community can be as open-minded to this notion as they are to the open source code they represent :o) -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 4:10 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam and what would a wicket standard give you? Except that those idiotic managers then say its standardized.. now you can use it why is that is a standard for ever? dont think so everything dies. But would it run on more platforms? Would we have multiply implementations? Because thats most of the time a JCP/JSR does, it doesnt have an implementation, what wicket is, but a description/interfaces what an implementation should do.. johan On Fri, Feb 13, 2009 at 10:00, Martijn Dashorst martijn.dasho...@gmail.comwrote: Bill Joy from Sun once said: innovation happens elsewhere. I think that the where elsewhere isn't, it is the JCP. Standardization is just antithetical to innovation. Once something is fixed in brick/mortar how can you innovate? Wicket is very comfortably located elsewhere. Martijn On Thu, Feb 12, 2009 at 10:05 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: we like the agility that the independence from any sort of a standard offers us. -igor On Thu, Feb 12, 2009 at 12:01 PM, Hoover, William whoo...@nemours.org wrote: Judging by the responses (or the lack thereof), It seems as though there isn't enough support from the Wicket community to push for something like this :( -Original Message- From: tomlist0...@gmail.com [mailto:tomlist0...@gmail.com] On Behalf Of Thomas Mäder Sent: Thursday, February 12, 2009 12:57 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam I totally agree that the JSR process is horrid. However, Wicket could really use some more corporate credibility (which a JSR would provide). The problem, I guess is that there are simply no corporate interests behind Wicket that would push the agenda. What wicket need is some evangelism, but I guess all the core people have real jobs. What we need is less talks titled why wicket is cool and more cut your development costs in two with Wicket. From experience, I am totally convinced that you can save 50% off your development costs if you switch to wicket (from just about any other framework), however, I've yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts). Thomas On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner jcompag...@gmail.com wrote: And then come into the horrible voting/administive stuff? Long Release cycles that are controlled, features that are discussed over and over. Hmm On 12/02/2009, Hoover, William whoo...@nemours.org wrote: Just out of curiosity... Are there any plans to push a JSR that Wicket could follow. I think there would be a lot more acceptance of Wicket if this was to happen :o) -Original Message- From: martijn.dasho...@gmail.com [mailto:martijn.dasho...@gmail.com] On Behalf Of Martijn Dashorst Sent: Wednesday, February 11, 2009 5:33 PM To: users@wicket.apache.org Subject: Wicket at ApacheCon EU'09 in Amsterdam We're happy to announce a lot of Wicket involvement at the upcoming ApacheCon in Amsterdam (23-27 March 2009) First of all we have 2 training sessions available: - Introduction to Wicket by Martijn Dashorst on Mon 23 March (http://tinyurl.com
RE: Wicket at ApacheCon EU'09 in Amsterdam
I agree that we need to change the views of corporate managers in the right way by illustrating the cost savings achieved though a reduction in development time. At the same time, I don't believe that this will change the Wicket community in the wrong way (which is a highly subjective statement). I'm only presenting the alternative viewpoint. It is possible that a standard could potentially inhibit progression due to contrasting viewpoints within the community, but it is also equally possible that it could lead to a value-added aspect by introducing a broader input base to the Wicket community that could speed progression (Hibernate/JPA is an example of this). There is always a possibility that progress can be slowed as the number of members increase because there are more viewpoints to be examined/debated. I think that there is a higher probability that the community will grow if such a standard were to be adopted. Just because there is already a specification for a web framework (JSF) that does not constitute abandoning a standard approach. Look at JAX-WS vs JAX-RS. They accomplish many of the same objectives, but they both are part of the proposed profile stack (http://www.theserverside.com/tt/articles/article.tss?l=JavaEE6Overview) . A Wicket implementation could orchestrate a refreshing alternative approach to JSF in the same manner that it does today. When I referred to open-mindedness I was referring to being open-minded to the ideas behind the push... I didn't necessary intended to imply that anyone would not be open-minded if they did not support a JSR :o) -Original Message- From: Dave Schoorl [mailto:mailli...@cyber-d.com] Sent: Friday, February 13, 2009 9:21 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam I am not sure what you would like to standardize. Given your JPA example, I would guess that you want to push a JSR for a web framework or something. But there is already something like that: JSF. Just let Wicket be Wicket and instead of changing Wicket (and it's community) in the wrong way, let's try to change the views of corporate managers in the right way. As Thomas said earlier What we need is less talks titled 'why wicket is cool' and more 'cut your development costs in two with Wicket' . And I do not think that the lack of support for pushing a JSR has anything to do with a lack of open-mindedness... Hoover, William wrote: I hear the arguments and I completely agree with the notion that innovation usually happens elsewhere and a JSR/JCP would slow that process down. I just want to objectively view the other side of the spectrum :o) From a developers point-of-view standardization can often be a thorn in our side, but for management it can offer a vendor-independent/implementation-independent solution. Maintaining/upgrading infrastructure is difficult, expensive and time consuming. From the point-of-view of management a standard can often minimize the risk of vender lock-in. Another thing to consider is that a broader multi-community involvement could also bread innovation. There may be other innovators from other communities that may have valuable input that could improve Wicket in ways that may have not been previously considered. IMHO, the biggest argument for JSR/JCP is that there is often a broader involvement in the process. Hibernate, for instance, was in a similar position a few years back when they introduced a new persistence concept. They have since become heavily involved in the JPA specification process. When I first worked with Hibernate, like many, I was very impressed (similar to the first time I worked with Wicket :o), but looking back at how Hiberante initially did things to how they do them now there are some huge improvements due to the JPA specification. My hope is that the Wicket community can be as open-minded to this notion as they are to the open source code they represent :o) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket at ApacheCon EU'09 in Amsterdam
First of all, thank you for entertaining this idea :o) See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 9:38 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam From a developers point-of-view standardization can often be a thorn in our side, but for management it can offer a vendor-independent/implementation-independent solution. Maintaining/upgrading infrastructure is difficult, expensive and time consuming. From the point-of-view of management a standard can often minimize the risk of vender lock-in. But the examples you gave me have multiply implementations. But wicket doesnt have multiply implementations, what would that mean? That we have IComponent, IRequestCycle, ISession and IApplication and so on? And that IBM would make its own implementation of all the components including the base? And JBoss and X and Y? Answer: They do not have multiple implementations now, but they could potentially have them in the future. It would mean that other communities could follow a standard and mangement could be satisfied that Wicket has the backing of a recognized standard. There is no vendor locking for wicket.. (and all other open source web frameworks by the way) what is the locking? Answer: I agree that other frameworks that have a standard have been disastrous as far as portability between implementations (such as the loosly organized JSF specification), but the locking I'm referring to is in realation to the vendor (Wicket in this case) from a business standpoint. I for one do not have an issue with being tightly coupled to Wicket, but I can see why managment may have an issue with it. A question we need to ask ourselves from a management standpoit is if for whatever reason we had to migrate from Wicket to another framework, what revenue impact would that have on our organization in doing so? If we chose a standards base solution would this minimize the risk due to multiple vendor offerings? And wicket runs pretty much on all simple servlet containers.. Some bugs in some not counting... So give me a concreet example what a standardized wicket would look like. What vendor-independent/implementation-independent solutions there would be then.. Answer: This is a preliminary concept, but the Swing-like architecture for the web could be a starting point? Another thing to consider is that a broader multi-community involvement could also bread innovation. There may be other innovators from other communities that may have valuable input that could improve Wicket in ways that may have not been previously considered. IMHO, the biggest argument for JSR/JCP is that there is often a broader involvement in the process. Hibernate, for instance, was in a similar position a few years back when they introduced a new persistence concept. They have since become heavily involved in the JPA specification process. When I first worked with Hibernate, like many, I was very impressed (similar to the first time I worked with Wicket :o), but looking back at how Hiberante initially did things to how they do them now there are some huge improvements due to the JPA specification. look hibernate is an implementation of a persistence.. And they adapted (and where involved) into the specifications yes Ok now translate that to wicket.. What is wicket an implementation of? a webframework? ahh.. tapestry is also a webframework and struts is also a webframework They all implement the standard webframework spec.. which is the servlet spec.. So JPA Spec == Servlet Spec Hibernate == Wicket TopLink == Tapestry So wicket is already in the JSR/JCP ! we are an enhancement/implementation of the servlet spec :) ok ok. Maybe you say.. sevlet spec implementation == servlet .jar and tomcat ;) not the thing you would build on top of that again But then if you have wicket,tapestry and struts (and x and y) and then you want to define a Web Framework spec that all of them can adapt to what would that then be? What would that then gain? Would that mean that tapestry components/pages could run inside wicket? It is just not as easy to do as with a persistence spec. Which is pretty easy because so many things kind of already work the same way before they where under the same spec.. web frameworks differ quite a bit Answer: Ironically, the same argument that Wicket follows the Servlet specification is the same one I used in some of the dicusssions with my colleagues ;o) I think there is a lot to gain in standardizing a Swing-like architecture such as Wicket. The answer to your question is the same reason why Wicket prides itself as a truly decoupled solution that facilitates a true MVC2 model. As stated previously, it would also gain more corporate acceptance. I think that web framework only differs from other tiers because noone has come to the table with a more viable solution than JSP/JSF in the
RE: Wicket at ApacheCon EU'09 in Amsterdam
I see that pushing for a Wicket standard is futile, but I will make one last attempt to answer some of your questions... See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 12:17 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam swing like? are there multiply implementations for swing? Can i choose one from Sun and one from X? or better said are there any desktop UI frameworks that do have multiply implementations (for the same platform??) not that i know of . There could be a reason for that Answer: Swing-like is referring to the programming model style- not the actual Swing framework (thus the word like :o). However, there could very well be other implementations for Swing, but that is another topic altogether. One of the reasons why you don't see multiple implementations of Swing is that it is part of Sun's Java Foundation Classes (JFC)- web frameworks are not ;o) so your managers just want to program against interfaces.. And be able to drop it into any container i dont see the point. That makes testing only more horrible, every container has its own bugs and slightly different behaviors... Answer: The reasoning that every container has its own bugs and slightly different behaviors is the very reason why management may want the flexibility to change implementations (the purpose for the standard in the first place). One implementation may not implement some features as well as others. Does anybody here on the list made a application using JPA persistence and the first against hibernate and then when it was finished swapped it for something else? Answer: It is highly plausible that a switch would be made from one JPA implementation to another. I know of companies that have switched from Hiberante to OpenJPA to do just that. Other reasons may include, but are not limited to: better support from one vendor to the next, discounted support through partner programs, light-weight implementation, etc. On Fri, Feb 13, 2009 at 16:59, Hoover, William whoo...@nemours.org wrote: First of all, thank you for entertaining this idea :o) See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 9:38 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam From a developers point-of-view standardization can often be a thorn in our side, but for management it can offer a vendor-independent/implementation-independent solution. Maintaining/upgrading infrastructure is difficult, expensive and time consuming. From the point-of-view of management a standard can often minimize the risk of vender lock-in. But the examples you gave me have multiply implementations. But wicket doesnt have multiply implementations, what would that mean? That we have IComponent, IRequestCycle, ISession and IApplication and so on? And that IBM would make its own implementation of all the components including the base? And JBoss and X and Y? Answer: They do not have multiple implementations now, but they could potentially have them in the future. It would mean that other communities could follow a standard and mangement could be satisfied that Wicket has the backing of a recognized standard. There is no vendor locking for wicket.. (and all other open source web frameworks by the way) what is the locking? Answer: I agree that other frameworks that have a standard have been disastrous as far as portability between implementations (such as the loosly organized JSF specification), but the locking I'm referring to is in realation to the vendor (Wicket in this case) from a business standpoint. I for one do not have an issue with being tightly coupled to Wicket, but I can see why managment may have an issue with it. A question we need to ask ourselves from a management standpoit is if for whatever reason we had to migrate from Wicket to another framework, what revenue impact would that have on our organization in doing so? If we chose a standards base solution would this minimize the risk due to multiple vendor offerings? And wicket runs pretty much on all simple servlet containers.. Some bugs in some not counting... So give me a concreet example what a standardized wicket would look like. What vendor-independent/implementation-independent solutions there would be then.. Answer: This is a preliminary concept, but the Swing-like architecture for the web could be a starting point? Another thing to consider is that a broader multi-community involvement could also bread innovation. There may be other innovators from other communities that may have valuable input that could improve Wicket in ways that may have not been previously considered. IMHO, the biggest argument for JSR/JCP is that there is often a broader involvement
RE: Wicket at ApacheCon EU'09 in Amsterdam
Just out of curiosity... Are there any plans to push a JSR that Wicket could follow. I think there would be a lot more acceptance of Wicket if this was to happen :o) -Original Message- From: martijn.dasho...@gmail.com [mailto:martijn.dasho...@gmail.com] On Behalf Of Martijn Dashorst Sent: Wednesday, February 11, 2009 5:33 PM To: users@wicket.apache.org Subject: Wicket at ApacheCon EU'09 in Amsterdam We're happy to announce a lot of Wicket involvement at the upcoming ApacheCon in Amsterdam (23-27 March 2009) First of all we have 2 training sessions available: - Introduction to Wicket by Martijn Dashorst on Mon 23 March (http://tinyurl.com/aceu09wicket1) - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2) Both courses are hosted by core members. Martijn has co-authored Wicket in Action and Timo has been involved with WicketTester and JDave. There is no better team to get you and your team up to speed with the finest Java web framework available and start cranking out fully tested applications. Martijn will also present Wicket in Action during the normal conference days. A quick introduction to Wicket's core features in just one hour. But attending the conference will give you much more: over 60 sessions covering your favorite Apache projects. Amsterdam is great, but Wicket meetups in Amsterdam are even better! We're attempting to schedule a Wicket meetup during the conference at the conference floor. Details will follow soon. Read more about ApacheCon EU 2009 here: http://www.eu.apachecon.com/c/aceu2009/ See you in Amsterdam! Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket at ApacheCon EU'09 in Amsterdam
Judging by the responses (or the lack thereof), It seems as though there isn't enough support from the Wicket community to push for something like this :( -Original Message- From: tomlist0...@gmail.com [mailto:tomlist0...@gmail.com] On Behalf Of Thomas Mäder Sent: Thursday, February 12, 2009 12:57 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam I totally agree that the JSR process is horrid. However, Wicket could really use some more corporate credibility (which a JSR would provide). The problem, I guess is that there are simply no corporate interests behind Wicket that would push the agenda. What wicket need is some evangelism, but I guess all the core people have real jobs. What we need is less talks titled why wicket is cool and more cut your development costs in two with Wicket. From experience, I am totally convinced that you can save 50% off your development costs if you switch to wicket (from just about any other framework), however, I've yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts). Thomas On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner jcompag...@gmail.comwrote: And then come into the horrible voting/administive stuff? Long Release cycles that are controlled, features that are discussed over and over. Hmm On 12/02/2009, Hoover, William whoo...@nemours.org wrote: Just out of curiosity... Are there any plans to push a JSR that Wicket could follow. I think there would be a lot more acceptance of Wicket if this was to happen :o) -Original Message- From: martijn.dasho...@gmail.com [mailto:martijn.dasho...@gmail.com] On Behalf Of Martijn Dashorst Sent: Wednesday, February 11, 2009 5:33 PM To: users@wicket.apache.org Subject: Wicket at ApacheCon EU'09 in Amsterdam We're happy to announce a lot of Wicket involvement at the upcoming ApacheCon in Amsterdam (23-27 March 2009) First of all we have 2 training sessions available: - Introduction to Wicket by Martijn Dashorst on Mon 23 March (http://tinyurl.com/aceu09wicket1) - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2) Both courses are hosted by core members. Martijn has co-authored Wicket in Action and Timo has been involved with WicketTester and JDave. There is no better team to get you and your team up to speed with the finest Java web framework available and start cranking out fully tested applications. Martijn will also present Wicket in Action during the normal conference days. A quick introduction to Wicket's core features in just one hour. But attending the conference will give you much more: over 60 sessions covering your favorite Apache projects. Amsterdam is great, but Wicket meetups in Amsterdam are even better! We're attempting to schedule a Wicket meetup during the conference at the conference floor. Details will follow soon. Read more about ApacheCon EU 2009 here: http://www.eu.apachecon.com/c/aceu2009/ See you in Amsterdam! Martijn - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Thomas Mäder Wicket Eclipse Consulting www.devotek-it.ch - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Java EE 6 Platform Draft- Web Profile?
Seems like a little wicketization should be in order: http://www.infoq.com/news/2009/01/java-ee6-draft - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: What is the best way to handle Undefined attribute name (wicket:id) warnings from Eclipse Ganymede?
?xml version=1.0 encoding=UTF-8? html xmlns=http://www.w3.org/1999/xhtml; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:wicket=http://wicket.apache.org; xsi:schemaLocation=http://www.w3.org/MarkUp/SCHEMA/xhtml11.xsd http://wicket.apache.org; xml:lang=en head titleNew User Registration/title /head body strongEven Newer User Registration Form/strong br/br/ span wicket:id=messagemessage will be here/span /body /html -Original Message- From: Piller Sébastien [mailto:pi...@hmcrecord.ch] Sent: Monday, February 02, 2009 7:35 AM To: users@wicket.apache.org Subject: Re: What is the best way to handle Undefined attribute name (wicket:id) warnings from Eclipse Ganymede? Hi, add the xmlns:wicket definition in html: html xmlns:wicket ... this works fine for me Kent Larsson a écrit : Hi, If I have some HTML with Wicket attributes in it: html head titleNew User Registration/title /head body strongEven Newer User Registration Form/strong br/br/ span wicket:id=messagemessage will be here/span /body /html I get Undefined attribute name (wicket:id). warning from Eclipse Ganymede from the span... line. What's the best solution to get rid of such warnings? If it's possible having some validation would be nice. Best regards, Kent - 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
Active Wicket ExtJS ?
Is there any active projects for Wicket and ExtJS out there? I know of the one that used to be at wickettools.org, but it looks like a dead project (no updates for over a year). There was also talk about adding it to wicketstuff around that same time period, but it doesn't seem like that materialized into anything. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Turn off form validation
http://cwiki.apache.org/WICKET/conditional-validation.html see alternative approach -Original Message- From: Kaspar Fischer [mailto:fisch...@inf.ethz.ch] Sent: Monday, January 19, 2009 5:19 AM To: users@wicket.apache.org Subject: Re: Turn off form validation On 19.12.2008, at 13:45, Martijn Dashorst wrote: Adding a new record to a list should not trigger model updates. It should just add the thing and repaint the container with the added item. If you use a (ajax)submit(link|button) you can setDefaultFormProcessing(false) on the button/link and wicket will not validate nor update model values, but keep the input of the user so it can be validated at actual form submission. Where can I get the input if I do setDefaultFormProcessing(false) when, as you say, model values or not updated? Validation is there to protect your domain objects from invalid data. Now you want to bypass this? I agree. I just do not know yet how to realize this in Wicket. Let me try to explain: I have a custom form component that allows the user to add and remove tags. In order to add a tag, the user enters the tag's name and clicks Add. Obviously, when she clicks Add, I do NOT want the WHOLE form to be validated, as Add is not the form's Submit, but just an intermediate step in the process of filling out the form. Still, I want to get the new tag name she entered -- and for this, I have to do setDefaultFormProcessing(true). Correct? Kaspar P.S. Noon, I think nested forms do not validate so I can't use them. - 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: Why you should not override isVisible
+1 -Original Message- From: s...@meiers.net [mailto:s...@meiers.net] Sent: Friday, January 16, 2009 7:47 AM To: users@wicket.apache.org Subject: Re: Why you should not override isVisible Ok, IMHO it's a bug that wicket calls isVisible() after detachment. Thus caching isVisible() is not needed. Sven - Ursprüngliche Nachricht - Von: Michael Sparer Gesendet: 16.01.09 11:20 Uhr An: users@wicket.apache.org Betreff: Re: Re: Why you should not override isVisible Nope, the problem is that the model object *possibly* gets reloaded if isVisible is called after the cached object got detached - and that's what started the whole bunch of messages Michael svenmeier wrote: What's taking so long in your isVisible() method? The model object should be cached, and is isPositive() so expensive? Sven - Ursprüngliche Nachricht - Von: Scott Swank Gesendet: 16.01.09 02:06 Uhr An: users@wicket.apache.org Betreff: Re: Why you should not override isVisible We have implemented this, perhaps a dozen times or more across our application. For example, there are several payment options whose relevance is determined by whether the customer owes any money on their purchase (e.g. as opposed to using a gift card). These total the order and determine visibility methods were particular hot spots. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: DropDownChoice onchange event with AjaxEventBehaviour
You should use the same label and just replace the model object: final Label label = new Label(text, new Model()); ... label.setModelObject(processing...); ... label.setModelObject(); -Original Message- From: Yazeed Isaacs [mailto:yaz...@switch.tj] Sent: Wednesday, January 07, 2009 8:27 AM To: users@wicket.apache.org Subject: RE: DropDownChoice onchange event with AjaxEventBehaviour Yes, I want feedback text for a lengthy process and then update the table and remove the feedback text. I'm not seeing the words processing... due to all 3 steps in the same onchange event. Example: AjaxEventBehaviour(onchange) { @Override protected onEvent(AjaxRequestTarget target) { // step 1 containerA.replace(new Label(text,processing...)); target.addComponent(containerA); // step 2 DataView data = new DataView(data, new DataProvider(), 10); containerB.replace(data); target.addComponent(containerB); // step 3 containerA.replace(new Label(text,)); target.addComponent(containerA); } } Obviously, step 1 does not belong in the onEvent method since step 3 replace the text with , however step 1 needs to happen during the onchange event. Regards, Yazeed Isaacs - Java Developer yaz...@transactionjunction.co.za -Original Message- From: Ernesto Reinaldo Barreiro [mailto:reier...@gmail.com] Sent: 07 January 2009 03:08 PM To: users@wicket.apache.org Subject: Re: DropDownChoice onchange event with AjaxEventBehaviour Hi, Are you able to see the words processing...? From your post I thought what you wanted was to have some kind of feedback for a lengthy process and once it was finished then update the table and no longer show the processing... anymore... Best, Ernesto On Wed, Jan 7, 2009 at 1:59 PM, Yazeed Isaacs yaz...@switch.tj wrote: If I implement all 3 steps in the same onchange event, then step 3 would remove the text in step 1, resulting in no text being seen on the page. Yazeed Isaacs - Java Developer yaz...@transactionjunction.co.za -Original Message- From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] Sent: 07 January 2009 02:30 PM To: users@wicket.apache.org Subject: Re: DropDownChoice onchange event with AjaxEventBehaviour Why not implement all actions within the same onchange? ** Martin 2009/1/7 Yazeed Isaacs yaz...@switch.tj: Hi I have a select box with an AjaxEventBehaviour linked to its onchange event. I want to perform the following but I need some help. When onchange occurs the following steps are implemented using the AjaxRequestTarget: 1. Update a WebMarkupContainer containerA with the words processing... 2. Update a WebMarkupContainer containerB with a DataView table. 3. Update containerA to display empty, ie. No words. How could I implement step 1 during the onchange event, and then have steps 2 3 execute after the onchange event? Regards, Yazeed Isaacs - Java Developer yaz...@transactionjunction.co.za - 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 - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: How much this graph is accurate?
Yeah sure- mostly due to name recognition. I'm willing to wager that if wicket was backed by a big player like google that it would be higher on the list (just speculation), but to be fair gwt is growing at a faster rate than wicket. -Original Message- From: Martin Grigorov [mailto:mcgreg...@e-card.bg] Sent: Monday, January 05, 2009 12:53 PM To: users@wicket.apache.org Subject: RE: How much this graph is accurate? Add GWT to the comparison El lun, 05-01-2009 a las 09:32 -0500, Hoover, William escribió: I think this: http://www.indeed.com/jobtrends?q=Seam%2C+Grails%2C+Tapestry%2C+Wicket %2 C+Stripesl=relative=1 is more accurate ;o) -Original Message- From: HHB [mailto:hubaghd...@yahoo.ca] Sent: Monday, January 05, 2009 9:24 AM To: users@wicket.apache.org Subject: How much this graph is accurate? Hey, How much this graph is accurate? http://www.indeed.com/jobtrends?q=Seam%2C+Grails%2C+Tapestry%2C+Wicket %2 C+Stripesl= Tapestry is so hot these day?:confused: Don't get me wrong, I respect Tapestry and HLS, I only find it strange. T5 has only one book and you can hardly find some one blog about it. What do you think? -- View this message in context: http://www.nabble.com/How-much-this-graph-is-accurate--tp21291871p2129 18 71.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 - 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: How much this graph is accurate?
If you don't mind having the gwt compiler dependency ;o) -Original Message- From: Hoover, William [mailto:whoo...@nemours.org] Sent: Monday, January 05, 2009 1:20 PM To: users@wicket.apache.org; mcgreg...@e-card.bg Subject: RE: How much this graph is accurate? Yeah sure- mostly due to name recognition. I'm willing to wager that if wicket was backed by a big player like google that it would be higher on the list (just speculation), but to be fair gwt is growing at a faster rate than wicket. -Original Message- From: Martin Grigorov [mailto:mcgreg...@e-card.bg] Sent: Monday, January 05, 2009 12:53 PM To: users@wicket.apache.org Subject: RE: How much this graph is accurate? Add GWT to the comparison El lun, 05-01-2009 a las 09:32 -0500, Hoover, William escribió: I think this: http://www.indeed.com/jobtrends?q=Seam%2C+Grails%2C+Tapestry%2C+Wicket %2 C+Stripesl=relative=1 is more accurate ;o) -Original Message- From: HHB [mailto:hubaghd...@yahoo.ca] Sent: Monday, January 05, 2009 9:24 AM To: users@wicket.apache.org Subject: How much this graph is accurate? Hey, How much this graph is accurate? http://www.indeed.com/jobtrends?q=Seam%2C+Grails%2C+Tapestry%2C+Wicket %2 C+Stripesl= Tapestry is so hot these day?:confused: Don't get me wrong, I respect Tapestry and HLS, I only find it strange. T5 has only one book and you can hardly find some one blog about it. What do you think? -- View this message in context: http://www.nabble.com/How-much-this-graph-is-accurate--tp21291871p2129 18 71.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 - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Turn off form validation
Not sure as to why you cannot use setDefaultFormProcessing? http://cwiki.apache.org/WICKET/conditional-validation.html (see Alternative Approach) -Original Message- From: ywtsang [mailto:ywts...@gmail.com] Sent: Saturday, January 03, 2009 9:46 AM To: users@wicket.apache.org Subject: Re: Turn off form validation i also have a similar use case that requires turning off validation for some ajax button links e.g. i have a form, that may have some text fields with different/none validators and i want to do translation on some of the text fields by ajax/dynamically, so i need to use ajax button links to submit the form with the latest input values to backend logic for this case, we want to supress the validation error (if any) and have wicket to still propagate the form fields to our model automatically we can't use setdefaultformprocess to false for the ajax button link so i go to have a look at the form processing, and copy the wicket's form property propagation logic to my form's onerror: code @Override protected void onError() { // just for demonstration, can make it happen only for certain cases only // before updating, call the interception method for clients beforeUpdateFormComponentModels(); // Update model using form data updateFormComponentModels(); // Persist FormComponents if requested // private, can't call // persistFormComponentData(); super.onError(); } /code there may be problem in propagating the form fields to model if there is validation error, but it looks ok to me because the form fields with no validation error should still get their values submitted and propagated nicely, event some other form fields may have validation error noon wrote: I solved similar problem where I had some required TextField components and an AJAX component which does a AJAX submit. During this AJAX submit I wanted to prohibit all the form validations. I achieved this by setting the AJAX components (an autocomplete TextField with custom AJAX behaviour) into its own nested form... form which is inside another form. I'm not sure does this solve your problem. I found my solution just by trying differend solutions and it worked :) hbf wrote: I have a custom component that allows the user to select one or more tags. For this, the component has a text field and an AjaxButton Add to add a tag. All works fine if I use the component in a form without validation errors. If, however, a text field has setRequired(true), the AjaxButton's onSubmit() method is not called (but onError() instead). In this case, I do not want this behaviour but want form validation to be disabled for the Add AjaxButton. (I still need to get the model values updated, though.) Is there an easy way to achieve this? I've read about conditional validation, http://cwiki.apache.org/WICKET/conditional-validation.html but as my component does not know about the enclosing form, I am looking for another solution. Many thanks, Kaspar - 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/Turn-off-form-validation-tp21090395p21265480.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: How much this graph is accurate?
This means the growth rate of wicket is greater relative to the other chosen technologies. I find forecast trends more useful as an indicator of what the future might hold. -Original Message- From: HHB [mailto:hubaghd...@yahoo.ca] Sent: Monday, January 05, 2009 9:37 AM To: users@wicket.apache.org Subject: RE: How much this graph is accurate? What does this mean? :-/ Hoover, William wrote: I think this: http://www.indeed.com/jobtrends?q=Seam%2C+Grails%2C+Tapestry%2C+Wicket %2 C+Stripesl=relative=1 is more accurate ;o) -Original Message- From: HHB [mailto:hubaghd...@yahoo.ca] Sent: Monday, January 05, 2009 9:24 AM To: users@wicket.apache.org Subject: How much this graph is accurate? Hey, How much this graph is accurate? http://www.indeed.com/jobtrends?q=Seam%2C+Grails%2C+Tapestry%2C+Wicket %2 C+Stripesl= Tapestry is so hot these day?:confused: Don't get me wrong, I respect Tapestry and HLS, I only find it strange. T5 has only one book and you can hardly find some one blog about it. What do you think? -- View this message in context: http://www.nabble.com/How-much-this-graph-is-accurate--tp21291871p2129 18 71.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://www.nabble.com/How-much-this-graph-is-accurate--tp21291871p212920 94.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Turn off form validation
Have you tried processInput? -Original Message- From: ywtsang [mailto:ywts...@gmail.com] Sent: Monday, January 05, 2009 10:15 AM To: users@wicket.apache.org Subject: RE: Turn off form validation because this will not update the model object automatically i.e. i cannot get the updated submitted fields values Hoover, William wrote: Not sure as to why you cannot use setDefaultFormProcessing? http://cwiki.apache.org/WICKET/conditional-validation.html (see Alternative Approach) -Original Message- From: ywtsang [mailto:ywts...@gmail.com] Sent: Saturday, January 03, 2009 9:46 AM To: users@wicket.apache.org Subject: Re: Turn off form validation i also have a similar use case that requires turning off validation for some ajax button links e.g. i have a form, that may have some text fields with different/none validators and i want to do translation on some of the text fields by ajax/dynamically, so i need to use ajax button links to submit the form with the latest input values to backend logic for this case, we want to supress the validation error (if any) and have wicket to still propagate the form fields to our model automatically we can't use setdefaultformprocess to false for the ajax button link so i go to have a look at the form processing, and copy the wicket's form property propagation logic to my form's onerror: code @Override protected void onError() { // just for demonstration, can make it happen only for certain cases only // before updating, call the interception method for clients beforeUpdateFormComponentModels(); // Update model using form data updateFormComponentModels(); // Persist FormComponents if requested // private, can't call // persistFormComponentData(); super.onError(); } /code there may be problem in propagating the form fields to model if there is validation error, but it looks ok to me because the form fields with no validation error should still get their values submitted and propagated nicely, event some other form fields may have validation error noon wrote: I solved similar problem where I had some required TextField components and an AJAX component which does a AJAX submit. During this AJAX submit I wanted to prohibit all the form validations. I achieved this by setting the AJAX components (an autocomplete TextField with custom AJAX behaviour) into its own nested form... form which is inside another form. I'm not sure does this solve your problem. I found my solution just by trying differend solutions and it worked :) hbf wrote: I have a custom component that allows the user to select one or more tags. For this, the component has a text field and an AjaxButton Add to add a tag. All works fine if I use the component in a form without validation errors. If, however, a text field has setRequired(true), the AjaxButton's onSubmit() method is not called (but onError() instead). In this case, I do not want this behaviour but want form validation to be disabled for the Add AjaxButton. (I still need to get the model values updated, though.) Is there an easy way to achieve this? I've read about conditional validation, http://cwiki.apache.org/WICKET/conditional-validation.html but as my component does not know about the enclosing form, I am looking for another solution. Many thanks, Kaspar - 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/Turn-off-form-validation-tp21090395p21265480.htm l 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://www.nabble.com/Turn-off-form-validation-tp21090395p21292775.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: How much this graph is accurate?
I think this: http://www.indeed.com/jobtrends?q=Seam%2C+Grails%2C+Tapestry%2C+Wicket%2 C+Stripesl=relative=1 is more accurate ;o) -Original Message- From: HHB [mailto:hubaghd...@yahoo.ca] Sent: Monday, January 05, 2009 9:24 AM To: users@wicket.apache.org Subject: How much this graph is accurate? Hey, How much this graph is accurate? http://www.indeed.com/jobtrends?q=Seam%2C+Grails%2C+Tapestry%2C+Wicket%2 C+Stripesl= Tapestry is so hot these day?:confused: Don't get me wrong, I respect Tapestry and HLS, I only find it strange. T5 has only one book and you can hardly find some one blog about it. What do you think? -- View this message in context: http://www.nabble.com/How-much-this-graph-is-accurate--tp21291871p212918 71.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Thread.sleep() for only one session
If you need to do these kind things at least utilize java.util.concurrent.* class MyCallable implements CallableMyReturnObject { final public MyReturnObject call() { // calling the another thread; do something and return your object } } final ExecutorService es = Executors.newSingleThreadExecutor(); final FutureMyReturnObject f = es.submit(new MyCallable()); // now we know if something went wrong in our thread and can act accordingly final MyReturnObject mro = f.get(); -Original Message- From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] Sent: Friday, December 05, 2008 11:21 AM To: users@wicket.apache.org Subject: Re: Thread.sleep() for only one session You definitely do NOT want to intentionally sleep a thread - that halts the request, and uses up your thread pool. You instead want the request to complete, but you don't want to allow them to continue trying. So, that being said, you could: 1 - add a value to their session like private long blockedFromSignInUntil and when they've exceeded your threshold, set that for ten minutes future. This isn't bulletproof since they could start a new session by using a new window / browser / blowing away cookies. 2 - if it's on a per-username (rather than a per-session) basis, add a similar value to the user - not allowed signin until This is probably better anyway, because if I'm nefarious guy and I'm trying to sign in to mr nice guy account, you lock mr nice guy account because you are in fact detecting an identity theft attempt. 3 - you could do a combo of the above so that I, nefarious guy when I get blocked from mr nice guy account, can't move on to mr unsuspecting account. Then, just have your sign in form be aware of that value in session or user and not allow a sign in to that account or from that session until the timeout is expired. But as a general rule of thumb, never use Thread.sleep in a web app - especially somewhere in the request cycle. It'll be shooting yourself in the foot. Hope this helps, -- Jeremy Thomerson http://www.wickettraining.com On Fri, Dec 5, 2008 at 9:46 AM, Anton Veretennikov [EMAIL PROTECTED] wrote: Hello all Wicket users. One more question today. I need to implement appearence of sleep if user (session, IP address) tries incorrect login many times. Thread.sleep() seems to stop all sessions at once. Any ideas? Thank you! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets
I think the idea behind this is that size will be called first. If the size is zero there is no need to proceed with the call to get the items. I don't necessarily agree with this approach because a lot of service calls can capture the data in one call (even down to the database level- some support getting the size/results in one call), but the last time I brought this issue up it was disputed. -Original Message- From: Wayne Pope [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 26, 2008 9:20 AM To: users@wicket.apache.org Subject: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets Ok, I was just having a bit of code clean up and I realized that in our IDataProviders we are loading all rows for a given dataset. So looking at the iterator method I see we can limit the result (and the offset). Great I thought - however I see that that the size() method is called as part of the getViewSize() in the AbstractPageableView. Thus I need to call the database here to figure out the size. Am I doing sonething wrong or have I got to hit the database twice for each DataProvider render. Obvously I don't want to hard code a size. Is there any other way ? Thanks Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets
We use the same workaround :o) -Original Message- From: Michael O'Cleirigh [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 26, 2008 9:43 AM To: users@wicket.apache.org Subject: Re: Is there any other way? DataProviders must hit the Db twice for (possible) large datasets Hi Wayne, The way we do it is to only extract the current page from the data provider once per render cycle. e.g. the first time size() is called the underlying extraction is performed to build the list for the size of the current page and all subsequent calls use this cached value. You just need to clear the cached state in provider.detach() so that the next time size() is called (on the next render) the data will be reloaded properly. With our project we use the size of the data provider to determine component visibility (i.e. 0 rows == is visible) which results in alot more calls of provider.size() but with this caching approach the rendering performance is not impacted. Regards, Mike I was just having a bit of code clean up and I realized that in our IDataProviders we are loading all rows for a given dataset. So looking at the iterator method I see we can limit the result (and the offset). Great I thought - however I see that that the size() method is called as part of the getViewSize() in the AbstractPageableView. Thus I need to call the database here to figure out the size. Am I doing sonething wrong or have I got to hit the database twice for each DataProvider render. Obvously I don't want to hard code a size. Is there any other way ? Thanks Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Organizing Wicket Stuff / Regular Release Schedule?
[X] - YES - I would like to see at least the most used Wicket Stuff projects structured so that they mirror Wicket, and a release is produced for each Wicket release. This should be a no-brainer ;o) -Original Message- From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2008 1:13 PM To: users@wicket.apache.org; Wicket Development Subject: [VOTE] Organizing Wicket Stuff / Regular Release Schedule? Hello everyone, I would like to get your opinion on an idea regarding the Wicket Stuff project(s). As you are familiar with, Wicket Stuff is where anyone can create anything related to Wicket, small or large. One problem that new users of Wicket (and us old users) come across is that there is a lot of stuff in there, and not all of it is well maintained, and there aren't specific releases of many of the projects. So, you have to build it yourself and figure out which version matches which Wicket version, etc... What I would like to know is if everyone thinks it would be good to have a subset of WS projects that are structured in a way that they are always in sync with the Wicket versions. IOW, there would be two branches - 1.3.X and 1.4 (trunk), just like Wicket has. There would be a parent module and all of the modules that wanted to participate would be structured under it. They would all release in sync with Wicket. For instance, when Wicket releases 1.4-RC2, we would cut a release of this wicket-stuff-structured (bad name) and all of the projects under it at 1.4-RC2. I haven't yet figured out how interim releases would work (new features are added to a WS project and it wants to cut a release between wicket releases) or if that matters. This would not have to effect all WS projects - someone could continue to add projects to WS just like they do today. This would simply create a sub-tree of projects that are in the structured / scheduled release area. For those that don't want to be part of that structure, they could continue operating as they do today. So, here's the vote: [ ] - NO! We should leave Wicket Stuff like it is - a free-for-all with no structure [ ] - YES - I would like to see at least the most used Wicket Stuff projects structured so that they mirror Wicket, and a release is produced for each Wicket release. [ ] - Maybe - I have a better idea (perfect!) Also - please add the following: 1 - Would you be interested in helping to maintain such a thing. (If we had two or three of the owners of the larger projects on board, I don't think it would be too hard to keep the codebase of this in sync with Wicket core.) 2 - What projects do you own (and by your vote we'll see if you want those projects to be included in this restructuring). -- Jeremy Thomerson http://www.wickettraining.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Compatibility of objectautocomplete
or you can go with this solution: http://cwiki.apache.org/WICKET/autocomplete-using-a-wicket-model.html -Original Message- From: Nino Saturnino Martinez Vazquez Wael [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2008 6:15 AM To: users@wicket.apache.org Subject: Re: Compatibility of objectautocomplete Hi Kai No it seems Objectautocomplete were added after the branching.. So seems you are a bit out of luck, however backporting should not be too hard.. Kai Mütz wrote: Nino Saturnino Martinez Vazquez Wael wrote: Hi Kai Im not sure if the authors are around.. But the one Objectautocomplet in trunk of stuff are not backwards compatible, that goes for every contrib which depends on wicket 1.4. But there should be a branch with the old version I think, Igor did that a while back the 1.3 branch I mean.. I can not find a 1.3 of objectautocomplete branch at https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/branches /wicke t-1.3.x/ Anywhere else? As for having AutoCompletetextfield along with objectautocompletefield, theres nothing intentionally done for them not to live together but the JS could be clashing(I dont even know if they use the same libs) you'll just have to try and see.. I will try it if I find a 1.3 branch. Thanks, Kai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: inserting javascript from java to html file
or you can use: https://svn.apache.org/repos/asf/wicket/trunk/wicket-velocity/ in which case you could have a separate js/vm file that can inject the values for you: myscript.vm script language=JavaScript function removeBlur(checked) { if(checked) { document.getElementById('${loginButtonId}').disabled = false; } else { document.getElementById('${loginButtonId}').disabled = true; } } /script MyPage.java final MapString, String vars = new HashMapString, String(1); vars.put(loginButtonId, login_button); // should get the login_button id from component.getMarkupId() instead return new VelocityHeaderContributor().add(new VelocityJavascriptContributor(MyPage.class, path/to/myscript.vm, Model.valueOf(vars), nameOfScript)); -Original Message- From: eyalbenamram [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2008 2:45 PM To: users@wicket.apache.org Subject: Re: inserting javascript from java to html file OK. What if I want all the JS to be inline (no .js file to be made)? I saw that wicket created a .js file... igor.vaynberg wrote: response.renderOnLoadJavascript() takes just the javascript - like the javadoc says. no need for you to output the script tags. -igor On Tue, Oct 28, 2008 at 11:33 AM, eyalbenamram [EMAIL PROTECTED] wrote: public void renderHead(IHeaderResponse response) { StringBuffer config = new StringBuffer(); config.append(script language=\JavaScript\\n); config.append(function removeBlur(checked) {\n); config.append(if(checked) {\n); config.append(document.getElementById('login_button').disabled = false;\n); config.append(} else {\n); config.append(document.getElementById('login_button').disabled = true;\n); config.append(} }\n); config.append(/script\n); response.renderOnLoadJavascript(config.toString()); igor.vaynberg wrote: what is your code look like? -igor On Tue, Oct 28, 2008 at 11:28 AM, eyalbenamram [EMAIL PROTECTED] wrote: Hi again, I used IHeaderContributer, and the javascript code is now garbled and not working. Here is what I got: script type=text/javascript src=resources/org.apache.wicket.markup.html.WicketEventReference/w icket-event.js/script script type=text/javascript !--/*--![CDATA[/*!--*/ Wicket.Event.add(window, load, function() { script language=JavaScript function removeBlur(checked) { if(checked) { document.getElementById('login_button').disabled = false; } else { document.getElementById('login_button').disabled = true; } } /script ;}); /*--]]*//script igor.vaynberg wrote: use iheadercontributor, that should work much better also make sure your page has body tag. -igor On Tue, Oct 28, 2008 at 10:57 AM, eyalbenamram [EMAIL PROTECTED] wrote: Hi I am inserting javascript code like this: StringBuffer config = new StringBuffer(); config.append(script language=\JavaScript\\n); config.append(function onLoad() { getValue(); setTimeout(\onRefresh();\,+ns.getAutoRefreshSecs()*1000+); }\n); config.append(function onRefresh(){\n); config.append(document.getElementById('hiddenVar').value = document.getElementById('textString').value;\n); config.append(window.location.reload(); }\n); config.append(function getValue() {\n); config.append(document.getElementById('textString').value = document.getElementById('hiddenVar').value; }\n); config.append(/script\n); /*open to activate JS*/ add(new StringHeaderContributor(config.toString())); and receive an error in log file: http-6789-2 ERROR html.WebPage - ^ http-6789-2 ERROR html.WebPage - You probably forgot to add a body or header tag to your markup since no Header Container was found but components where found which want to write to the head section. script language=JavaScript function removeBlur(checked) { if(checked) { document.getElementById('login_button').disabled = false; } else { document.getElementById('login_button').disabled = true; } } /script although my html file contains a head tag, and the javascript code actually appears in the rendered page (when I look at the source of the page). any idea? Thanks,Eyal. -- View this message in context: http://www.nabble.com/inserting-javascript-from-java-to-html-file -tp20212650p20212650.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Compatibility of objectautocomplete
The CHOICE is your domain model object (there was an error in the WIKI). You should be able to use any object in your domain. Can you post your code example? -Original Message- From: Kai Mütz [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2008 8:57 AM To: users@wicket.apache.org Subject: RE: Compatibility of objectautocomplete Hoover, William mailto:[EMAIL PROTECTED] wrote: or you can go with this solution: http://cwiki.apache.org/WICKET/autocomplete-using-a-wicket-model.html Hi William, I have tried it but not successfully. I can select a choice from the choicelist. But if I want to save it I get a java.lang.IllegalArgumentException: argument type mismatch at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.setValue(Proper tyResolver.java:1093) at org.apache.wicket.util.lang.PropertyResolver$ObjectAndGetSetter.setValue(Pro pertyResolver.java:583) at org.apache.wicket.util.lang.PropertyResolver.setValue(PropertyResolver.java: 137) at org.apache.wicket.model.AbstractPropertyModel.setObject(AbstractPropertyMode l.java:164) at org.apache.wicket.Component.setModelObject(Component.java:2889) This is because the model object seems to be a String. Do I have to use a special IModel for CHOICE? Where is the findChoice methode invoked? Or do I have to invoke it within a behavior? Regards, Kai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Compatibility of objectautocomplete
// optional, but probably needed final AjaxFormComponentUpdatingBehavior afcub = new AjaxFormComponentUpdatingBehavior(onchange) { protected final void onUpdate(final AjaxRequestTarget target) { // TODO : do something } }; // optional final AbstractAutoCompleteRenderer autoCompleteRenderer = new AbstractAutoCompleteRenderer() { protected final String getTextValue(final Object object) { // TODO : get the text value representation of our domain model object } protected final void renderChoice(final Object object, final Response response, final String criteria) { response.write(getTextValue(object)); } }; // required final AbstractAutoCompleteTextFieldMyDomainModelObject autoCompleteField = new AbstractAutoCompleteTextFieldMyDomainModelObject(id, autoCompleteRenderer) { protected final ListMyDomainModelObject getChoiceList(final String searchTextInput) { // TODO : return your choice list } protected final String getChoiceValue(final MyDomainModelObject choice) throws Throwable { // TODO : get the value that will be displayed for the choice in the autocomplete list } }; autoCompleteField.add(afcub); -Original Message- From: Hoover, William [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2008 9:03 AM To: users@wicket.apache.org; [EMAIL PROTECTED] Subject: RE: Compatibility of objectautocomplete The CHOICE is your domain model object (there was an error in the WIKI). You should be able to use any object in your domain. Can you post your code example? -Original Message- From: Kai Mütz [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2008 8:57 AM To: users@wicket.apache.org Subject: RE: Compatibility of objectautocomplete Hoover, William mailto:[EMAIL PROTECTED] wrote: or you can go with this solution: http://cwiki.apache.org/WICKET/autocomplete-using-a-wicket-model.html Hi William, I have tried it but not successfully. I can select a choice from the choicelist. But if I want to save it I get a java.lang.IllegalArgumentException: argument type mismatch at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.setValue(Proper tyResolver.java:1093) at org.apache.wicket.util.lang.PropertyResolver$ObjectAndGetSetter.setValue(Pro pertyResolver.java:583) at org.apache.wicket.util.lang.PropertyResolver.setValue(PropertyResolver.java: 137) at org.apache.wicket.model.AbstractPropertyModel.setObject(AbstractPropertyMode l.java:164) at org.apache.wicket.Component.setModelObject(Component.java:2889) This is because the model object seems to be a String. Do I have to use a special IModel for CHOICE? Where is the findChoice methode invoked? Or do I have to invoke it within a behavior? Regards, Kai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Form model update with ajax using AutoCompleteTextField
or you can use this one- http://cwiki.apache.org/confluence/display/WICKET/Autocomplete+using+a+W icket+model -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Gravener Sent: Monday, October 13, 2008 9:17 AM To: users@wicket.apache.org Subject: Re: Form model update with ajax using AutoCompleteTextField You can search the archives for the answer to this one. Essentially the model object for autocomplete is just a string. On 10/13/08, kerim bey [EMAIL PROTECTED] wrote: Hi! I have problems with using an AutoCompleteText field. Loading the choice Objects works fine, but when I select an entry the ModelObject (using a CompoundPropertyModel) of the Form is not updated. Calling setModelObject() doesn't seem to have any effect. Using a DropDownChoice the same way works. What is missing? -- View this message in context: http://www.nabble.com/Form-model-update-with-ajax-using-AutoCompleteTe xtField-tp19954381p19954381.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ryan Gravener http://twitter.com/ryangravener - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Turning off SWARM for testing?
Try HiveMind.unregisterHive(hiveKey); -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2008 1:56 PM To: users@wicket.apache.org Subject: Re: Turning off SWARM for testing? sorry, i dont know anything about swarm itself. maybe during test you override setuphive() and give it a policy that allows everything and does not require a login. -igor On Thu, Sep 18, 2008 at 10:45 AM, Neil McT [EMAIL PROTECTED] wrote: Sorry not sure what you mean by 'swarm auth strategy' My application class extends SwarmWebApplication and the only SWARM specific methods it overrides are getHiveKey() and setUpHive() - where I add the policy file. Is it one of these that I should be 'nulling out' for testing? Thanks. igor.vaynberg wrote: have an overrideable method on your application boolean issecurityenabled(), and only add swarm auth strategy if it returns true. that way during tests you can give tester a subclass of your app that returns false. -igor -- View this message in context: http://www.nabble.com/Turning-off-SWARM-for-testing--tp19557765p195581 53.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Turning off SWARM for testing?
Yes, the same org.apache.wicket.security.hive.HiveMind used to HiveMind.registerHive(getHiveKey(), factory) the factory in SwarmWebApplication#setUpHive() -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Thursday, September 18, 2008 2:07 PM To: users@wicket.apache.org Subject: Re: Turning off SWARM for testing? HiveMind? On Thu, Sep 18, 2008 at 2:03 PM, Hoover, William [EMAIL PROTECTED] wrote: Try HiveMind.unregisterHive(hiveKey); -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2008 1:56 PM To: users@wicket.apache.org Subject: Re: Turning off SWARM for testing? sorry, i dont know anything about swarm itself. maybe during test you override setuphive() and give it a policy that allows everything and does not require a login. -igor On Thu, Sep 18, 2008 at 10:45 AM, Neil McT [EMAIL PROTECTED] wrote: Sorry not sure what you mean by 'swarm auth strategy' My application class extends SwarmWebApplication and the only SWARM specific methods it overrides are getHiveKey() and setUpHive() - where I add the policy file. Is it one of these that I should be 'nulling out' for testing? Thanks. igor.vaynberg wrote: have an overrideable method on your application boolean issecurityenabled(), and only add swarm auth strategy if it returns true. that way during tests you can give tester a subclass of your app that returns false. -igor -- View this message in context: http://www.nabble.com/Turning-off-SWARM-for-testing--tp19557765p19558 1 53.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Turning off SWARM for testing?
Yeah, really :) the param name in the register method is for the hive key is queen... hmmm... I wonder if any exceptions refer to you getting stung -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Thursday, September 18, 2008 2:24 PM To: users@wicket.apache.org Subject: Re: Turning off SWARM for testing? Way to poach a name! :) On Thu, Sep 18, 2008 at 2:17 PM, Hoover, William [EMAIL PROTECTED] wrote: Yes, the same org.apache.wicket.security.hive.HiveMind used to HiveMind.registerHive(getHiveKey(), factory) the factory in SwarmWebApplication#setUpHive() -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Thursday, September 18, 2008 2:07 PM To: users@wicket.apache.org Subject: Re: Turning off SWARM for testing? HiveMind? On Thu, Sep 18, 2008 at 2:03 PM, Hoover, William [EMAIL PROTECTED] wrote: Try HiveMind.unregisterHive(hiveKey); -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2008 1:56 PM To: users@wicket.apache.org Subject: Re: Turning off SWARM for testing? sorry, i dont know anything about swarm itself. maybe during test you override setuphive() and give it a policy that allows everything and does not require a login. -igor On Thu, Sep 18, 2008 at 10:45 AM, Neil McT [EMAIL PROTECTED] wrote: Sorry not sure what you mean by 'swarm auth strategy' My application class extends SwarmWebApplication and the only SWARM specific methods it overrides are getHiveKey() and setUpHive() - where I add the policy file. Is it one of these that I should be 'nulling out' for testing? Thanks. igor.vaynberg wrote: have an overrideable method on your application boolean issecurityenabled(), and only add swarm auth strategy if it returns true. that way during tests you can give tester a subclass of your app that returns false. -igor -- View this message in context: http://www.nabble.com/Turning-off-SWARM-for-testing--tp19557765p1955 8 1 53.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ListView in Forms
Why do you use propertiesList.setReuseItems(true)? -Original Message- From: Markus Haspl [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 10:20 AM To: users@wicket.apache.org Subject: ListView in Forms hi, first, i'm a very newbie to wicket... I want to add a ListView in a Form. The ListView has two Texfields and one Checkbox each row. When i submit the form the values are still the old ones. here the code: private class InputForm extends Form { IModel pluginPropertiesModel; public InputForm(String id, IPlugin plugin){ super(id); final IPlugin Iplugin = plugin; pluginPropertiesModel = new LoadableDetachableModel(){ public Object load() { log.debug(load the Model); Iplugin.loadPluginProperties(); return pluginProperties; } }; ListView propertiesList = new ListView(pluginRepeater, pluginPropertiesModel) { @Override public void populateItem(ListItem item) { PluginProperties pluginProperties = (PluginProperties)item.getModelObject(); TextField propertiesName = new TextField(name,new Model(pluginProperties.getName())); TextField propertiesValue = new TextField(value,new Model(pluginProperties.getValue())); CheckBox propertiesDefault = new CheckBox(defaultProperty,new Model(pluginProperties.isDefaultProperty())); item.add(propertiesName); item.add(propertiesValue); item.add(propertiesDefault); } }; propertiesList.setReuseItems(true); add(propertiesList); add(new Button(saveButton)); } public void onSubmit() { ListPluginProperties pluginProperties = (ListPluginProperties)pluginPropertiesModel.getObject(); for(PluginProperties property:pluginProperties){ info(+property.getName()+: +property.getValue()+ == +property.isDefaultProperty()); log.debug(+property.getName()+: +property.getValue()+ == +property.isDefaultProperty()); } } } thanks in advance markus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ListView in Forms
If there are errors try setting this strategy on your list view: public class ReuseOnFeedbackMessageStrategy implements IItemReuseStrategy { private static final long serialVersionUID = 1L; private static final int LEVEL_NA = 0; private int feedbackMessageThresholdLevel; private FeedbackMessageLevelComparator feedbackMessageLevelComparator; private int upperThresholdLevel; /** * Constructs a new ReuseOnFeedbackMessageStrategy taking an feedbackMessageLevelComparator that does not require a lower/upper bound threshold level. * * @param feedbackMessageLevelComparator *the [EMAIL PROTECTED] FeedbackMessageLevelComparator} to be used when comparing the active message with the threshold * @param feedbackMessageThresholdLevel *the threshold level to be compared */ public ReuseOnFeedbackMessageStrategy(final FeedbackMessageLevelComparator feedbackMessageLevelComparator, final int feedbackMessageThresholdLevel) { super(); if (feedbackMessageLevelComparator.isLowerAndUpperBoundRequired) { throw new IllegalArgumentException(This feedbackMessageLevelComparator requires a lower/upper bound threshold level and so it is not allowed within this constructor (see javadoc).); } init(feedbackMessageLevelComparator, feedbackMessageThresholdLevel, LEVEL_NA); } /** * Constructs a new ReuseOnFeedbackMessageStrategy. Accepts a feedbackMessageLevelComparator that requires both a lower and upper bound feedback level (typically used with a * [EMAIL PROTECTED] FeedbackMessageLevelComparator#BETWEEN} feedbackMessageLevelComparator). * * @param feedbackMessageLevelComparator *the [EMAIL PROTECTED] FeedbackMessageLevelComparator} to be used when comparing the active message with a lower and upper bound threshold level * @param lowerThresholdLevel *the threshold lower bound feedback message level * @param upperThresholdLevel *the threshold upper bound feedback message level */ public ReuseOnFeedbackMessageStrategy(final FeedbackMessageLevelComparator feedbackMessageLevelComparator, final int lowerThresholdLevel, final int upperThresholdLevel) { super(); if (!feedbackMessageLevelComparator.isLowerAndUpperBoundRequired) { throw new IllegalArgumentException( This feedbackMessageLevelComparator does not require a lower/upper bound threshold level and so it is not allowed within this constructor (see javadoc).); } init(feedbackMessageLevelComparator, lowerThresholdLevel, upperThresholdLevel); } /** * Initialized the ReuseOnFeedbackMessageStrategy. * * @param boundaryOperator *the [EMAIL PROTECTED] FeedbackMessageLevelComparator} to be used when comparing the active message with the threshold * @param lowerBoundThresholdLevel *the threshold lower bound feedback message level or a single threshold for operators that only require one threshold value (i.e. =, , , =, or =) * @param upperBoundThresholdLevel *the threshold upper bound feedback message level */ private final void init(final FeedbackMessageLevelComparator boundaryOperator, final int lowerBoundThresholdLevel, final int upperBoundThresholdLevel) { setFeedbackMessageLevelComparator(boundaryOperator); setFeedbackMessageThresholdLevel(lowerBoundThresholdLevel); setUpperThresholdLevel(upperBoundThresholdLevel); } /** * [EMAIL PROTECTED] */ @SuppressWarnings(unchecked) @Override public final IteratorItem getItems(final IItemFactory factory, final Iterator newModels, final Iterator existingItems) { final ListItem existingItemList = new ArrayListItem(); while (existingItems.hasNext()) { existingItemList.add((Item) existingItems.next()); } return new IteratorItem() { private int index = 0; private transient Boolean hasMessage; /** * [EMAIL PROTECTED] */ @Override public final boolean hasNext() { return newModels.hasNext(); } /** * [EMAIL PROTECTED] */ @Override public final Item next() {
RE: ListView in Forms
That is an issue in itself ;o) -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 1:00 PM To: users@wicket.apache.org Subject: Re: ListView in Forms listviews dont use item reuse strategies... -igor On Wed, Aug 6, 2008 at 9:25 AM, Hoover, William [EMAIL PROTECTED] wrote: If there are errors try setting this strategy on your list view: public class ReuseOnFeedbackMessageStrategy implements IItemReuseStrategy { private static final long serialVersionUID = 1L; private static final int LEVEL_NA = 0; private int feedbackMessageThresholdLevel; private FeedbackMessageLevelComparator feedbackMessageLevelComparator; private int upperThresholdLevel; /** * Constructs a new ReuseOnFeedbackMessageStrategy taking an feedbackMessageLevelComparator that does not require a lower/upper bound threshold level. * * @param feedbackMessageLevelComparator *the [EMAIL PROTECTED] FeedbackMessageLevelComparator} to be used when comparing the active message with the threshold * @param feedbackMessageThresholdLevel *the threshold level to be compared */ public ReuseOnFeedbackMessageStrategy(final FeedbackMessageLevelComparator feedbackMessageLevelComparator, final int feedbackMessageThresholdLevel) { super(); if (feedbackMessageLevelComparator.isLowerAndUpperBoundRequired) { throw new IllegalArgumentException(This feedbackMessageLevelComparator requires a lower/upper bound threshold level and so it is not allowed within this constructor (see javadoc).); } init(feedbackMessageLevelComparator, feedbackMessageThresholdLevel, LEVEL_NA); } /** * Constructs a new ReuseOnFeedbackMessageStrategy. Accepts a feedbackMessageLevelComparator that requires both a lower and upper bound feedback level (typically used with a * [EMAIL PROTECTED] FeedbackMessageLevelComparator#BETWEEN} feedbackMessageLevelComparator). * * @param feedbackMessageLevelComparator *the [EMAIL PROTECTED] FeedbackMessageLevelComparator} to be used when comparing the active message with a lower and upper bound threshold level * @param lowerThresholdLevel *the threshold lower bound feedback message level * @param upperThresholdLevel *the threshold upper bound feedback message level */ public ReuseOnFeedbackMessageStrategy(final FeedbackMessageLevelComparator feedbackMessageLevelComparator, final int lowerThresholdLevel, final int upperThresholdLevel) { super(); if (!feedbackMessageLevelComparator.isLowerAndUpperBoundRequired) { throw new IllegalArgumentException( This feedbackMessageLevelComparator does not require a lower/upper bound threshold level and so it is not allowed within this constructor (see javadoc).); } init(feedbackMessageLevelComparator, lowerThresholdLevel, upperThresholdLevel); } /** * Initialized the ReuseOnFeedbackMessageStrategy. * * @param boundaryOperator *the [EMAIL PROTECTED] FeedbackMessageLevelComparator} to be used when comparing the active message with the threshold * @param lowerBoundThresholdLevel *the threshold lower bound feedback message level or a single threshold for operators that only require one threshold value (i.e. =, , , =, or =) * @param upperBoundThresholdLevel *the threshold upper bound feedback message level */ private final void init(final FeedbackMessageLevelComparator boundaryOperator, final int lowerBoundThresholdLevel, final int upperBoundThresholdLevel) { setFeedbackMessageLevelComparator(boundaryOperator); setFeedbackMessageThresholdLevel(lowerBoundThresholdLevel); setUpperThresholdLevel(upperBoundThresholdLevel); } /** * [EMAIL PROTECTED] */ @SuppressWarnings(unchecked) @Override public final IteratorItem getItems(final IItemFactory factory, final Iterator newModels, final Iterator existingItems) { final ListItem existingItemList = new ArrayListItem(); while (existingItems.hasNext()) { existingItemList.add((Item) existingItems.next()); } return new IteratorItem() { private int index = 0; private transient Boolean hasMessage; /** * [EMAIL PROTECTED
Component#modelChanging and Component#modelChanged when IModel#setObject
Seems strange that Component#modelChanging and Component#modelChanged are never called when IModel#setObject is called... https://issues.apache.org/jira/browse/WICKET-1764 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Component#modelChanging and Component#modelChanged when IModel#setObject
Well, I am still trying to hash that one out- any ideas? I just think that if there is a method that indicates that it will be called anytime that a model is changing that it should follow through with that contract. -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 6:01 PM To: users@wicket.apache.org Subject: Re: Component#modelChanging and Component#modelChanged when IModel#setObject how should we handle that? -igor On Thu, Jul 31, 2008 at 2:43 PM, Hoover, William [EMAIL PROTECTED] wrote: Seems strange that Component#modelChanging and Component#modelChanged are never called when IModel#setObject is called... https://issues.apache.org/jira/browse/WICKET-1764 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Component#modelChanging and Component#modelChanged when IModel#setObject
Yes, it does seem to be a difficult task to accomplish unless the model itself is component aware. Nonetheless, it seems relatively useless to have the onchanging/onchanged methods if they cannot do what they claim they can do- don't you agree? If models were component aware it would simply be a matter of setting the component on the model when Compopnent#setModel is called. Then when IModel#setObject is called it could in turn call Component#modelChanging/modelChanged. This obviously requires a tight coupling relationship between the component and the model, but at least notifications of model object changes can be guaranteed. -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 6:16 PM To: users@wicket.apache.org Subject: Re: Component#modelChanging and Component#modelChanged when IModel#setObject well, it notifies if the model is changed through the component. there is no way for us to really intercept a setobject call on an arbitrary model instance, figure out which components it is currently attached to, and call modelchanging methods on them. -igor On Thu, Jul 31, 2008 at 3:08 PM, Hoover, William [EMAIL PROTECTED] wrote: Well, I am still trying to hash that one out- any ideas? I just think that if there is a method that indicates that it will be called anytime that a model is changing that it should follow through with that contract. -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 6:01 PM To: users@wicket.apache.org Subject: Re: Component#modelChanging and Component#modelChanged when IModel#setObject how should we handle that? -igor On Thu, Jul 31, 2008 at 2:43 PM, Hoover, William [EMAIL PROTECTED] wrote: Seems strange that Component#modelChanging and Component#modelChanged are never called when IModel#setObject is called... https://issues.apache.org/jira/browse/WICKET-1764 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Component#modelChanging and Component#modelChanged when IModel#setObject
That is true... it would require a proxy service in order to intercept the IModel#setObject calls. -Original Message- From: Daniel Freitas [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 7:02 PM To: users@wicket.apache.org Subject: Re: Component#modelChanging and Component#modelChanged when IModel#setObject What would happen if more than one component uses the same model? Would we keep a list of components to notify? If that's the case why not just implement listeners instead, so then any class could listen to model changes. It's a nice idea except that IModel would have to be turned in to a class instead of an interface and that seems more restrictive than not having those methods being called :(. I'm new to Wicket and never needed to use those methods but I guess that making IModel a class and increasing the coupling between model and component is a price too high to pay for it. 2008/7/31 Hoover, William [EMAIL PROTECTED] Yes, it does seem to be a difficult task to accomplish unless the model itself is component aware. Nonetheless, it seems relatively useless to have the onchanging/onchanged methods if they cannot do what they claim they can do- don't you agree? If models were component aware it would simply be a matter of setting the component on the model when Compopnent#setModel is called. Then when IModel#setObject is called it could in turn call Component#modelChanging/modelChanged. This obviously requires a tight coupling relationship between the component and the model, but at least notifications of model object changes can be guaranteed. -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 6:16 PM To: users@wicket.apache.org Subject: Re: Component#modelChanging and Component#modelChanged when IModel#setObject well, it notifies if the model is changed through the component. there is no way for us to really intercept a setobject call on an arbitrary model instance, figure out which components it is currently attached to, and call modelchanging methods on them. -igor On Thu, Jul 31, 2008 at 3:08 PM, Hoover, William [EMAIL PROTECTED] wrote: Well, I am still trying to hash that one out- any ideas? I just think that if there is a method that indicates that it will be called anytime that a model is changing that it should follow through with that contract. -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 6:01 PM To: users@wicket.apache.org Subject: Re: Component#modelChanging and Component#modelChanged when IModel#setObject how should we handle that? -igor On Thu, Jul 31, 2008 at 2:43 PM, Hoover, William [EMAIL PROTECTED] wrote: Seems strange that Component#modelChanging and Component#modelChanged are never called when IModel#setObject is called... https://issues.apache.org/jira/browse/WICKET-1764 --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Conditional Form Validation
What about formComponent.processInput() -Original Message- From: Ritesh Trivedi [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 12:52 PM To: users@wicket.apache.org Subject: Conditional Form Validation Hi, I am trying to implement conditional form validation according to the wiki artcle http://cwiki.apache.org/WICKET/conditional-validation.html Seems like one has to manually call updateFormComponentModels() to update the form model which is not mentioned in the wiki which is fine, but the problem is updateFormComponentModels() is protected method, so it cannot be called from button's onSubmit() method. Am I missing anything? -- View this message in context: http://www.nabble.com/Conditional-Form-Validation-tp18737747p18737747.ht ml Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to get the remote address (IP)
did you try getRequestCycleSettings().setGatherExtendedBrowserInfo(true); in your WebApplication? -Original Message- From: Kaspar Fischer [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2008 6:35 AM To: users@wicket.apache.org Subject: How to get the remote address (IP) I try to obtain the client's remote address from the session: WebClientInfo info = (WebClientInfo) session.getClientInfo(); final String remoteAddress = info.getProperties().getRemoteAddress(); This results in 0:0:0:0:0:0:0:1%0. Any idea what might be wrong? Thanks a lot, Kaspar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AutocompleteTextField
A simple solution is to hold on to the actual choices list until you can match the selection: public abstract class AbstractAutoCompleteTextFieldCHOICE extends TextField { private static final Logger LOG = LoggerFactory.getLogger(AbstractAutoCompleteTextField.class); private static final long serialVersionUID = 1L; private final AutoCompleteChoiceBehavior autoCompleteBehavior; private transient ListCHOICE choiceList; /** * Constructor * * @param id *the ID to set * @param type *the type to set */ public AbstractAutoCompleteTextField(final String id, final Class? type) { this(id, (IModel) null, type, false); } /** * Constructor * * @param id *the ID to set * @param model *the model to set * @param type *the type to set * @param preselect *the preselect to set */ public AbstractAutoCompleteTextField(final String id, final IModel model, final Class? type, final boolean preselect) { this(id, model, type, StringAutoCompleteRenderer.INSTANCE, preselect); } /** * Constructor * * @param id *the ID to set * @param model *the model to set * @param type *the type to set * @param settings *the settings to set */ public AbstractAutoCompleteTextField(final String id, final IModel model, final Class? type, final AutoCompleteSettings settings) { this(id, model, type, StringAutoCompleteRenderer.INSTANCE, settings); } /** * Constructor * * @param id *the ID to set * @param model *the model to set * @param preselect *the preselect to set */ public AbstractAutoCompleteTextField(final String id, final IModel model, final boolean preselect) { this(id, model, (Class?) null, preselect); } /** * Constructor * * @param id *the ID to set * @param model *the model to set * @param settings *the settings to set */ public AbstractAutoCompleteTextField(final String id, final IModel model, final AutoCompleteSettings settings) { this(id, model, (Class?) null, settings); } /** * Constructor * * @param id *the ID to set * @param model *the model to set */ public AbstractAutoCompleteTextField(final String id, final IModel model) { this(id, model, (Class?) null, false); } /** * Constructor * * @param id *the ID to set * @param preselect *the preselect to set */ public AbstractAutoCompleteTextField(final String id, final boolean preselect) { this(id, (IModel) null, preselect); } /** * Constructor * * @param id *the ID to set * @param settings *the settings to set */ public AbstractAutoCompleteTextField(final String id, final AutoCompleteSettings settings) { this(id, (IModel) null, settings); } /** * Constructor * * @param id *the ID to set */ public AbstractAutoCompleteTextField(final String id) { this(id, (IModel) null, false); } /** * Constructor * * @param id *the ID to set * @param renderer *the renderer to set */ public AbstractAutoCompleteTextField(final String id, final IAutoCompleteRenderer renderer) { this(id, (IModel) null, renderer); } /** * Constructor * * @param id *the ID to set * @param type *the type to set * @param renderer *the renderer to set */ public AbstractAutoCompleteTextField(final String id, final Class? type, final IAutoCompleteRenderer renderer) { this(id, null, type, renderer, false); } /** * Constructor * * @param id *the ID to set * @param model *the model to set * @param renderer *the renderer
Possible AbstractAjaxBehavior Bug
I am using a behavior that is dynamically added/removed from a TextField based upon another components state (in order to avoid extra round trips to the server): final AjaxFormComponentUpdatingBehavior afcub = ... final TextField textField = new TextField(some-id, new Model()){ protected final void onBeforeRender() { boolean hasBehavior = false; for (final IBehavior b : (ListIBehavior) component.getBehaviors()) { if (b.equals(behavior)) { hasBehavior = true; break; } } // is add flag is captured by another components conditions to avoid server round-trips if (isAddFlag !hasBehavior) { add(afcub); } else if(!isAddFlag hasBehavior) { remove(afcub); } super.onBeforeRender(); } } Using the code above I get an IllegalStateException when the AjaxFormComponentUpdatingBehavior is added, then removed, and added again (all based on user interaction of course). In AbstractAjaxBehavoir there is a method that does a (component != null) check... shouldn't that check be (component != null !(component.equals(hostComponent))) to avoid this type of scenario? public final void bind(final Component hostComponent) { if (hostComponent == null) { throw new IllegalArgumentException(Argument hostComponent must be not null); } if (component != null) { throw new IllegalStateException(this kind of handler cannot be attached to + multiple components; it is already attached to component + component + , but component + hostComponent + wants to be attached too); } component = hostComponent; // call the callback onBind(); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Contextual autoCompleteTextField
can you post the code? -Original Message- From: Bertrand DATAS [mailto:[EMAIL PROTECTED] Sent: Friday, June 27, 2008 11:00 AM To: users@wicket.apache.org Subject: Re: Contextual autoCompleteTextField in fact i have a problem with that because i am using the listview(which you called yourView) during her contruction that is to say the populmate item. so java told me that object may not be initialized. This is because my AutoCompleteTextField is generated like the others. so i can use this code in my AutocompleteTextField. Really, I don't know how to make the behavior I want. 2008/6/25 Bertrand DATAS [EMAIL PROTECTED]: Ok I will try that but I am not sure that model object will be updated with the new data entered by the when I want to populate the list of my AutoCompleteTextField. Oh may be i can update it in the onChange of all my fields (this will add network traffic but i don't know how to make it better). 2008/6/25 Hoover, William [EMAIL PROTECTED]: If you need the components: final ListFormComponent yourViewFormComponents = new ArrayListFormComponent(); final IteratorWebMarkupContainer items = yourView.iterator(); if (items != null) { while (items.hasNext()) { items.next().visitChildren(new Component.IVisitor() { public final Object component(final Component component) { if (component instanceof FormComponent) { yourViewFormComponents.add((FormComponent) component); } return CONTINUE_TRAVERSAL; } }); } } If you only need the model objects: final ListYourModelObject yourViewModelObjects = new ArrayListYourModelObject(); final IteratorWebMarkupContainer items = yourView.iterator(); if (items != null) { while (items.hasNext()) { yourViewModelObjects.add((YourModelObject) items.next().getModelObject()); } } -Original Message- From: Bertrand DATAS [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2008 10:25 AM To: users@wicket.apache.org Subject: Re: Contextual autoCompleteTextField yes i could do like that but my field are generated in a listview so how can I retrieve them ?? 2008/6/25 Hoover, William [EMAIL PROTECTED]: What is stopping you from using the models from the other fields when constructing your list? -Original Message- From: Bertrand DATAS [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2008 8:05 AM To: users@wicket.apache.org Subject: Re: Contextual autoCompleteTextField Not really because i dont want to use the onselect of this component but to use the content of two other fields to construct the list that will be displayed in my AutoCompleteTextField. 2008/6/25 Hoover, William [EMAIL PROTECTED]: Are you referring to something like http://issues.apache.org/jira/browse/WICKET-488? -Original Message- From: Bertrand DATAS [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2008 4:21 AM To: users@wicket.apache.org Subject: Contextual autoCompleteTextField Hello everybody, Do you know if there is a way to make contextual the list of autocompletTextfield that is to say to make it relative to other fields that are in the form ? Actually i have two Fields, Town and ZipCode and when there are filled, my autoCompleteTextField must display the list of the streets available for this Town and ZipCode. Do you have any trick for making this ?? Thanks Bertrand Datas - --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Contextual autoCompleteTextField
Are you referring to something like http://issues.apache.org/jira/browse/WICKET-488? -Original Message- From: Bertrand DATAS [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2008 4:21 AM To: users@wicket.apache.org Subject: Contextual autoCompleteTextField Hello everybody, Do you know if there is a way to make contextual the list of autocompletTextfield that is to say to make it relative to other fields that are in the form ? Actually i have two Fields, Town and ZipCode and when there are filled, my autoCompleteTextField must display the list of the streets available for this Town and ZipCode. Do you have any trick for making this ?? Thanks Bertrand Datas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Contextual autoCompleteTextField
What is stopping you from using the models from the other fields when constructing your list? -Original Message- From: Bertrand DATAS [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2008 8:05 AM To: users@wicket.apache.org Subject: Re: Contextual autoCompleteTextField Not really because i dont want to use the onselect of this component but to use the content of two other fields to construct the list that will be displayed in my AutoCompleteTextField. 2008/6/25 Hoover, William [EMAIL PROTECTED]: Are you referring to something like http://issues.apache.org/jira/browse/WICKET-488? -Original Message- From: Bertrand DATAS [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2008 4:21 AM To: users@wicket.apache.org Subject: Contextual autoCompleteTextField Hello everybody, Do you know if there is a way to make contextual the list of autocompletTextfield that is to say to make it relative to other fields that are in the form ? Actually i have two Fields, Town and ZipCode and when there are filled, my autoCompleteTextField must display the list of the streets available for this Town and ZipCode. Do you have any trick for making this ?? Thanks Bertrand Datas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Contextual autoCompleteTextField
If you need the components: final ListFormComponent yourViewFormComponents = new ArrayListFormComponent(); final IteratorWebMarkupContainer items = yourView.iterator(); if (items != null) { while (items.hasNext()) { items.next().visitChildren(new Component.IVisitor() { public final Object component(final Component component) { if (component instanceof FormComponent) { yourViewFormComponents.add((FormComponent) component); } return CONTINUE_TRAVERSAL; } }); } } If you only need the model objects: final ListYourModelObject yourViewModelObjects = new ArrayListYourModelObject(); final IteratorWebMarkupContainer items = yourView.iterator(); if (items != null) { while (items.hasNext()) { yourViewModelObjects.add((YourModelObject) items.next().getModelObject()); } } -Original Message- From: Bertrand DATAS [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2008 10:25 AM To: users@wicket.apache.org Subject: Re: Contextual autoCompleteTextField yes i could do like that but my field are generated in a listview so how can I retrieve them ?? 2008/6/25 Hoover, William [EMAIL PROTECTED]: What is stopping you from using the models from the other fields when constructing your list? -Original Message- From: Bertrand DATAS [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2008 8:05 AM To: users@wicket.apache.org Subject: Re: Contextual autoCompleteTextField Not really because i dont want to use the onselect of this component but to use the content of two other fields to construct the list that will be displayed in my AutoCompleteTextField. 2008/6/25 Hoover, William [EMAIL PROTECTED]: Are you referring to something like http://issues.apache.org/jira/browse/WICKET-488? -Original Message- From: Bertrand DATAS [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2008 4:21 AM To: users@wicket.apache.org Subject: Contextual autoCompleteTextField Hello everybody, Do you know if there is a way to make contextual the list of autocompletTextfield that is to say to make it relative to other fields that are in the form ? Actually i have two Fields, Town and ZipCode and when there are filled, my autoCompleteTextField must display the list of the streets available for this Town and ZipCode. Do you have any trick for making this ?? Thanks Bertrand Datas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to get context path
It would be better if ContextImage was a behavior rather than an actual component. For instance, if you have an html input of type=image (or a link for that matter) you can still utilize the behavior whereas a component you cannot ;o) -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 3:29 PM To: users@wicket.apache.org Subject: Re: How to get context path see ContextImage -igor On Wed, Jun 11, 2008 at 12:10 PM, Patel, Sanjay [EMAIL PROTECTED] wrote: Hi, my images in the application are in webapp/image folder. How to get Context Path in wicket so I can prepend this path to display the image. I am looking for something like this. getContextPath() + image/icon.gif; Please suggest how to do that. Thanks, Sanjay. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to get context path
Done: https://issues.apache.org/jira/browse/WICKET-1700 -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 11:32 AM To: users@wicket.apache.org Subject: Re: How to get context path jira is your friend -igor On Thu, Jun 12, 2008 at 4:46 AM, Hoover, William [EMAIL PROTECTED] wrote: It would be better if ContextImage was a behavior rather than an actual component. For instance, if you have an html input of type=image (or a link for that matter) you can still utilize the behavior whereas a component you cannot ;o) -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 3:29 PM To: users@wicket.apache.org Subject: Re: How to get context path see ContextImage -igor On Wed, Jun 11, 2008 at 12:10 PM, Patel, Sanjay [EMAIL PROTECTED] wrote: Hi, my images in the application are in webapp/image folder. How to get Context Path in wicket so I can prepend this path to display the image. I am looking for something like this. getContextPath() + image/icon.gif; Please suggest how to do that. Thanks, Sanjay. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
In java 1.7 it will allow: TextFieldStirng tf = new TextField(id); So, at least one of your wishes will come true ;o) I like the default idea. -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 4:15 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket If only... if only we had this construct: class ComponentT default Void { } then all our problems with verbosity would be gone.. TextField tf = new TextField(id) // just default Void Also only declare it once: TextFieldStirng tf = new TextField(id); And both ways type guessing, so TextFieldString tf = new TextField(id, new Model()); //textfield and model are both just String or TextField tf = new TextField(id, new ModelString()); // text field gets the type of its given model.. I guess we should make a feature request for sun and then Vote on it with all of us! (and make noise on the internet...) johan On Tue, Jun 3, 2008 at 8:58 AM, Marcus Mattila [EMAIL PROTECTED] wrote: generics for formcomponents do not make sense, most of the time they can figure out the type by inspecting their model. further, generics did not get rid of the need to specify the type as a constructor argument: new TextFieldInteger(num, Integer.class) Agreed. +1 for NOT generifying everything, because most components are set it and forget it = generifying everything is unnecessary clutter. I will continue to use Wicket whatever is decided, though :) -Marcus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Look in the section Laguage Proposals Shorter Instance Creations in: http://blogs.sun.com/dannycoward/resource/Java7Overview_Prague_JUG.pdf Other useful links: http://blogs.sun.com/ahe/resource/java-se-7-EclipseCon-2007.pdf http://puredanger.com/techfiles/java7.pdf -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 7:47 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket really? i still cant find information what will really be 1.7.. On Tue, Jun 3, 2008 at 1:29 PM, Hoover, William [EMAIL PROTECTED] wrote: In java 1.7 it will allow: TextFieldStirng tf = new TextField(id); So, at least one of your wishes will come true ;o) I like the default idea. -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 4:15 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket If only... if only we had this construct: class ComponentT default Void { } then all our problems with verbosity would be gone.. TextField tf = new TextField(id) // just default Void Also only declare it once: TextFieldStirng tf = new TextField(id); And both ways type guessing, so TextFieldString tf = new TextField(id, new Model()); //textfield and model are both just String or TextField tf = new TextField(id, new ModelString()); // text field gets the type of its given model.. I guess we should make a feature request for sun and then Vote on it with all of us! (and make noise on the internet...) johan On Tue, Jun 3, 2008 at 8:58 AM, Marcus Mattila [EMAIL PROTECTED] wrote: generics for formcomponents do not make sense, most of the time they can figure out the type by inspecting their model. further, generics did not get rid of the need to specify the type as a constructor argument: new TextFieldInteger(num, Integer.class) Agreed. +1 for NOT generifying everything, because most components are set +it and forget it = generifying everything is unnecessary clutter. I will continue to use Wicket whatever is decided, though :) -Marcus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. Verbose VS Clarity, Clarity wins hands down. 2) How strongly do you feel about your choice above? [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. -Original Message- From: Eelco Hillenius [mailto:[EMAIL PROTECTED] Sent: Sunday, June 01, 2008 4:45 PM To: wicket user list Subject: users, please give us your opinion: what is your take on generics with Wicket Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [ ] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Goes to show you that people have a tendency to reject things that they do not understand rather than put in the effort :o) -Original Message- From: richardwilko [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:21 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket ok maybe i misread this : 'Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking.' but those 2 sentences seem to contradict each other, the first says only generify IModel which I assumed ti mean that when you put a String into a model you would get a String out of it, the second seems to says generifiying components to make them only accept some model types. So just to clarify my position generic models which would do away with this type of casting: protected void onSubmit(AjaxRequestTarget target, Form form) { EmailFormModel emailFormModel = (EmailFormModel) form.getModelObject(); is what I would like to see. generic components im not bothered about. if using generics wont do away with the casting then I dont see any point to using them at all. Johan Compagner wrote: why are you contradicting yourself? To be honest I don't see the advantage of generic components, all I want is to not have to do casting when I'm using models, .getModelObject() should return the type that I put in, in a list view, if I give it a list of strings I dont want to cast the listItem model object to a string. if you have just IModel then you will have to cast.. getModelObject will always return just Object then. ok maybe i misread about: new TextArea(...).add(some behavior).setRequired(true) this can be done but then we have to override some methods of component and then return another type The problem is that this could result in us lifting a final where we dont want to.. But this is outside the scope of generics johan On Mon, Jun 2, 2008 at 3:26 PM, richardwilko [EMAIL PROTECTED] wrote: [ x ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [ x ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. To be honest I don't see the advantage of generic components, all I want is to not have to do casting when I'm using models, .getModelObject() should return the type that I put in, in a list view, if I give it a list of strings I dont want to cast the listItem model object to a string. It would also be nice if the .add() and others methods on components could return the type of component it is rather than just a Component object. eg you cant do 'new TextArea(...).add(some behavior).setRequired(true) because the add behaviour method returns a Component not a TextArea and setRequired is not available on Components. Thanks -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is -your-take-on-generics-with-Wicket-tp17589984p17601296.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo ur-take-on-generics-with-Wicket-tp17589984p17602507.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
+1 -Original Message- From: Brill Pappin [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:49 AM To: users@wicket.apache.org Subject: RE: users, please give us your opinion: what is your take on generics with Wicket I don't know, I think the discussion is going *toward* generics. Frankly I can't even see why its an issue at all, the language has evolved and uses them... Why would Wicket not also use them its inline with the current state of the language? There is no reason that people who can't get their heads around Generics can't use the older releases that don't include it, but IMO any java developer who doesn't get generics yet better make some time to learn, because like it or not, they *will* be dealing with them. - Brill Pappin -Original Message- From: Matej Knopp [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:46 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. Also If i had to decide between new WebMarkupContainerVoid and new WebMarkupContainer where the later wouldn't be generified I'd certainly go for the Void alternative. -Matej On Sun, Jun 1, 2008 at 10:44 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [ ] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
+1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 10:56 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
I see your point... a referendum will only be as good as the current state of the product that is being evaluated, and the expertise of those doing the evaluation. It seems as though in this case that some of those doing the evaluation have limited knowledge of what benefits generics has to offer (and obviously the state of the product is incomplete- so a released version is not what's being evaluated). -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:32 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket yes thats why i am against Referendums (politically) :) On Mon, Jun 2, 2008 at 4:27 PM, Hoover, William [EMAIL PROTECTED] wrote: Goes to show you that people have a tendency to reject things that they do not understand rather than put in the effort :o) -Original Message- From: richardwilko [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:21 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket ok maybe i misread this : 'Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking.' but those 2 sentences seem to contradict each other, the first says only generify IModel which I assumed ti mean that when you put a String into a model you would get a String out of it, the second seems to says generifiying components to make them only accept some model types. So just to clarify my position generic models which would do away with this type of casting: protected void onSubmit(AjaxRequestTarget target, Form form) { EmailFormModel emailFormModel = (EmailFormModel) form.getModelObject(); is what I would like to see. generic components im not bothered about. if using generics wont do away with the casting then I dont see any point to using them at all. Johan Compagner wrote: why are you contradicting yourself? To be honest I don't see the advantage of generic components, all I want is to not have to do casting when I'm using models, .getModelObject() should return the type that I put in, in a list view, if I give it a list of strings I dont want to cast the listItem model object to a string. if you have just IModel then you will have to cast.. getModelObject will always return just Object then. ok maybe i misread about: new TextArea(...).add(some behavior).setRequired(true) this can be done but then we have to override some methods of component and then return another type The problem is that this could result in us lifting a final where we dont want to.. But this is outside the scope of generics johan On Mon, Jun 2, 2008 at 3:26 PM, richardwilko [EMAIL PROTECTED] wrote: [ x ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [ x ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. To be honest I don't see the advantage of generic components, all I want is to not have to do casting when I'm using models, .getModelObject() should return the type that I put in, in a list view, if I give it a list of strings I dont want to cast the listItem model object to a string. It would also be nice if the .add() and others methods on components could return the type of component it is rather than just a Component object. eg you cant do 'new TextArea(...).add(some behavior).setRequired(true) because the add behaviour method returns a Component not a TextArea and setRequired is not available on Components. Thanks -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what- is -your-take-on-generics-with-Wicket-tp17589984p17601296.html Sent from the Wicket - User mailing list archive at Nabble.com. --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is- yo ur-take-on-generics-with-Wicket-tp17589984p17602507.htmlhttp://www.na bble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on- generics-with-Wicket-tp17589984p17602507.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
RE: users, please give us your opinion: what is your take on generics with Wicket
Ahhh... there's a good starting point for the gotchas... I agree. It is not a big issue to use Void when needed. I doubt anyone would be using something like Class? extends Page? extends IModelT unless they themselves are attempting to extend a generic component that they want to extend its generic capabilities. Anyone that doesn't want to use the complete generic signature does not have to (MyPage extends PageSomeModel and Class? extends MyPage or ClassMyPage). That's the nice thing... It's up to the user. -Original Message- From: Scott Swank [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:11 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Agreed. I don't see a problem with having to type LinkVoid or PageVoid instead of Link/Page. That's simply the way that generics are implemented in Java. Are there places in the API where an end user would have to type something like Class? extends Page? extends IModelT? That way madness lies, however I haven't seen anything like that in 1.4M1 (I'll let you know about M2 later today). So unless I'm missing something pretty beafy, which I don't see here: http://cwiki.apache.org/WICKET/generics.html I just don't see the problem with the current direction. Cheers, Scott On Mon, Jun 2, 2008 at 8:03 AM, Hoover, William [EMAIL PROTECTED] wrote: +1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Sounds like a good idea... Are you going to create it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 11:06 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Why don't we use the Wiki page to list our *specific* gotchas we encounter and try to come up with a solution for them. My guess is that we can do so. On Mon, Jun 2, 2008 at 11:03 AM, Hoover, William [EMAIL PROTECTED] wrote: +1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 10:56 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Good question... I would add to that and say: how many of those users actually use generified wicket on day-to-day basis? how many of those users actually implement generics on day-to-day basis (not just using them- like ListMyClass)? -Original Message- From: Matej Knopp [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:28 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 2, 2008 at 5:22 PM, Jan Kriesten [EMAIL PROTECTED] wrote: Hi, I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. @matej_k: ugh - you should count again... if I counted right, most of the responses yet prefer 'Component' /not/ being touched by generics. Question is, how many of those users actually use generified wicket on day-to-day basis. -Matej +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. @jwcarman: There is an issue with generics on components which is leading into a big mess - and as far as I can see, many objections are especially on that topic! It might not be Wicket's fault, though, it might be a language problem (i.e. Java's to blame). But IMHO putting generics on Component is a bad design, since it per se touches all of Wicket's Components without urgent need. Boilerplate over and over. If I look at my components and libraries (and yes, i have tried out 1.4!) - I have at most 30% of my components containing a Model! Best regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
If you use more than one type of model for a given component I would hardly say that it is only a fraction of the time. Do you use only one type of model on all your components? :o) The use of Void is not an obscure workaround. Why do you think they have it? I think it's intent is very clear if you understand what void represents. The key point is that Java generics are not runtime generics ;o) -Original Message- From: Jan Kriesten [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:37 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Hi Matej, Question is, how many of those users actually use generified wicket on day-to-day basis. well, I did, and it really doesn't looked nice (and it doesn't work as it should in the end, but that's another story). The main point is (repeatedly) ignored by the people who are 'pro' generics: Why do you have to put generics on Components, when need is only in a fraction of cases? Discussing the possibility of Void is somewhat an obscure workaround. It's just boilerplate in more than 70% (of my cases), and this boilerplate gets repeated over and over again with each assignment. Best regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
I read it, but I think most people will be using models more frequently than 30% of the time. Personally, I use them 99% of the time. -Original Message- From: Jan Kriesten [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:54 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Hi William, If you use more than one type of model for a given component I would hardly say that it is only a fraction of the time. Do you use only one type of model on all your components? :o) read again - I said 70% of my components don't have a Model... The use of Void is not an obscure workaround. Why do you think they have it? I think it's intent is very clear if you understand what void represents. The key point is that Java generics are not runtime generics ;o) See above, the point is having Void in there for especially nothing to gain - Just make reading harder and each assignment even longer... Regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Enlighten me with an example -Original Message- From: Jan Kriesten [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 12:23 PM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket hi william, Wouldn't that infer that the component has to have generics, or am I missing something here? you miss something... getModel/getModelObject would have to be non-final and overriden by the specialized component (return types are covariant, so you can override object with something more specific). regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Then we are on the same page with one thing... some level in the component hierarchy would have to be generic. Your original example specified T getModel() - you must have meant T getModelObject() ;o) -Original Message- From: Jan Kriesten [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 12:34 PM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket hi william, Enlighten me with an example just like that: Component { public object getModelObject(){ ... } } FormComponentT extends Component { public T getModelObject() { ... } } regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Wouldn't that infer that the component has to have generics, or am I missing something here? Something like... public abstract class ComponentM extends IModelT, T implements IClusterable, IConverterLocator { ... public final M getModel(){ ... } ... public final T getModelObject(){ ... } ... } -Original Message- From: Jan Kriesten [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 12:03 PM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Hi Sebastian, What about getModel()? If componennt is not generified I'm really wondering if the there is any benefit to generics at all... (I do really think it will spawn lots of questions on the list as well). what's the problem with getModel? If you specialize on a certain Component, you can implement T getModel() ? Regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Wow, last time I checked CompoundPropertyModel is a model ;o) -Original Message- From: John Krasnay [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 1:22 PM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 02, 2008 at 11:59:09AM -0400, Hoover, William wrote: I read it, but I think most people will be using models more frequently than 30% of the time. Personally, I use them 99% of the time. Really? Haven't you heard of CompoundPropertyModel? jk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
I got the point, but I take things as people state them. It was stated that 70% of the time models are not being used (such is the case for LinkVoid). As you stated, they are being used indirectly. That is different. If that is the case then I agree that the percentage of components using model indirectly would be reduced for form-heavy applications (as you stated). On the contrary, a lot of applications are not form-heavy (i.e. Ajax heavy apps, etc.) which also need to be accounted for in the figures. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Maw Sent: Monday, June 02, 2008 2:09 PM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket I think you miss John's point, which is that when you use a CompoundPropertyModel for a component, all its children typically do not reference models explicitly. Thus you typically use an explicit model on 30% of your components if you have a form-heavy web-app; the other components use the implicit model provided by the parent's CompoundPropertyModel. Regards, Al On Mon, Jun 2, 2008 at 6:42 PM, Hoover, William [EMAIL PROTECTED] wrote: Wow, last time I checked CompoundPropertyModel is a model ;o) -Original Message- From: John Krasnay [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 1:22 PM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 02, 2008 at 11:59:09AM -0400, Hoover, William wrote: I read it, but I think most people will be using models more frequently than 30% of the time. Personally, I use them 99% of the time. Really? Haven't you heard of CompoundPropertyModel? jk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: (Class? extends Page?) casting troubles
+1 This seems to be the best option so far. It's confusing to see a bunch of subclasses whose only purpose is to avoid generic type definitions. A separate dependency makes sense. If anyone is that concerned with having to define void generic types they can add the dependency. -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Saturday, May 24, 2008 10:51 AM To: users@wicket.apache.org Subject: Re: (Class? extends Page?) casting troubles thats funny, my primary usecase is to use link WITH a model. so why dont we keep Link generified and have a subclass VoidLink. i am also not a big fan of using class hierarchy essentially as a typedef, seems like a nasty hack to me (which i am willing to live with). perhaps we can have wicket-void module that can contain all these Void subclasses. -igor On Sat, May 24, 2008 at 2:24 AM, Johan Compagner [EMAIL PROTECTED] wrote: +1 On Sat, May 24, 2008 at 8:09 AM, Daniel Walmsley [EMAIL PROTECTED] wrote: Just to quickly weigh in on the verbosity argument: As someone who has coded Java (and Perl, C++, etc) in every environment from individual projects to multinational finance systems, I will say that verbosity of code runs a far, far, distant third (or twentieth) to: 1. Readability/Understandability, and 2. Maintainability By illustrating succinctly what type of model (if any) a component will contain, generics in Wicket neatly accomplish point 1. By allowing your IDE to tell you when you're setting the wrong type of model object in a component it neatly accomplishes point 2. You write your code once. You maintain it thousands of times. The trade-off to me is perfectly clear, and this will be vindicated when Wicket-based enterprise projects start conspicuously succeeding where others have failed. Also, don't mistake verbosity for DRY-ness. COBOL was verbose because it forced you to repeat yourself over and over. Java supports very elegant reuse, so each piece of functionality is written just once. Thanks to Annotations we've cut down (significantly) on boilerplate, and the whole appeal of Wicket is its ability to enable reuse at the web tier. Between generics, annotations and component reuse, this makes Wicket a very DRY-friendly framework, and has vastly reduced the amount of code I've had to cut for my clients. I've used every framework under the sun (no pun intended) and Wicket rules over them all. Cheers, Dan On 22/05/2008, at 07:20AM, Jonathan Locke wrote: I'm jumping into this conversation very late and I simply can't catch up on this entire thread, but isn't it possible to have a non-generic build of the generic framework for people that don't want to use generics? Skimming this discussion, in general, I tend to agree with Eelco. A good general approach would be to fully generify the framework and then vote to back out the things which are really not helpful (for example, although page is technically a component, pages often have no models, so it might be a good thing to a un-generify). Once we have found a practical/optimal level of generification should we vote on it. Let's not throw the baby out with the bathwater. Also, for myself, I disagree that type safety is not a primary goal of generics. Even if the API were completely clear already, I'd still prefer more type safety. Martijn Dashorst wrote: On Wed, May 21, 2008 at 5:05 PM, Johan Compagner [EMAIL PROTECTED] wrote: Generics is type safety I didn't say generics isn't type safety. But APPLYING generics for the Wicket framework API *ISN'T* its primary goal. API clarity *IS*. Less questions on the mailing list regarding DDC, ListView, etc. is the main goal for applying generics in Wicket. I am against this abuse big time -1000 from me I'm -1000^1 for abusing my eyes and brain in the way it currently is implemented in Wicket. It is completely and utterly unusable for beginners. There is no way this is going to make the number of questions on the mailinglist less (other than by scaring away anyone that wants to actually use the framework) Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting -troubles-tp17355847p17375350.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Daniel Walmsley Director, Firesyde e: [EMAIL PROTECTED] m: +61404864141 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Providing IModel to Validators
done: https://issues.apache.org/jira/browse/WICKET-1654 -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 8:10 PM To: users@wicket.apache.org Subject: Re: Providing IModel to Validators ah, i see. so the model for the validator overrides the message completely? i have already built in a support for this into the core api via IValidationError. the problem is that our validator implementations are based around resource keys, and changing that will probably entail api breakages which we cannot have in a 1.3 release. enter an rfe and we can refactor this stuff for 1.4/1.5 -igor On Wed, May 21, 2008 at 5:00 PM, Hoover, William [EMAIL PROTECTED] wrote: A column attribute, or any other attribute for that matter, would not make a difference because if would all be encapsulated within the model set on the validator (use case 6 below). Providing models to the validators would make it a lot easier to override validation messages because all the developer would have to do is set the model on it (vs looking up the resource key and add it to the components properties file). I can see that this is receiving some strong resistance so I wont push the issue any further :o) == Use Case 6: StringResourceModel srm = new StringResourceModel(CustomStringValidator.minimum, null, null, new Object[]{ rowIndex, columnIndex }); add(new textfield(fname).setlabel(new model(first name)).add(stringvalidator.minimum(5, srm)); results in- 'first name' with value 'abc' at row 10, column 3 is shorter than the minimum of 5 characters. == -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 3:07 PM To: users@wicket.apache.org Subject: Re: Providing IModel to Validators and what happens when someone wants ${label} at row {0} column {1} is required? do we start passing in arrays, lists, or maps for imodels to validators? why not just do textfield.setlabel(new model(first name at row +row)); -igor On Wed, May 21, 2008 at 4:52 AM, Hoover, William [EMAIL PROTECTED] wrote: What I'm proposing would not require the same first name model on both validators. I might not have been clear enough in my explanation... StringValidator.minimum='${label}' with value '${input}' is shorter than the minimum of ${minimum} characters. CustomStringValidator.minimum='${label}' with value '${input}' at row {0} is shorter than the minimum of ${minimum} characters. MyUsernameValidator.unique='${label}' with value '${input}' at row {0} is not unique. == Use Case 1: add(new textfield(fname).add(stringvalidator.minimum(5)); results in- 'fNameId' with value 'abc' is shorter than the minimum of 5 characters. == Use Case 2: add(new textfield(fname).setlabel(new model(first name)).add(stringvalidator.minimum(5)); results in- 'first name' with value 'abc' is shorter than the minimum of 5 characters. == Use Case 3: StringResourceModel srm = new StringResourceModel(CustomStringValidator.minimum, null, null, new Object[]{ rowIndex }); add(new textfield(fname).add(stringvalidator.minimum(5, srm)); results in- 'fNameId' with value 'abc' at row 10 is shorter than the minimum of 5 characters. == Use Case 4: StringResourceModel srm = new StringResourceModel(CustomStringValidator.minimum, null, null, new Object[]{ rowIndex }); add(new textfield(fname).setlabel(new model(first name)).add(stringvalidator.minimum(5, srm)); results in- 'first name' with value 'abc' at row 10 is shorter than the minimum of 5 characters. == Use Case 5: StringResourceModel srm = new StringResourceModel(CustomStringValidator.minimum, null, null, new Object[]{ rowIndex }); add(new textfield(fname).setlabel(new model(first name)).add(stringvalidator.minimum(5, srm)).add(new MyUsernameValidator()); results in- 'first name' with value 'abc' at row 10 is shorter than the minimum of 5 characters. results in- 'first name' with value 'abc' at row 10 is not unique. == -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 20, 2008 8:41 PM To: users@wicket.apache.org Subject: Re: Providing IModel to Validators On Tue, May 20, 2008 at 3:39 PM, Hoover, William [EMAIL PROTECTED] wrote: sure, if you know to override NumberValidator.minimum with: label.myminimum=My Object at row: {0} with value NumberValidator.minimum=${label} '${input}' must be smaller than ${minimum} It seems odd because: 1) NumberValidator.minimum (or any other entry in Application.properties) does not use ${label} by default i have argued for this, but ive been met with resistance. reasoning was that not everyone
RE: How can i load Image??
Why not do: final Image logoImg = new Image(logoimg); logoImg.add(new SimpleAttributeModifier(src, chemin)); or: final Image logoImg = new Image(logoimg); logoImg.add(new AttributeModifier(src, true, new AbstractReadOnlyModel() { public final Object getObject() { // TODO : get the image source that will be updated dynamically return chemin; } })); -Original Message- From: Fabien D. [mailto:[EMAIL PROTECTED] Sent: Thursday, May 22, 2008 9:08 AM To: users@wicket.apache.org Subject: How can i load Image?? Hi everybody, In my web application, I want to display a Image. I try to use Image and ResourceReference but I have some problemes My image is in a folder stock in my context of my web aplication : /stock/domaine/sdoimaine/projet/logo. I try to load it with the real path, or the context path... String name_upload = GestionProperties.getProperty(uploadRealdir); String chemin = name_upload+File.separator+model_domaine.getObject()+File.separator+mode l_sous_domaine.getObject()+File.separator+model_nom.getObject()+File.sep arator+model_logo.getObject(); ResourceReference ref = new ResourceReference(chemin); Image logoProjet = new Image(logoimg, ref ); And the result is : http://localhost:8080/appWicket-1.0/resources/org.apache.wicket.Applicat ion/stock... How can I place my RessourceReference in the context? Thank you in adance -- View this message in context: http://www.nabble.com/How-can-i-load-Image---tp17403872p17403872.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Providing IModel to Validators
What I'm proposing would not require the same first name model on both validators. I might not have been clear enough in my explanation... StringValidator.minimum='${label}' with value '${input}' is shorter than the minimum of ${minimum} characters. CustomStringValidator.minimum='${label}' with value '${input}' at row {0} is shorter than the minimum of ${minimum} characters. MyUsernameValidator.unique='${label}' with value '${input}' at row {0} is not unique. == Use Case 1: add(new textfield(fname).add(stringvalidator.minimum(5)); results in- 'fNameId' with value 'abc' is shorter than the minimum of 5 characters. == Use Case 2: add(new textfield(fname).setlabel(new model(first name)).add(stringvalidator.minimum(5)); results in- 'first name' with value 'abc' is shorter than the minimum of 5 characters. == Use Case 3: StringResourceModel srm = new StringResourceModel(CustomStringValidator.minimum, null, null, new Object[]{ rowIndex }); add(new textfield(fname).add(stringvalidator.minimum(5, srm)); results in- 'fNameId' with value 'abc' at row 10 is shorter than the minimum of 5 characters. == Use Case 4: StringResourceModel srm = new StringResourceModel(CustomStringValidator.minimum, null, null, new Object[]{ rowIndex }); add(new textfield(fname).setlabel(new model(first name)).add(stringvalidator.minimum(5, srm)); results in- 'first name' with value 'abc' at row 10 is shorter than the minimum of 5 characters. == Use Case 5: StringResourceModel srm = new StringResourceModel(CustomStringValidator.minimum, null, null, new Object[]{ rowIndex }); add(new textfield(fname).setlabel(new model(first name)).add(stringvalidator.minimum(5, srm)).add(new MyUsernameValidator()); results in- 'first name' with value 'abc' at row 10 is shorter than the minimum of 5 characters. results in- 'first name' with value 'abc' at row 10 is not unique. == -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 20, 2008 8:41 PM To: users@wicket.apache.org Subject: Re: Providing IModel to Validators On Tue, May 20, 2008 at 3:39 PM, Hoover, William [EMAIL PROTECTED] wrote: sure, if you know to override NumberValidator.minimum with: label.myminimum=My Object at row: {0} with value NumberValidator.minimum=${label} '${input}' must be smaller than ${minimum} It seems odd because: 1) NumberValidator.minimum (or any other entry in Application.properties) does not use ${label} by default i have argued for this, but ive been met with resistance. reasoning was that not everyone uses setLabel() for every component. 2) label.myminimum has to be worded in a way that would accommodate all types of IValidator that may be used right, the ones in application.properties are generic. of course you can override the message just for that page/component by simply defining your own NumberValidator.minimum key and if i remember correctly you can do without the label entirely, defining your own componentid.NumberValidator.minimum - but dont quote me on this 3) label.myminimum shouldn't really exist on it's own of course not, you are calling setlabel(new resourcemodel(label.minimum)) on that one specific component, its not meant to be reusable 4) It's not very intuitive to use the label because... well... it's a label, not a validation message :o) well, this is a label meant to be used inside a validation message. so there :) i see nothing counter intuitive about add(new textfield(fname).setlabel(new model(first name)); and defining a default StringValidator.minimum=${label} must be at least ${minimum} characters for messages like first name must be at least 5 characters If there were a means to add a IModel when adding any of the validators (as described) it would follow the standard Wicket protocol of using models. Any thoughts? setLabel() takes in a model... the fact is that the label is scoped to the formcomponent, not validation message most of the time. eg add(new textfield(fname).add(stringvalidator.minimum(5)).add(new uniqueusernamevalidator()); so with your proposal i would have to give the same first name model to both validators, why? i can declare it once on the textfield, the label of the formcomponent wont change validator to validator. -igor -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 20, 2008 1:52 PM To: users@wicket.apache.org Subject: Re: Providing IModel to Validators that is why formcomponents have a setLabel(IModelString) whose text is then available via ${label} place holder. -igor On Tue, May 20, 2008 at 7:14 AM, Hoover, William [EMAIL PROTECTED] wrote: What does everyone think about updating the Wicket core validators to contain an optional IModel? Simple Use Case: # properties file
RE: Providing IModel to Validators
A column attribute, or any other attribute for that matter, would not make a difference because if would all be encapsulated within the model set on the validator (use case 6 below). Providing models to the validators would make it a lot easier to override validation messages because all the developer would have to do is set the model on it (vs looking up the resource key and add it to the components properties file). I can see that this is receiving some strong resistance so I wont push the issue any further :o) == Use Case 6: StringResourceModel srm = new StringResourceModel(CustomStringValidator.minimum, null, null, new Object[]{ rowIndex, columnIndex }); add(new textfield(fname).setlabel(new model(first name)).add(stringvalidator.minimum(5, srm)); results in- 'first name' with value 'abc' at row 10, column 3 is shorter than the minimum of 5 characters. == -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 3:07 PM To: users@wicket.apache.org Subject: Re: Providing IModel to Validators and what happens when someone wants ${label} at row {0} column {1} is required? do we start passing in arrays, lists, or maps for imodels to validators? why not just do textfield.setlabel(new model(first name at row +row)); -igor On Wed, May 21, 2008 at 4:52 AM, Hoover, William [EMAIL PROTECTED] wrote: What I'm proposing would not require the same first name model on both validators. I might not have been clear enough in my explanation... StringValidator.minimum='${label}' with value '${input}' is shorter than the minimum of ${minimum} characters. CustomStringValidator.minimum='${label}' with value '${input}' at row {0} is shorter than the minimum of ${minimum} characters. MyUsernameValidator.unique='${label}' with value '${input}' at row {0} is not unique. == Use Case 1: add(new textfield(fname).add(stringvalidator.minimum(5)); results in- 'fNameId' with value 'abc' is shorter than the minimum of 5 characters. == Use Case 2: add(new textfield(fname).setlabel(new model(first name)).add(stringvalidator.minimum(5)); results in- 'first name' with value 'abc' is shorter than the minimum of 5 characters. == Use Case 3: StringResourceModel srm = new StringResourceModel(CustomStringValidator.minimum, null, null, new Object[]{ rowIndex }); add(new textfield(fname).add(stringvalidator.minimum(5, srm)); results in- 'fNameId' with value 'abc' at row 10 is shorter than the minimum of 5 characters. == Use Case 4: StringResourceModel srm = new StringResourceModel(CustomStringValidator.minimum, null, null, new Object[]{ rowIndex }); add(new textfield(fname).setlabel(new model(first name)).add(stringvalidator.minimum(5, srm)); results in- 'first name' with value 'abc' at row 10 is shorter than the minimum of 5 characters. == Use Case 5: StringResourceModel srm = new StringResourceModel(CustomStringValidator.minimum, null, null, new Object[]{ rowIndex }); add(new textfield(fname).setlabel(new model(first name)).add(stringvalidator.minimum(5, srm)).add(new MyUsernameValidator()); results in- 'first name' with value 'abc' at row 10 is shorter than the minimum of 5 characters. results in- 'first name' with value 'abc' at row 10 is not unique. == -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 20, 2008 8:41 PM To: users@wicket.apache.org Subject: Re: Providing IModel to Validators On Tue, May 20, 2008 at 3:39 PM, Hoover, William [EMAIL PROTECTED] wrote: sure, if you know to override NumberValidator.minimum with: label.myminimum=My Object at row: {0} with value NumberValidator.minimum=${label} '${input}' must be smaller than ${minimum} It seems odd because: 1) NumberValidator.minimum (or any other entry in Application.properties) does not use ${label} by default i have argued for this, but ive been met with resistance. reasoning was that not everyone uses setLabel() for every component. 2) label.myminimum has to be worded in a way that would accommodate all types of IValidator that may be used right, the ones in application.properties are generic. of course you can override the message just for that page/component by simply defining your own NumberValidator.minimum key and if i remember correctly you can do without the label entirely, defining your own componentid.NumberValidator.minimum - but dont quote me on this 3) label.myminimum shouldn't really exist on it's own of course not, you are calling setlabel(new resourcemodel(label.minimum)) on that one specific component, its not meant to be reusable 4) It's not very intuitive to use the label because... well... it's
Providing IModel to Validators
What does everyone think about updating the Wicket core validators to contain an optional IModel? Simple Use Case: # properties file label.myminimum=My Object at row: {0} with value '${input}' must be smaller than ${minimum} ... final RefreshingView myView = new RefreshingView(tr-my-object-view) { protected final void populateItem(final Item item) { ... final TextField myTextField = new TextField(input-text-field); final IModel myMinValidatorModel = new StringResourceModel(label.myminimum, item, null, new Object[] { item.getIndex() }); myTextField.add(NumberValidator.MinimumValidator.minimum(10L, myMinValidatorModel); ... } }; ... So, instead of seeing a very general message that could apply to any number of fields that may contain the same value: ... '0' is smaller than the minimum of 10. '0' is smaller than the minimum of 10. '0' is smaller than the minimum of 10. ... You would see this: ... My Object at row: 1 with value '0' must be smaller than 10 My Object at row: 12 with value '0' must be smaller than 10 My Object at row: 20 with value '0' must be smaller than 10 ... The problem with just overriding the NumberValidator.minimum resource in this example is that makes it difficult to add custom property values (i.e. the index in example). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
yes, that will work in my example, but what if MyObjectOption is not part of my namespace? -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 10:14 AM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice why dont you just implement equals/hashcode on MyObjectOption??? -igor On Fri, May 16, 2008 at 5:14 AM, Hoover, William [EMAIL PROTECTED] wrote: Here is an example of what I'm referring to: class MyObject { private Long id; private MyObjectOption myObjectOption; public MyObject(final Long id){ setId(id); ... } ... } class MyObjectOption { private Long id; private String name; public MyObjectOption(final Long id){ setId(id); ... } ... } // in the WebPage final MyObject myObject = new MyObject(1L); ... myObject.setMyObjectOption(new MyObjectOption(200L)); final ListMyObjectOption myObjectOptionList = new ArrayListMyObjectOption(); myObjectOptionList.add(new MyObjectOption(100L)); myObjectOptionList.add(new MyObjectOption(200L)); myObjectOptionList.add(new MyObjectOption(300L)); final Form myForm = new Form(form-myobject, new CompoundPropertyModel(myObject)); ... final RadioGroup group = new RadioGroup(myObjectOption); group.add(new ListView(div-myobject-options-view, myObjectList) { protected final void populateItem(final ListItem item) { final MyObjectOption myObjectOption = (MyObjectOption) item.getModelObject(); item.add(new Label(label-myobject-option-name, myObjectOption.getName())); item.add(new Radio(input-radio-myobject-option, new Model(myObjectOption))); } }); myForm.add(group); add(myForm); form wicket:id=form-myobject div wicket:id=myObjectOption div wicket:id=div-myobject-options-view label wicket:id=label-myobject-option-name [MyObjectOption Name] /label input wicket:id=input-radio-myobject-option type=radio / /div /div /form In the example above myObjectOption would never be selected because it is not the same instance of the MyObjectOption that is in myObjectOptionList (index 1) even though they share the same ID. If an IChoiceRenderer was provided to the RadioGroup the following could accomplish the task of making the selection work: final IChoiceRenderer myObjectOptionRenderer = new ChoiceRenderer() { ... public final String getIdValue(final Object object, final int index) { final Object id = ((MyObjectOption) object).getId(); return (id != null) ? id.toString() : super.getIdValue(object, index); } ... }; -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2008 7:16 PM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice On Thu, May 15, 2008 at 3:12 PM, Hoover, William [EMAIL PROTECTED] wrote: It's strange that that kind of functionality is provided when multiple selections is needed (i.e. CheckBoxMultipleChoice), but it is not when only one choice is needed (i.e. RadioGroup/CheckGroup). CheckGroup is a muti-selection component It is an oddity that other components that have choices (i.e. DropDownChoice, etc.) provide a means to use an IChoiceRenderer, but some do not. the whole point of Radio/CheckGroup is to give the user more control then what IChoiceRenderer offers. What if someone is using a RadioGroup/CheckGroup that uses some form of a RepeatingView to generate the Radio/Check options dynamically? In the case where they need to make a selection using a separate choice instance than what is in the list, how would they accomplish that? If they set the choice on the RadioGroup/CheckGroup model it will never be selected because they are different instances, and because there is not IChoiceRenderer it is not possible to define an ID value to determine the equality of the two instances. Not really sure what you mean here. The selection is based on the model object of Radio/Check, not the Radio/Check instance itself... -igor -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2008 5:50 PM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice well, the whole point of radio/check group is to allow user complete control over markup. the whole point of choice renderer is to automate markup generation, so there is just a big mismatch. eg i always use radio/check group when using a choice renderer would be inconvenient. you can always roll your own subclass, i just dont think something like
RE: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
I agree, but there are some cases where it will not be possible to implement equals/hashcode on the model object. I would be more of a proponent to have as much consistency across components as possible- which would mean that ICoiceRenderer would be available, but not enforced, in any component that needs to handle choices (this is already the case for models --- IModelComparator Component#getModelComparator(...)). I'm not sure I understand what you mean by using a LoadableDetachableModel to solve the issue. Could you elaborate? -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 11:12 AM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice then use loadable detachable models that will ensure instance equality. we can let the group take a comparator, but its yet another complication. i see it as a reasonable enough requirement that objects properly implement equals and hashcode. -igor On Fri, May 16, 2008 at 7:58 AM, Hoover, William [EMAIL PROTECTED] wrote: yes, that will work in my example, but what if MyObjectOption is not part of my namespace? -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 10:14 AM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice why dont you just implement equals/hashcode on MyObjectOption??? -igor On Fri, May 16, 2008 at 5:14 AM, Hoover, William [EMAIL PROTECTED] wrote: Here is an example of what I'm referring to: class MyObject { private Long id; private MyObjectOption myObjectOption; public MyObject(final Long id){ setId(id); ... } ... } class MyObjectOption { private Long id; private String name; public MyObjectOption(final Long id){ setId(id); ... } ... } // in the WebPage final MyObject myObject = new MyObject(1L); ... myObject.setMyObjectOption(new MyObjectOption(200L)); final ListMyObjectOption myObjectOptionList = new ArrayListMyObjectOption(); myObjectOptionList.add(new MyObjectOption(100L)); myObjectOptionList.add(new MyObjectOption(200L)); myObjectOptionList.add(new MyObjectOption(300L)); final Form myForm = new Form(form-myobject, new CompoundPropertyModel(myObject)); ... final RadioGroup group = new RadioGroup(myObjectOption); group.add(new ListView(div-myobject-options-view, myObjectList) { protected final void populateItem(final ListItem item) { final MyObjectOption myObjectOption = (MyObjectOption) item.getModelObject(); item.add(new Label(label-myobject-option-name, myObjectOption.getName())); item.add(new Radio(input-radio-myobject-option, new Model(myObjectOption))); } }); myForm.add(group); add(myForm); form wicket:id=form-myobject div wicket:id=myObjectOption div wicket:id=div-myobject-options-view label wicket:id=label-myobject-option-name [MyObjectOption Name] /label input wicket:id=input-radio-myobject-option type=radio / /div /div /form In the example above myObjectOption would never be selected because it is not the same instance of the MyObjectOption that is in myObjectOptionList (index 1) even though they share the same ID. If an IChoiceRenderer was provided to the RadioGroup the following could accomplish the task of making the selection work: final IChoiceRenderer myObjectOptionRenderer = new ChoiceRenderer() { ... public final String getIdValue(final Object object, final int index) { final Object id = ((MyObjectOption) object).getId(); return (id != null) ? id.toString() : super.getIdValue(object, index); } ... }; -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2008 7:16 PM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice On Thu, May 15, 2008 at 3:12 PM, Hoover, William [EMAIL PROTECTED] wrote: It's strange that that kind of functionality is provided when multiple selections is needed (i.e. CheckBoxMultipleChoice), but it is not when only one choice is needed (i.e. RadioGroup/CheckGroup). CheckGroup is a muti-selection component It is an oddity that other components that have choices (i.e. DropDownChoice, etc.) provide a means to use an IChoiceRenderer, but some do not. the whole point of Radio/CheckGroup is to give the user more control then what IChoiceRenderer offers. What if someone is using a RadioGroup/CheckGroup that uses some form of a RepeatingView to generate the Radio/Check options dynamically? In the case where they need to make
RE: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
It could be left as is and use the display value as expected (i.e. input type=checkbox id=ID_VALUE value=DISPLAY_VALUE /). Another option would be to have an identifier renderer: public interface IChoiceRenderer extends IIdentifierRenderer { Object getDisplayValue(Object object); } public interface IIdentifierRenderer extends IClusterable { String getIdValue(Object object, int index); } -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 11:47 AM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice if you use an ldm in choice/choicegroup then you should have instance equality available since you will probably load the objects from the same place, so during request processing they are consistent. as far as choicerenderer, i dont think thats a good idea, what do you do with getdisplayvalue()? -igor On Fri, May 16, 2008 at 8:35 AM, Hoover, William [EMAIL PROTECTED] wrote: I agree, but there are some cases where it will not be possible to implement equals/hashcode on the model object. I would be more of a proponent to have as much consistency across components as possible- which would mean that ICoiceRenderer would be available, but not enforced, in any component that needs to handle choices (this is already the case for models --- IModelComparator Component#getModelComparator(...)). I'm not sure I understand what you mean by using a LoadableDetachableModel to solve the issue. Could you elaborate? -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 11:12 AM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice then use loadable detachable models that will ensure instance equality. we can let the group take a comparator, but its yet another complication. i see it as a reasonable enough requirement that objects properly implement equals and hashcode. -igor On Fri, May 16, 2008 at 7:58 AM, Hoover, William [EMAIL PROTECTED] wrote: yes, that will work in my example, but what if MyObjectOption is not part of my namespace? -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 10:14 AM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice why dont you just implement equals/hashcode on MyObjectOption??? -igor On Fri, May 16, 2008 at 5:14 AM, Hoover, William [EMAIL PROTECTED] wrote: Here is an example of what I'm referring to: class MyObject { private Long id; private MyObjectOption myObjectOption; public MyObject(final Long id){ setId(id); ... } ... } class MyObjectOption { private Long id; private String name; public MyObjectOption(final Long id){ setId(id); ... } ... } // in the WebPage final MyObject myObject = new MyObject(1L); ... myObject.setMyObjectOption(new MyObjectOption(200L)); final ListMyObjectOption myObjectOptionList = new ArrayListMyObjectOption(); myObjectOptionList.add(new MyObjectOption(100L)); myObjectOptionList.add(new MyObjectOption(200L)); myObjectOptionList.add(new MyObjectOption(300L)); final Form myForm = new Form(form-myobject, new CompoundPropertyModel(myObject)); ... final RadioGroup group = new RadioGroup(myObjectOption); group.add(new ListView(div-myobject-options-view, myObjectList) { protected final void populateItem(final ListItem item) { final MyObjectOption myObjectOption = (MyObjectOption) item.getModelObject(); item.add(new Label(label-myobject-option-name, myObjectOption.getName())); item.add(new Radio(input-radio-myobject-option, new Model(myObjectOption))); } }); myForm.add(group); add(myForm); form wicket:id=form-myobject div wicket:id=myObjectOption div wicket:id=div-myobject-options-view label wicket:id=label-myobject-option-name [MyObjectOption Name] /label input wicket:id=input-radio-myobject-option type=radio / /div /div /form In the example above myObjectOption would never be selected because it is not the same instance of the MyObjectOption that is in myObjectOptionList (index 1) even though they share the same ID. If an IChoiceRenderer was provided to the RadioGroup the following could accomplish the task of making the selection work: final IChoiceRenderer myObjectOptionRenderer = new ChoiceRenderer() { ... public final String getIdValue(final Object object, final int index) { final Object id = ((MyObjectOption) object).getId(); return (id != null) ? id.toString
RE: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
It is valid to have a value on a checbox/radio http://www.w3.org/TR/html401/interact/forms.html#h-17.4 I agree that the name of the interface needs to be addressed. The concept is what I was attempting to convey. -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 12:16 PM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice afaik value is not used in checkbox or radio, not even sure that its valid to have it. iidentfierrenderer is a bad name since the id isnt actually rendered... -igor On Fri, May 16, 2008 at 9:07 AM, Hoover, William [EMAIL PROTECTED] wrote: It could be left as is and use the display value as expected (i.e. input type=checkbox id=ID_VALUE value=DISPLAY_VALUE /). Another option would be to have an identifier renderer: public interface IChoiceRenderer extends IIdentifierRenderer { Object getDisplayValue(Object object); } public interface IIdentifierRenderer extends IClusterable { String getIdValue(Object object, int index); } -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 11:47 AM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice if you use an ldm in choice/choicegroup then you should have instance equality available since you will probably load the objects from the same place, so during request processing they are consistent. as far as choicerenderer, i dont think thats a good idea, what do you do with getdisplayvalue()? -igor On Fri, May 16, 2008 at 8:35 AM, Hoover, William [EMAIL PROTECTED] wrote: I agree, but there are some cases where it will not be possible to implement equals/hashcode on the model object. I would be more of a proponent to have as much consistency across components as possible- which would mean that ICoiceRenderer would be available, but not enforced, in any component that needs to handle choices (this is already the case for models --- IModelComparator Component#getModelComparator(...)). I'm not sure I understand what you mean by using a LoadableDetachableModel to solve the issue. Could you elaborate? -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 11:12 AM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice then use loadable detachable models that will ensure instance equality. we can let the group take a comparator, but its yet another complication. i see it as a reasonable enough requirement that objects properly implement equals and hashcode. -igor On Fri, May 16, 2008 at 7:58 AM, Hoover, William [EMAIL PROTECTED] wrote: yes, that will work in my example, but what if MyObjectOption is not part of my namespace? -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 10:14 AM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice why dont you just implement equals/hashcode on MyObjectOption??? -igor On Fri, May 16, 2008 at 5:14 AM, Hoover, William [EMAIL PROTECTED] wrote: Here is an example of what I'm referring to: class MyObject { private Long id; private MyObjectOption myObjectOption; public MyObject(final Long id){ setId(id); ... } ... } class MyObjectOption { private Long id; private String name; public MyObjectOption(final Long id){ setId(id); ... } ... } // in the WebPage final MyObject myObject = new MyObject(1L); ... myObject.setMyObjectOption(new MyObjectOption(200L)); final ListMyObjectOption myObjectOptionList = new ArrayListMyObjectOption(); myObjectOptionList.add(new MyObjectOption(100L)); myObjectOptionList.add(new MyObjectOption(200L)); myObjectOptionList.add(new MyObjectOption(300L)); final Form myForm = new Form(form-myobject, new CompoundPropertyModel(myObject)); ... final RadioGroup group = new RadioGroup(myObjectOption); group.add(new ListView(div-myobject-options-view, myObjectList) { protected final void populateItem(final ListItem item) { final MyObjectOption myObjectOption = (MyObjectOption) item.getModelObject(); item.add(new Label(label-myobject-option-name, myObjectOption.getName())); item.add(new Radio(input-radio-myobject-option, new Model(myObjectOption))); } }); myForm.add(group); add(myForm); form wicket:id=form-myobject div wicket:id=myObjectOption div wicket:id=div-myobject-options-view label wicket:id=label-myobject-option-name [MyObjectOption Name] /label input wicket:id=input-radio-myobject
IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
For consistency sake, wouldn't it be wise to use IChoiceRenderer for RadioGroup and CheckBoxMultipleChoice? Seems like a natural solution to override IChoiceRenderer#getIdValue(...) to infer IDs for selection comparison the same way that it is being done in DropDownChoice. Otherwise, how else can you use two different model object instances that share the same ID to be selectable? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
yes... sorry CheckGroup is what I meant. It seems as though RadioGroup/CheckGroup should also have the capability of using an IChoiceRenderer as well, right? One reason I was thinking that is if someone has a model object instance A that is a different instance than any of the choices in the list, they can override the IChoiceRenderer#getIdValue(...) and provide the identifier. Even though none of the choices are the same instance of A they can still determine equality for selection purposes using the ID value. -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2008 4:47 PM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice checkboxmultiplechoice uses ichoicerenderer afaik, did you mean checkgroup? radiogroup/checkgroup work differently, they leave all text generation up to the user so no choice renderer is required. -igor On Thu, May 15, 2008 at 1:01 PM, Hoover, William [EMAIL PROTECTED] wrote: For consistency sake, wouldn't it be wise to use IChoiceRenderer for RadioGroup and CheckBoxMultipleChoice? Seems like a natural solution to override IChoiceRenderer#getIdValue(...) to infer IDs for selection comparison the same way that it is being done in DropDownChoice. Otherwise, how else can you use two different model object instances that share the same ID to be selectable? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice
I agree with your view on keeping Wicket from being bloated. What if the IChoiceRenderer was optional? If you provide it you have automation. If you do not it works as it does now. It's strange that that kind of functionality is provided when multiple selections is needed (i.e. CheckBoxMultipleChoice), but it is not when only one choice is needed (i.e. RadioGroup/CheckGroup). It is an oddity that other components that have choices (i.e. DropDownChoice, etc.) provide a means to use an IChoiceRenderer, but some do not. What if someone is using a RadioGroup/CheckGroup that uses some form of a RepeatingView to generate the Radio/Check options dynamically? In the case where they need to make a selection using a separate choice instance than what is in the list, how would they accomplish that? If they set the choice on the RadioGroup/CheckGroup model it will never be selected because they are different instances, and because there is not IChoiceRenderer it is not possible to define an ID value to determine the equality of the two instances. -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2008 5:50 PM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice well, the whole point of radio/check group is to allow user complete control over markup. the whole point of choice renderer is to automate markup generation, so there is just a big mismatch. eg i always use radio/check group when using a choice renderer would be inconvenient. you can always roll your own subclass, i just dont think something like that would belong in core, its just one more parallel way of doing something. -igor On Thu, May 15, 2008 at 2:44 PM, Hoover, William [EMAIL PROTECTED] wrote: yes... sorry CheckGroup is what I meant. It seems as though RadioGroup/CheckGroup should also have the capability of using an IChoiceRenderer as well, right? One reason I was thinking that is if someone has a model object instance A that is a different instance than any of the choices in the list, they can override the IChoiceRenderer#getIdValue(...) and provide the identifier. Even though none of the choices are the same instance of A they can still determine equality for selection purposes using the ID value. -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2008 4:47 PM To: users@wicket.apache.org Subject: Re: IChoiceRenderer: RadioGroup CheckBoxMultipleChoice checkboxmultiplechoice uses ichoicerenderer afaik, did you mean checkgroup? radiogroup/checkgroup work differently, they leave all text generation up to the user so no choice renderer is required. -igor On Thu, May 15, 2008 at 1:01 PM, Hoover, William [EMAIL PROTECTED] wrote: For consistency sake, wouldn't it be wise to use IChoiceRenderer for RadioGroup and CheckBoxMultipleChoice? Seems like a natural solution to override IChoiceRenderer#getIdValue(...) to infer IDs for selection comparison the same way that it is being done in DropDownChoice. Otherwise, how else can you use two different model object instances that share the same ID to be selectable? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using generics with some non-generic classes in Wicket
imho, that seems like that adds a lot of unnecessary code. One of the nice things about Wicket is that it keeps the bloat to a minimum. -Original Message- From: Doug Donohoe [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 14, 2008 8:21 AM To: users@wicket.apache.org Subject: Re: Using generics with some non-generic classes in Wicket Somewhat related to this thread, when I moved to generics win Wicket 1.4, I created some utility classes such as: public class VoidContainer extends WebMarkupContainerlt;Void public class VoidPanel extends Panellt;Void public class StringLabel extends Labellt;String public class IntegerModel extends Modellt;Integer public class StringModel extends Modellt;String public class DateModel extends Modellt;Date public class DoubleModel extends Modellt;Double And so on. This made my wicket code cleaner and easier to use. I think the Wicket 1.4 generics implementation is headed in the right direction. It was a pain at first because I had to parameterize everything, but creating convenience classes like this made it easier. I'm thinking about creating a patch with a suite of these types of classes because I think users will want something like this. -Doug Johan Compagner wrote: The problem is that wicket needs an annotation genericsOptional so that all the warnings about raw types are gone. A component only has to be generic if you use the IModel constructor or call getModel(), getModelObject() methods.. for the rest it is not really needed johan On Wed, May 14, 2008 at 9:28 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: My post kind of missed the point, I shouldn't post when I'm already half asleep. :-) Obviously MarkupContainer satisfies the MarkupContainer? in a method argument, so it accepts the raw type. However, it generates a warning because the method says it's generified, so you should be using the generic type. Johan Compagner wrote: I dont care, because i cant do any thing with the ? The only thing it enforces is that it must now be a generic class which is annoying. Not to mention that in that area eclipse and javac accept different things The reason it warns you to use generics when generics are wanted is because Sun wants to be able to make it *required* (in a future release) to use generics where generics are wanted; at least, so I read... I think in the real world they wouldn't dare to do this because it would piss off so many users and break so much stuff. :-) But the idea is that if something is generified you should be using a type parameter, and using a raw type is *purely* for backwards compatibility with legacy code. Regards, Sebastiaan So or we in wicket dont use ? any where and have supress warning everywhere for that or we do use it and then suddenly it is in my eyes restricted to much. I don't understand On 5/14/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Johan Compagner wrote: yes thats the reason you are calling the method add with a generified component but that container itself is not generified i dont like this about generics expecially the onces like this: add(MarkupContainer? container) then suddenly a none generified component cant be added... thats really stupid ? should mean anything.. including none generics No, that's not correct. For example, List? is much more restrictive than a raw List (which is a List). To a raw list you can add an instance of any type whatever, i.e., list.add(new Object()). But in List? the ? is a wildcard which says it could be any type there, i.e., it could be a ListInteger. But you can't add a new Object() to a ListInteger! Thus MarkupContainer? means MarkupContainer parameterized by some unknown type, and *not* MarkupContainer parameterized by Object, which is what the raw type means. Regards, Sebastiaan johan On Tue, May 13, 2008 at 5:55 PM, Stefan Simik [EMAIL PROTECTED] wrote: I have one idea, the reason of the warnigs is, that parent of AjaxPagingNavigator is PagingNavigator, which has parent Panel --- that is not parameterized. The same problem is with LoopItem, which extends the WebMarkupContainer --- that is not parameterized. ? could this be the reason ? Stefan Simik wrote: Mhmm, it is meaningful ;) I will know in future, thx One of the last occuring warning is, when working with MarkupContainer#add(...) or #addOrReplace(...) method. Example: I have a simple AjaxPagingNavigator, to which I add a simple ListView - -- ListViewInteger menu = new ListViewInteger(id, numbers){ //populate metods } add(menu);
RE: How to get select objects from ListView
@SuppressWarnings(unchecked) public final ListCulture findCultures() { final ListCulture cultures = new ArrayListCulture(); final IteratorItem items = ratingScalesView.getItems(); if (items != null) { while (items.hasNext()) { cultures.add((Culture) items.next().getModelObject()); } } return cultures; } -Original Message- From: Mathias P.W Nilsson [mailto:[EMAIL PROTECTED] Sent: Friday, May 09, 2008 7:37 AM To: users@wicket.apache.org Subject: How to get select objects from ListView Hi! I have this list view ListView view = new ListView( translatorView , cultureModel ){ private static final long serialVersionUID = 1L; @Override protected void populateItem(ListItem item) { Culture culture = (Culture) item.getModelObject(); item.add( new Label( culture , culture.getName() )); DropDownChoice translatorChoice = new DropDownChoice( translatorChoice, new LoadableDetachableTranslatorModel( culture) , new FtcUserChoiceRenderer() ){ private static final long serialVersionUID = 1L; @Override protected java.lang.CharSequence getDefaultChoice(final Object selected){ return option value=\\+ getLocalizer().getString( culture.select.empty, TranslatorInvitationPage.this ) + /option; } }; item.add( translatorChoice ); } }; The model is a detached model for users. How can I get the list of drop down choice model objects? -- View this message in context: http://www.nabble.com/How-to-get-select-objects-from-ListView-tp17146212 p17146212.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AutoCompleteTextField type mismatch in line 227
Although, it still has some issues when dealing with mouseover and keyboard events combo ;o) -Original Message- From: Gerolf Seitz [mailto:[EMAIL PROTECTED] Sent: Thursday, May 08, 2008 4:23 PM To: users@wicket.apache.org Subject: Re: AutoCompleteTextField type mismatch in line 227 it's fixed in the upcoming 1.3.4 and the already release 1.4-M1 Gerolf On Thu, May 8, 2008 at 10:20 PM, taygolf [EMAIL PROTECTED] wrote: Yes I am just starting to try and get the autocompletetextfield working on my app and I am using wicket 1.3. as well and it is doing the same thing. It is throwing a js type mismatch error. Works fine in firefox but not in IE. Did you figure out the problem? T Niels Bo wrote: Hi I just swithed from 1.3.2 to 1.3.3 and that resultet in a javascript error type mismatch in line 227, wich is this line in wicket-autocomplete.js: menu.style.zIndex=index==auto?index:Number(index)+1; Only in IE (6.0) - firefox works fine. Does anyone else see this problem? Niels -- View this message in context: http://www.nabble.com/AutoCompleteTextField-%22type-mismatch%22-in-lin e-227-tp16560166p17135623.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AutoCompleteTextField type mismatch in line 227
that is it :o) i'm assuming the same issue also causes the selection to be lost on occasion -Original Message- From: Gerolf Seitz [mailto:[EMAIL PROTECTED] Sent: Thursday, May 08, 2008 7:57 PM To: users@wicket.apache.org Subject: Re: AutoCompleteTextField type mismatch in line 227 in case you mean [0], that's going to be dealt with probably tomorrow ;) [0] https://issues.apache.org/jira/browse/WICKET-1595 On Fri, May 9, 2008 at 1:52 AM, Hoover, William [EMAIL PROTECTED] wrote: Although, it still has some issues when dealing with mouseover and keyboard events combo ;o) -Original Message- From: Gerolf Seitz [mailto:[EMAIL PROTECTED] Sent: Thursday, May 08, 2008 4:23 PM To: users@wicket.apache.org Subject: Re: AutoCompleteTextField type mismatch in line 227 it's fixed in the upcoming 1.3.4 and the already release 1.4-M1 Gerolf On Thu, May 8, 2008 at 10:20 PM, taygolf [EMAIL PROTECTED] wrote: Yes I am just starting to try and get the autocompletetextfield working on my app and I am using wicket 1.3. as well and it is doing the same thing. It is throwing a js type mismatch error. Works fine in firefox but not in IE. Did you figure out the problem? T Niels Bo wrote: Hi I just swithed from 1.3.2 to 1.3.3 and that resultet in a javascript error type mismatch in line 227, wich is this line in wicket-autocomplete.js: menu.style.zIndex=index==auto?index:Number(index)+1; Only in IE (6.0) - firefox works fine. Does anyone else see this problem? Niels -- View this message in context: http://www.nabble.com/AutoCompleteTextField-%22type-mismatch%22-in-l in e-227-tp16560166p17135623.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AutoComplete functionality for Wicket 1.4-m1 in IE
I think he is referring to http://issues.apache.org/jira/browse/WICKET-1504 -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Monday, May 05, 2008 6:52 PM To: users@wicket.apache.org Subject: Re: AutoComplete functionality for Wicket 1.4-m1 in IE Which jira issue are you talking about? On 5/5/08, Ricky [EMAIL PROTECTED] wrote: Hi, The AutoCompleteTextField doesn't seemed to be fixed for corrupt IE behavior in wicket 1.4-m1 release; Can someone confirm this ? If so, any ideas as to when this issue will be addressed or fixed ? Thanks and appreciate your time. Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AutoComplete functionality for Wicket 1.4-m1 in IE
I tested this fix and it seems to be fixed. Ricky, make sure that you cleared your browser cache and try again. -Original Message- From: Hoover, William [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 06, 2008 8:33 AM To: users@wicket.apache.org Subject: RE: AutoComplete functionality for Wicket 1.4-m1 in IE I think he is referring to http://issues.apache.org/jira/browse/WICKET-1504 -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Monday, May 05, 2008 6:52 PM To: users@wicket.apache.org Subject: Re: AutoComplete functionality for Wicket 1.4-m1 in IE Which jira issue are you talking about? On 5/5/08, Ricky [EMAIL PROTECTED] wrote: Hi, The AutoCompleteTextField doesn't seemed to be fixed for corrupt IE behavior in wicket 1.4-m1 release; Can someone confirm this ? If so, any ideas as to when this issue will be addressed or fixed ? Thanks and appreciate your time. Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AutoComplete functionality for Wicket 1.4-m1 in IE
I did notice another issue that seems to be prevalent in IE and Firefox. Sometimes when the selection is made using the mouse and new AjaxFormComponentUpdatingBehavior(onchange) { protected void onUpdate(final AjaxRequestTarget target) { ... } }, will not always be fired. I have yet to pinpoint a solid use case when this occurs consecutively. -Original Message- From: Hoover, William [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 06, 2008 8:43 AM To: users@wicket.apache.org Subject: RE: AutoComplete functionality for Wicket 1.4-m1 in IE I tested this fix and it seems to be fixed. Ricky, make sure that you cleared your browser cache and try again. -Original Message- From: Hoover, William [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 06, 2008 8:33 AM To: users@wicket.apache.org Subject: RE: AutoComplete functionality for Wicket 1.4-m1 in IE I think he is referring to http://issues.apache.org/jira/browse/WICKET-1504 -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Monday, May 05, 2008 6:52 PM To: users@wicket.apache.org Subject: Re: AutoComplete functionality for Wicket 1.4-m1 in IE Which jira issue are you talking about? On 5/5/08, Ricky [EMAIL PROTECTED] wrote: Hi, The AutoCompleteTextField doesn't seemed to be fixed for corrupt IE behavior in wicket 1.4-m1 release; Can someone confirm this ? If so, any ideas as to when this issue will be addressed or fixed ? Thanks and appreciate your time. Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [announce] wicketstuff-annotation 1.0 released
Would it be better if there were a core wicket-annotation project that provides the basics (such as the scanner) and another project called wicket-automount (with wicket-annotation dependency)? That way other future projects can utilize the core capabilities without reinventing the wheel. This would also accommodate those who want a specific dependency for wicket-automount. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Tuesday, May 06, 2008 4:37 PM To: users@wicket.apache.org Subject: Re: [announce] wicketstuff-annotation 1.0 released The name wicket-annotations doesn't really tell you anything about what features it provides (as was pointed out earlier). If I were a person wanting to find an easier way to mount pages, it wouldn't necessarily be obvious to check wicket-annotations. However, it would be more obvious if I saw something called wicket-automount. On Tue, May 6, 2008 at 4:02 PM, Ryan Sonnek [EMAIL PROTECTED] wrote: the only reason to break annotations out into separate distributions is if new dependencies are introduced with a subset of annotations. if a new annotation comes along that requires hibernate jars to be on the classpath, that definitely should be it's own project. otherwise, it makes sense to lump all annotations together. On Tue, May 6, 2008 at 2:59 PM, James Carman [EMAIL PROTECTED] wrote: Yes, but should we globalize the annotations namespace to mean that anyone who wants to do anything with annotations should put it inside this project? Perhaps keeping things smaller is a better idea. That way, if I want to use automount, but I don't want all of the other annotation-based goodies, I can just download this little nugget and use it. On Tue, May 6, 2008 at 3:55 PM, Doug Donohoe [EMAIL PROTECTED] wrote: Matthijs, That is a good point and I did consider that, but I thought if anyone else wants to do things with annotations and wicket in the future, this would be a perfect place to put that code (especially given the underlying scanning support). Thus, I was being optimistic about the future. Believe me, I spent an hour staring out the window trying to decide on the right name. Hopefully the documentation explains clearly what it does. -Doug Matthijs Wensveen-2 wrote: Doug Donohoe wrote: I am pleased to announce the 1.0 release of wicketstuff-annotation. Nice. But the name 'wicketstuff-annotation' does not say anything about what it does, just 'something with annotations'. IMO 'wicketstuff-mount-annotations' or somesuch would be better. Just my 2c. Matthijs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-announce--wicketstuff-annotation-1.0-released-t p17090601p17091003.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [announce] wicketstuff-annotation 1.0 released
Yes, that is what I ment. I should have said wicketstuff-annotation and wicketstuff-automount. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Tuesday, May 06, 2008 5:45 PM To: users@wicket.apache.org Subject: Re: [announce] wicketstuff-annotation 1.0 released On Tue, May 6, 2008 at 5:42 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Tue, May 6, 2008 at 2:24 PM, Hoover, William [EMAIL PROTECTED] wrote: Would it be better if there were a core wicket-annotation project thatprovides the basics (such as the scanner) and another project calledwicket-automount (with wicket-annotation dependency)? That way otherfuture projects can utilize the core capabilities without reinventingthe wheel. This would also accommodate those who want a specificdependency for wicket-automount. The project can be split without needing to make one a core project though. On the long term we could consider making something like that a core project, but for now that simply wouldn't be practical. The great thing about wicket-stuff projects is that it is easy for people to join the effort. I don't think they meant core project as in a subproject of Wicket, hosted at the ASF. I think they meant a core wicket-annotations project at wicketstuff that others could lean on Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANNOUNCE] Apache Wicket 1.4-M1
Is there a reason why StringResourceModel is not using StringResourceModelT ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Bille Sent: Friday, May 02, 2008 4:09 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; users@wicket.apache.org; Apache Wicket Development Subject: [ANNOUNCE] Apache Wicket 1.4-M1 The Apache Wicket team is proud to announce the availability of the first milestone release of our first java 1.5 Wicket version: Apache Wicket 1.4-m1. Eager people click here to download the distribution, others can read further: http://www.apache.org/dyn/closer.cgi/wicket/1.4-m1 We thank you for your patience and support. The Wicket Team === Apache Wicket === Apache Wicket is a component oriented Java web application framework. With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML, Apache Wicket makes developing web-apps simple and enjoyable again. Swap the boilerplate, complex debugging and brittle code for powerful, reusable components written with plain Java and HTML. You can find out more about Apache Wicket on our website: http://wicket.apache.org === This release === The Apache Wicket team is proud to announce the availability of the first milestone release of our first java 1.5 Wicket version: Apache Wicket 1.4-m1. This is the first release with java 1.5 as a minimum. Not everything has been converted to java 1.5 yet but we are getting there. === Migrating from 1.3 === If you are coming from Wicket 1.3, you really want to read our migration guide, found on the wiki: http://cwiki.apache.org/WICKET/migrate-14.html === Downloading the release === You can download the release from the official Apache mirror system, and you can find it through the following link: http://www.apache.org/dyn/closer.cgi/wicket/1.4-m1/ For the Maven and Ivy fans out there: update your pom's to the following, and everything will be downloaded automatically: dependency groupIdorg.apache.wicket/groupId artifactIdwicket/artifactId version1.4-m1/version /dependency Substitute the artifact ID with the projects of your liking to get the other projects. Please note that we don't prescribe a Logging implementation for SLF4J. You need to specify yourself which one you prefer. Read more about SLF4J here: [http://slf4j.org] === Validating the release === The release has been signed by Frank Bille, your release manager for today. The public key can be found in the KEYS file in the download area. Download the KEYS file only from the Apache website. http://www.apache.org/dist/wicket/1.4-m1/KEYS Instructions on how to validate the release can be found here: http://www.apache.org/dev/release-signing.html#check-integrity === Reporting bugs === In case you do encounter a bug, we would appreciate a report in our JIRA: http://issues.apache.org/jira/browse/WICKET === The distribution === In the distribution you will find a README. The README contains instructions on how to build from source yourself. You also find a CHANEGELOG-1.4 which contains a list of all things that have been fixed, added and/or removed since the first release in the 1.4 branch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANNOUNCE] Apache Wicket 1.4-M1
Is that the same case for UploadProgressBar ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Bille Sent: Sunday, May 04, 2008 11:52 AM To: users@wicket.apache.org Subject: Re: [ANNOUNCE] Apache Wicket 1.4-M1 It wasn't done at the time of m1. It's fixed in trunk (hardcoded to String) Frank On Sun, May 4, 2008 at 5:47 PM, Hoover, William [EMAIL PROTECTED] wrote: Is there a reason why StringResourceModel is not using StringResourceModelT ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Bille Sent: Friday, May 02, 2008 4:09 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; users@wicket.apache.org; Apache Wicket Development Subject: [ANNOUNCE] Apache Wicket 1.4-M1 The Apache Wicket team is proud to announce the availability of the first milestone release of our first java 1.5 Wicket version: Apache Wicket 1.4-m1. Eager people click here to download the distribution, others can read further: http://www.apache.org/dyn/closer.cgi/wicket/1.4-m1 We thank you for your patience and support. The Wicket Team === Apache Wicket === Apache Wicket is a component oriented Java web application framework. With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML, Apache Wicket makes developing web-apps simple and enjoyable again. Swap the boilerplate, complex debugging and brittle code for powerful, reusable components written with plain Java and HTML. You can find out more about Apache Wicket on our website: http://wicket.apache.org === This release === The Apache Wicket team is proud to announce the availability of the first milestone release of our first java 1.5 Wicket version: Apache Wicket 1.4-m1. This is the first release with java 1.5 as a minimum. Not everything has been converted to java 1.5 yet but we are getting there. === Migrating from 1.3 === If you are coming from Wicket 1.3, you really want to read our migration guide, found on the wiki: http://cwiki.apache.org/WICKET/migrate-14.html === Downloading the release === You can download the release from the official Apache mirror system, and you can find it through the following link: http://www.apache.org/dyn/closer.cgi/wicket/1.4-m1/ For the Maven and Ivy fans out there: update your pom's to the following, and everything will be downloaded automatically: dependency groupIdorg.apache.wicket/groupId artifactIdwicket/artifactId version1.4-m1/version /dependency Substitute the artifact ID with the projects of your liking to get the other projects. Please note that we don't prescribe a Logging implementation for SLF4J. You need to specify yourself which one you prefer. Read more about SLF4J here: [http://slf4j.org] === Validating the release === The release has been signed by Frank Bille, your release manager for today. The public key can be found in the KEYS file in the download area. Download the KEYS file only from the Apache website. http://www.apache.org/dist/wicket/1.4-m1/KEYS Instructions on how to validate the release can be found here: http://www.apache.org/dev/release-signing.html#check-integrity === Reporting bugs === In case you do encounter a bug, we would appreciate a report in our JIRA: http://issues.apache.org/jira/browse/WICKET === The distribution === In the distribution you will find a README. The README contains instructions on how to build from source yourself. You also find a CHANEGELOG-1.4 which contains a list of all things that have been fixed, added and/or removed since the first release in the 1.4 branch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANNOUNCE] Apache Wicket 1.4-M1
Also, looks like most of the models are not generic typed (BoundCompoundPropertyModel, CompoundPropertyModel, etc.) are these fixed in trunk as well? -Original Message- From: Hoover, William [mailto:[EMAIL PROTECTED] Sent: Sunday, May 04, 2008 12:15 PM To: users@wicket.apache.org Subject: RE: [ANNOUNCE] Apache Wicket 1.4-M1 Is that the same case for UploadProgressBar ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Bille Sent: Sunday, May 04, 2008 11:52 AM To: users@wicket.apache.org Subject: Re: [ANNOUNCE] Apache Wicket 1.4-M1 It wasn't done at the time of m1. It's fixed in trunk (hardcoded to String) Frank On Sun, May 4, 2008 at 5:47 PM, Hoover, William [EMAIL PROTECTED] wrote: Is there a reason why StringResourceModel is not using StringResourceModelT ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Bille Sent: Friday, May 02, 2008 4:09 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; users@wicket.apache.org; Apache Wicket Development Subject: [ANNOUNCE] Apache Wicket 1.4-M1 The Apache Wicket team is proud to announce the availability of the first milestone release of our first java 1.5 Wicket version: Apache Wicket 1.4-m1. Eager people click here to download the distribution, others can read further: http://www.apache.org/dyn/closer.cgi/wicket/1.4-m1 We thank you for your patience and support. The Wicket Team === Apache Wicket === Apache Wicket is a component oriented Java web application framework. With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML, Apache Wicket makes developing web-apps simple and enjoyable again. Swap the boilerplate, complex debugging and brittle code for powerful, reusable components written with plain Java and HTML. You can find out more about Apache Wicket on our website: http://wicket.apache.org === This release === The Apache Wicket team is proud to announce the availability of the first milestone release of our first java 1.5 Wicket version: Apache Wicket 1.4-m1. This is the first release with java 1.5 as a minimum. Not everything has been converted to java 1.5 yet but we are getting there. === Migrating from 1.3 === If you are coming from Wicket 1.3, you really want to read our migration guide, found on the wiki: http://cwiki.apache.org/WICKET/migrate-14.html === Downloading the release === You can download the release from the official Apache mirror system, and you can find it through the following link: http://www.apache.org/dyn/closer.cgi/wicket/1.4-m1/ For the Maven and Ivy fans out there: update your pom's to the following, and everything will be downloaded automatically: dependency groupIdorg.apache.wicket/groupId artifactIdwicket/artifactId version1.4-m1/version /dependency Substitute the artifact ID with the projects of your liking to get the other projects. Please note that we don't prescribe a Logging implementation for SLF4J. You need to specify yourself which one you prefer. Read more about SLF4J here: [http://slf4j.org] === Validating the release === The release has been signed by Frank Bille, your release manager for today. The public key can be found in the KEYS file in the download area. Download the KEYS file only from the Apache website. http://www.apache.org/dist/wicket/1.4-m1/KEYS Instructions on how to validate the release can be found here: http://www.apache.org/dev/release-signing.html#check-integrity === Reporting bugs === In case you do encounter a bug, we would appreciate a report in our JIRA: http://issues.apache.org/jira/browse/WICKET === The distribution === In the distribution you will find a README. The README contains instructions on how to build from source yourself. You also find a CHANEGELOG-1.4 which contains a list of all things that have been fixed, added and/or removed since the first release in the 1.4 branch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WicketStuff.org Is Down
Does anyone have an ETA when wicketstuff.org will be back up? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: WicketStuff.org Is Down
okay... thanks for the info -Original Message- From: Martijn Dashorst [mailto:[EMAIL PROTECTED] Sent: Friday, May 02, 2008 3:31 PM To: users@wicket.apache.org Subject: Re: WicketStuff.org Is Down No. bamboo is doing its upgrade stuff. and has been doing that for about 3 hours. If you are looking for the examples, install them on your own box. They're only a download away. Martijn On 5/2/08, Hoover, William [EMAIL PROTECTED] wrote: Does anyone have an ETA when wicketstuff.org will be back up? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: getter called multiple times on PropertyModel with ListView
// It solves your problem because the call to load will be made each time your view renders final LoadableDetachableModel articlesLoadableModel = new LoadableDetachableModel() { private static final long serialVersionUID = 1L; /** * [EMAIL PROTECTED] */ @Override protected final Object load() { return new PropertyModel(YourPage.this, articles); } }; final ListView newsDetails = new ListView(newsDetails, articlesLoadableModel){ private static final long serialVersionUID = 1L; /** * [EMAIL PROTECTED] */ @Override protected final void populateItem(final ListItem item) { ... } }; add(newsDetails); -Original Message- From: Andrew Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 29, 2008 2:19 PM To: 'users@wicket.apache.org' Subject: RE: getter called multiple times on PropertyModel with ListView Cannot instantiate LoadableDetachableModel directly .. it is abstract. Besides, how does it help solve the problem? Thanks -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 29, 2008 12:49 PM To: users@wicket.apache.org Subject: Re: getter called multiple times on PropertyModel with ListView ListView newsDetails = new ListView(newsDetails, new LoadableDetachableModel(new PropertyModel(this, articles))) -igor On Tue, Apr 29, 2008 at 10:46 AM, Andrew Broderick [EMAIL PROTECTED] wrote: Hi, I have a page where I am using a PropertyModel to populate a ListView, so it will change when the underlying contents change: ListView newsDetails = new ListView(newsDetails, new PropertyModel(this, articles)) { protected void populateItem(ListItem item) { final NewsDetails nd = (NewsDetails) item.getModelObject(); item.add(new Label(articleDate, nd.getArticleDate())); item.add(new Label(articleTime, nd.getArticleTime())); item.add(new Label(newsShortDesc, nd.getNewsShortDesc())); newsUrlLink.add(new Label(newsTitle, nd.getNewsTitle())); item.add(newsUrlLink); } }; add(newsDetails); The page class, obviously, has a getter named getArticles(): public ListNewsDetails getArticles() { } However, this seems to get called multiple times when the listview is being populated, not just once at the beginning of each time the page is displayer. Why is this happening? It results in many more hits to the database than are necessary. Thanks, Andrew B ___ The information in this email or in any file attached hereto is intended only for the personal and confiden- tial use of the individual or entity to which it is addressed and may contain information that is propri- etary and confidential. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communica- tion is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product. Email trans- mission cannot be guaranteed to be secure or error- free. P6070214 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wicket Auto complete text Issue
I'm not sure why the built-in Wicket component doesn't support this feature out-of-the-box, but here is a simple fix/solution: /** * Auto-Complete text field that allows capture of choice selections by choice type (rather than just strings) * * @author whoover * * @param CHOICE *the choice type */ private abstract class AbstractAutoCompleteTextFieldCHOICE extends AutoCompleteTextField { private static final long serialVersionUID = 1L; private transient IteratorCHOICE choiceIterator; /** * Renderer constrcutor TODO : you can obviously add all of the constructors- just added this one for demo * * @param id *the ID to set * @param renderer *the renderer to set */ public AbstractAutoCompleteTextField(final String id, final IAutoCompleteRenderer renderer) { super(id, renderer); } /** * [EMAIL PROTECTED] */ @Override protected final IteratorCHOICE getChoices(final String searchTextInput) { // find list of items to display in auto-complete (we need to cache the list because the auto-complete only deals with strings) choiceIterator = getChoiceIterator(searchTextInput); return choiceIterator; } /** * Call-back method that should return an iterator over all possible assist choice objects. * These objects will be passed to the renderer to generate output. * * @param input *current input * @return iterator over all possible choice objects */ protected abstract IteratorCHOICE getChoiceIterator(final String searchTextInput); /** * Gets the string value from the specified choice * * @param choice *the choice that needs value extraction * @return the unique string value of the choice */ protected abstract String getChoiceValue(final CHOICE choice); /** * Finds the selection by cycling through the current choices and matching the choices value. * If the selected choice is found the choices will be reset and the choice will be returned. * p * bNOTE:/b Assumes that the selection choice values are unique * /p * * @return the found selection choice value (null if it cannot be found) */ public final CHOICE findChoice() { CHOICE choice; while (choiceIterator.hasNext()) { choice = choiceIterator.next(); if (getModelObject().equals(getChoiceValue(choice))) { // found result- clear choices cache (would be nice to use detach() method, but it has been finalized) choiceIterator = null; return choice; } } return null; } } Using the auto-complete above we can get our specific model instead of a string final AbstractAutoCompleteRenderer autoCompleteRenderer = new AbstractAutoCompleteRenderer() { private static final long serialVersionUID = 1L; /** * [EMAIL PROTECTED] */ @SuppressWarnings(unchecked) @Override protected final String getTextValue(final Object object) { // TODO : get the choice text value ((MyObject) object).getMyStringValue(); } /** * [EMAIL PROTECTED] */
wicket-minis release?
Does anyone know how close we are to a release of wicket-minis? http://wicketstuff.org/maven/repository/org/wicketstuff/wicketstuff-minis/ shows 1.3.0-SNAPSHOT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RadioButton inside DataTable
see http://cwiki.apache.org/WICKET/using-radiogroups.html -Original Message- From: Sathish Gopal [mailto:[EMAIL PROTECTED] Sent: Sunday, April 06, 2008 6:07 AM To: users@wicket.apache.org Subject: RadioButton inside DataTable Hi all, I'm trying to build DataTable using the Wickets DefaultDataTable component. One of the column in the list is a RadioButton component, which is used to select a particular row. I'm using wicket fragment feature. My html looks like this... div table cellpadding=0 cellspacing=1 wicket:id=table/ /div wicket:fragment wicket:id=radioChoiceFrag input type=radio wicket:id=selected/ /wicket:fragment My fragment looks like this.. public class FlightSelectionFragment extends Fragment { private RadioGroup radioGroup; public FlightSelectionFragment(String id, String markupId, MarkupContainer markupProvider) { super(id, markupId, markupProvider); radioGroup.add(new Radio(selected, new Model()) { }); } How do i add the same Radio button component (id=selected) to RadioGroup (id=radioChoicegroup) for multiple rows. i.e Assuming there are three rows in table. So i need 3 radio buttons which will be added to the same radio group (id=radioChoicegroup). But the component id (id=selected) cannot be the same for all the three rows. This gives Runtime Exception. How to handle this issue? -- View this message in context: http://www.nabble.com/RadioButton-inside-DataTable-tp16522717p16522717.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Default selection in radio group?
see http://cwiki.apache.org/confluence/display/WICKET/Using+RadioGroups -Original Message- From: Michael Mehrle [mailto:[EMAIL PROTECTED] Sent: Thursday, April 03, 2008 8:49 PM To: users@wicket.apache.org Subject: Default selection in radio group? I created a RadioGroup with three radios attached. For some reason the form is being drawn with the last radio pre-selected, which I don't want. How can I pre-select a default radio and also how can I set the group to nothing selected? Thanks, Michael