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
RE: DataView size() iterator() call order issue
I apologize that I missed the detach() portion of your email :o)
I don't want to beat the issue on needing size before offset/count and waste
anymore of anyone's time. In a legacy application we have I already
accomplished this. So, I will just use some customization to the wicket
components and incorporate the code from the legacy JSF application. Thanks for
your time!
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Friday, March 28, 2008 8:59 AM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
i already mentioned detach() in my fist reply to this thread 2 days ago...
and as i said before both variables that go into the iterator() are
depending on the size call so the size() call really needs to happen first
or we have to just guess those 2 variables completely
johan
On Fri, Mar 28, 2008 at 1:23 PM, Hoover, William [EMAIL PROTECTED]
wrote:
Perfect! detach was the missing piece of the puzzle, thank you! The only
issue remaining is the capability to combine the size/iterator call to
prevent duplicate DAO calls.
-Original Message-
From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 12:02 PM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
forgot:
public class MYSizeCachingDataProvider ... {
public void detach() {
size = null;
resultset = null;
}
}
On 3/27/08, Martijn Dashorst [EMAIL PROTECTED] wrote:
public class MySizeCachingDataProvider implements IDataProvider {
private Integer size = null;
private ListFoo resultset = null;
public int getSize() {
if(size == null ) {
performExpensiveQuery();
}
return size;
}
public Iterator iterator() {
if(resultset == null ) {
performExpensiveQuery();
}
return resultset;
}
private void performExpensiveQuery() {
size = count();
resultset = query();
}
}
On 3/27/08, Hoover, William [EMAIL PROTECTED] wrote:
I'm only interested in caching it for the current request so there
isn't multiple calls to size within the same request. The same way
AbstractPageableView is caching it and clearing it in onBeforeRender. The
only problem is that:
1) I do not have access to the cached size stored in
AbstractPageableView - cachedItemCount from within the data provider
2) The cached size in AbstractPageableView - cachedItemCount is
cleared in onBeforeRender() before the call is made to getViewOffset() -
getCurrentPage() - getPageCount() - getRowCount() when getting the item
models in getItemModels(); This causes a second call to the data providers
size() method when paginating. In other words, the AbstractPageableView -
cachedItemCount is not working properly when a link for the PagingNavigator
is clicked- causing 2 calls to the size() method within the same request
(w/o deletions ;o).
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 11:36 AM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
If you are iterating over a list that can be changed by all kinds of
different users
Then you cant really cache it
If you are iterating over a list that is pretty stable for the
current users
or the user itself only alters that list (insert/delete)
Then you can cache it easily
Just call detach (that clears the size cache) when you have an
action that
deletes or inserts a new items so that you know the size is changed.
johan
On Thu, Mar 27, 2008 at 4:04 PM, Hoover, William
[EMAIL PROTECTED]
wrote:
Can you post code for an example data provider that would KNOW how
to
cache the size?
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 10:47 AM
To: users@wicket.apache.org
Subject: Re: DataView size() iterator() call order issue
no you as a developer KNOW that it can cache it
Cache it if you can dont if you cant
On Thu, Mar 27, 2008 at 2:28 PM, Hoover, William
[EMAIL PROTECTED]
wrote:
Okay, two issues... (1) combined call for size/data (2) multiple
calls
to
size() when paginating
I will avoid confusion by addressing only the multiple calls to
size()
for
now.
If only the size was to be cached, as you suggested, how would
the data
provider know when to clear it? The data provider is statefull
and
maintains
the size across requests and there is no onBeforeRender in a
data
provider
like there is in AbstractPageableView. So, the size will never
be
cleared
