Re: [Wicket-user] Post 1.2 roadmap
If we do this (java5 and constructor change at once)Then we need to support 2 really different versions1.2 like it is now and a pretty much changed wicket by internals (constructor) and java5.If we don't we only really have to support 1.3 and 2.0 but those wickets are pretty much the same except 1.5 features like generics.That does merge much easier.But maybe if retroweaver or translater works right then we could use that for supporting 1.4 people a bit more.johanOn 2/17/06, Jesse Sightler [EMAIL PROTECTED] wrote: I tend to agree... could we perhaps have another thread for a formal vote? I've read through this thread and I just don't see that many people who both don't want 1.5 and do want the constructor change.Perhaps a survey like: 1. I need the constructor change NOW, but don't want 1.52. I don't care about the constructor change, do them whenever you want3. I don't want either one (just to catch the obstinate types:))I honestly think the do them separate types were mostly just wanting the 1.5 delayed a bit, and don't really care if there's a formal release with just the constructor change or not (but, of course, just IMO).Thanks,Jess http://www.jroller.com/page/jsight/ On 2/16/06, Justin Lee [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE-Hash: RIPEMD160The constructor change is going to be disruptive enough that maybeswitching both at once wouldn't be so bad.That'd mean only twobranches to maintain which would be a lot less work on you guys.That'd be my vote.It sucks for those who can't upgrade to 1.5 yet, but youhave to make sure you're not making too much work for yourself.And 3branches could get ugly fast.Eelco Hillenius wrote: Yeah, that would mean supporting 1.2 and 1.3 as branches. 2.0 would be HEAD. For us it would be way less work if we'd move to 1.2 directly. But that would probably be a bummer for people that don't want to make the move to JDK 5, but who do want to take advantage of the constructor change. Eelco On 2/16/06, Philip A. Chapman [EMAIL PROTECTED] wrote: Eelco Hillenius wrote: SNIP Only thing for us is that we have to support both 1.2 and 1.3. Does that mean supporting 3 branches;1.2, 1.3 and eventually 2.0?Or did you mean support 1.2 and 1.3 until 2.0 comes out; then supporting 1.3 and 2.0? Just curious on how much I should pity the committers. -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user- --Justin Lee http://www.antwerkz.com AIM : evan chooly720.299.0101-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (Cygwin)iD8DBQFD9LudJnQfEGuJ90MRA0EEAJ985iq9DWPAG4RHekGmqiOkqyisBgCeOw2t81qP9GYOjffV+aYOkyhzywQ==67QW-END PGP SIGNATURE- ---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
I agree with Justin, if you are already introducing a break, put them all into 1 release. Let's say you break the constructors (I'm sorry I'm not farmiliar exactly with what was refactored) and then a certain number of people re-normalize ontop of it, then you break it all over again for Java 5, just break it all at once. On 2/16/06, Justin Lee [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE-Hash: RIPEMD160The constructor change is going to be disruptive enough that maybeswitching both at once wouldn't be so bad.That'd mean only twobranches to maintain which would be a lot less work on you guys.That'd be my vote.It sucks for those who can't upgrade to 1.5 yet, but youhave to make sure you're not making too much work for yourself.And 3branches could get ugly fast.Eelco Hillenius wrote: Yeah, that would mean supporting 1.2 and 1.3 as branches. 2.0 would be HEAD. For us it would be way less work if we'd move to 1.2 directly. But that would probably be a bummer for people that don't want to make the move to JDK 5, but who do want to take advantage of the constructor change. Eelco On 2/16/06, Philip A. Chapman [EMAIL PROTECTED] wrote: Eelco Hillenius wrote: SNIP Only thing for us is that we have to support both 1.2 and 1.3. Does that mean supporting 3 branches;1.2, 1.3 and eventually 2.0?Or did you mean support 1.2 and 1.3 until 2.0 comes out; then supporting 1.3 and 2.0? Just curious on how much I should pity the committers. -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user- --Justin Leehttp://www.antwerkz.com AIM : evan chooly720.299.0101-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (Cygwin)iD8DBQFD9LudJnQfEGuJ90MRA0EEAJ985iq9DWPAG4RHekGmqiOkqyisBgCeOw2t81qP9GYOjffV+aYOkyhzywQ==67QW-END PGP SIGNATURE- ---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
The difference between these two changes is though, that people can always 'fix' their code to work with the constructor change, but they might not be able to move to Java 5 due to external factors (ie they can't run on a platform with Java 5 support). Eelco On 2/16/06, Riyad Kalla [EMAIL PROTECTED] wrote: I agree with Justin, if you are already introducing a break, put them all into 1 release. Let's say you break the constructors (I'm sorry I'm not farmiliar exactly with what was refactored) and then a certain number of people re-normalize ontop of it, then you break it all over again for Java 5, just break it all at once. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
*puts on his Vote for Igor shirt*On 2/16/06, Johan Compagner [EMAIL PROTECTED] wrote: igor is ofcourse 100% right !We all should really listen to what igor has to say on this matter!!I always completely agree with igor! We all should follow him!!johan On 2/16/06, Igor Vaynberg [EMAIL PROTECTED] wrote: it doesnt matter how the post started, you have to read the entire thing.first he said what the constructor refactor isthen he asked when we should do it.there was never a question of /how/ the refactor will look. furthermore, i asked gili not to post any discussion into /this/ thread. is that so difficult? i never told him not to discuss it, just not to do it here. if he wants to gain insight as to why we chose to do the refactor like we did, that is fine, but once again, not in this thread. this is absolutely the last message i am posting about this. i have very little free time and so i do not want to waste other people's time on reading this because i know it sucks.-Igor On 2/16/06, Timo Stamm [EMAIL PROTECTED] wrote: Igor Vaynberg schrieb: first of all we have already decided that this is going to happen. there was a vote and it passed. this is what the original posting by martijn implied, he asked for /when/ not /how/. Martijns post started with the following sentence (emphasis mine):| We are of course very busy finalizing Wicket 1.2, and we /really/ hope| to get it done soon. This will benefit everyone. So I want to take a | look beyond 1.2 and try to *get some opinions on our roadmap*, and| *adjust where appropiate*.Where did he ask /when/ to make the changes? I can't find that questionin the entire original posting. You are the committers, you have the best insight into wicket, youreceive the most user feedback and you are probably in the best positionto decide which changes are necessary. I don't want to question that. But the original posting did seem like a request for discussion, sopeople started a discussion. It's just a misunderstanding, and itreconfirmes once again that one should be extra verbose in allcommunications that are not face-to-face communication. Timo---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
it doesnt matter how the post started, you have to read the entire thing.first he said what the constructor refactor isthen he asked when we should do it.there was never a question of /how/ the refactor will look. furthermore, i asked gili not to post any discussion into /this/ thread. is that so difficult? i never told him not to discuss it, just not to do it here. if he wants to gain insight as to why we chose to do the refactor like we did, that is fine, but once again, not in this thread. this is absolutely the last message i am posting about this. i have very little free time and so i do not want to waste other people's time on reading this because i know it sucks.-Igor On 2/16/06, Timo Stamm [EMAIL PROTECTED] wrote: Igor Vaynberg schrieb: first of all we have already decided that this is going to happen. there was a vote and it passed. this is what the original posting by martijn implied, he asked for /when/ not /how/. Martijns post started with the following sentence (emphasis mine):| We are of course very busy finalizing Wicket 1.2, and we /really/ hope| to get it done soon. This will benefit everyone. So I want to take a | look beyond 1.2 and try to *get some opinions on our roadmap*, and| *adjust where appropiate*.Where did he ask /when/ to make the changes? I can't find that questionin the entire original posting. You are the committers, you have the best insight into wicket, youreceive the most user feedback and you are probably in the best positionto decide which changes are necessary. I don't want to question that. But the original posting did seem like a request for discussion, sopeople started a discussion. It's just a misunderstanding, and itreconfirmes once again that one should be extra verbose in allcommunications that are not face-to-face communication. Timo---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
igor is ofcourse 100% right !We all should really listen to what igor has to say on this matter!!I always completely agree with igor! We all should follow him!!johan On 2/16/06, Igor Vaynberg [EMAIL PROTECTED] wrote: it doesnt matter how the post started, you have to read the entire thing.first he said what the constructor refactor isthen he asked when we should do it.there was never a question of /how/ the refactor will look. furthermore, i asked gili not to post any discussion into /this/ thread. is that so difficult? i never told him not to discuss it, just not to do it here. if he wants to gain insight as to why we chose to do the refactor like we did, that is fine, but once again, not in this thread. this is absolutely the last message i am posting about this. i have very little free time and so i do not want to waste other people's time on reading this because i know it sucks.-Igor On 2/16/06, Timo Stamm [EMAIL PROTECTED] wrote: Igor Vaynberg schrieb: first of all we have already decided that this is going to happen. there was a vote and it passed. this is what the original posting by martijn implied, he asked for /when/ not /how/. Martijns post started with the following sentence (emphasis mine):| We are of course very busy finalizing Wicket 1.2, and we /really/ hope| to get it done soon. This will benefit everyone. So I want to take a | look beyond 1.2 and try to *get some opinions on our roadmap*, and| *adjust where appropiate*.Where did he ask /when/ to make the changes? I can't find that questionin the entire original posting. You are the committers, you have the best insight into wicket, youreceive the most user feedback and you are probably in the best positionto decide which changes are necessary. I don't want to question that. But the original posting did seem like a request for discussion, sopeople started a discussion. It's just a misunderstanding, and itreconfirmes once again that one should be extra verbose in allcommunications that are not face-to-face communication. Timo---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
So, if we wrap up this thread, I think this is roughly the outcome: Most people are +1 on the JDK 5 move. About half (not an exact count) think we should do do it in one release, the others think seperately is a better idea. I think having seperate releases (1.3. for the constructor change, 2.0 for JDK 5) makes sense as people that are +1 for having it in one release can just skip 1.3. and having the same effect. Only thing for us is that we have to support both 1.2 and 1.3. Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Eelco Hillenius wrote: SNIP Only thing for us is that we have to support both 1.2 and 1.3. Does that mean supporting 3 branches; 1.2, 1.3 and eventually 2.0? Or did you mean support 1.2 and 1.3 until 2.0 comes out; then supporting 1.3 and 2.0? Just curious on how much I should pity the committers. -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP signature.asc Description: OpenPGP digital signature
Re: [Wicket-user] Post 1.2 roadmap
Yeah, that would mean supporting 1.2 and 1.3 as branches. 2.0 would be HEAD. For us it would be way less work if we'd move to 1.2 directly. But that would probably be a bummer for people that don't want to make the move to JDK 5, but who do want to take advantage of the constructor change. Eelco On 2/16/06, Philip A. Chapman [EMAIL PROTECTED] wrote: Eelco Hillenius wrote: SNIP Only thing for us is that we have to support both 1.2 and 1.3. Does that mean supporting 3 branches; 1.2, 1.3 and eventually 2.0? Or did you mean support 1.2 and 1.3 until 2.0 comes out; then supporting 1.3 and 2.0? Just curious on how much I should pity the committers. -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 The constructor change is going to be disruptive enough that maybe switching both at once wouldn't be so bad. That'd mean only two branches to maintain which would be a lot less work on you guys. That'd be my vote. It sucks for those who can't upgrade to 1.5 yet, but you have to make sure you're not making too much work for yourself. And 3 branches could get ugly fast. Eelco Hillenius wrote: Yeah, that would mean supporting 1.2 and 1.3 as branches. 2.0 would be HEAD. For us it would be way less work if we'd move to 1.2 directly. But that would probably be a bummer for people that don't want to make the move to JDK 5, but who do want to take advantage of the constructor change. Eelco On 2/16/06, Philip A. Chapman [EMAIL PROTECTED] wrote: Eelco Hillenius wrote: SNIP Only thing for us is that we have to support both 1.2 and 1.3. Does that mean supporting 3 branches; 1.2, 1.3 and eventually 2.0? Or did you mean support 1.2 and 1.3 until 2.0 comes out; then supporting 1.3 and 2.0? Just curious on how much I should pity the committers. -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - -- Justin Lee http://www.antwerkz.com AIM : evan chooly 720.299.0101 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) iD8DBQFD9LudJnQfEGuJ90MRA0EEAJ985iq9DWPAG4RHekGmqiOkqyisBgCeOw2t 81qP9GYOjffV+aYOkyhzywQ= =67QW -END PGP SIGNATURE- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Certainly true. On 2/16/06, Justin Lee [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 The constructor change is going to be disruptive enough that maybe switching both at once wouldn't be so bad. That'd mean only two branches to maintain which would be a lot less work on you guys. That'd be my vote. It sucks for those who can't upgrade to 1.5 yet, but you have to make sure you're not making too much work for yourself. And 3 branches could get ugly fast. Eelco Hillenius wrote: Yeah, that would mean supporting 1.2 and 1.3 as branches. 2.0 would be HEAD. For us it would be way less work if we'd move to 1.2 directly. But that would probably be a bummer for people that don't want to make the move to JDK 5, but who do want to take advantage of the constructor change. Eelco On 2/16/06, Philip A. Chapman [EMAIL PROTECTED] wrote: Eelco Hillenius wrote: SNIP Only thing for us is that we have to support both 1.2 and 1.3. Does that mean supporting 3 branches; 1.2, 1.3 and eventually 2.0? Or did you mean support 1.2 and 1.3 until 2.0 comes out; then supporting 1.3 and 2.0? Just curious on how much I should pity the committers. -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - -- Justin Lee http://www.antwerkz.com AIM : evan chooly 720.299.0101 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) iD8DBQFD9LudJnQfEGuJ90MRA0EEAJ985iq9DWPAG4RHekGmqiOkqyisBgCeOw2t 81qP9GYOjffV+aYOkyhzywQ= =67QW -END PGP SIGNATURE- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
I think is better make the tow changes in 1.3, i think is less work for you the developers and for us end users. On 2/16/06, Eelco Hillenius [EMAIL PROTECTED] wrote: Certainly true. On 2/16/06, Justin Lee [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 The constructor change is going to be disruptive enough that maybe switching both at once wouldn't be so bad. That'd mean only two branches to maintain which would be a lot less work on you guys. That'd be my vote. It sucks for those who can't upgrade to 1.5 yet, but you have to make sure you're not making too much work for yourself. And 3 branches could get ugly fast. Eelco Hillenius wrote: Yeah, that would mean supporting 1.2 and 1.3 as branches. 2.0 would be HEAD. For us it would be way less work if we'd move to 1.2 directly. But that would probably be a bummer for people that don't want to make the move to JDK 5, but who do want to take advantage of the constructor change. Eelco On 2/16/06, Philip A. Chapman [EMAIL PROTECTED] wrote: Eelco Hillenius wrote: SNIP Only thing for us is that we have to support both 1.2 and 1.3. Does that mean supporting 3 branches; 1.2, 1.3 and eventually 2.0? Or did you mean support 1.2 and 1.3 until 2.0 comes out; then supporting 1.3 and 2.0? Just curious on how much I should pity the committers. -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - -- Justin Lee http://www.antwerkz.com AIM : evan chooly 720.299.0101 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) iD8DBQFD9LudJnQfEGuJ90MRA0EEAJ985iq9DWPAG4RHekGmqiOkqyisBgCeOw2t 81qP9GYOjffV+aYOkyhzywQ= =67QW -END PGP SIGNATURE- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- play tetris http://pepone.on-rez.com/tetris --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Hey, What about RFE 1249933? It would be really useful to have more formal CSS/JS support in Wicket such that we can use them as markup files and insert dynamic elements. We can currently hack this though without formal support there is no previewability and it's definitely harder to maintain. Gili --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
I tend to agree... could we perhaps have another thread for a formal vote? I've read through this thread and I just don't see that many people who both don't want 1.5 and do want the constructor change.Perhaps a survey like: 1. I need the constructor change NOW, but don't want 1.52. I don't care about the constructor change, do them whenever you want3. I don't want either one (just to catch the obstinate types:))I honestly think the do them separate types were mostly just wanting the 1.5 delayed a bit, and don't really care if there's a formal release with just the constructor change or not (but, of course, just IMO).Thanks,Jesshttp://www.jroller.com/page/jsight/ On 2/16/06, Justin Lee [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE-Hash: RIPEMD160The constructor change is going to be disruptive enough that maybeswitching both at once wouldn't be so bad.That'd mean only twobranches to maintain which would be a lot less work on you guys.That'd be my vote.It sucks for those who can't upgrade to 1.5 yet, but youhave to make sure you're not making too much work for yourself.And 3branches could get ugly fast.Eelco Hillenius wrote: Yeah, that would mean supporting 1.2 and 1.3 as branches. 2.0 would be HEAD. For us it would be way less work if we'd move to 1.2 directly. But that would probably be a bummer for people that don't want to make the move to JDK 5, but who do want to take advantage of the constructor change. Eelco On 2/16/06, Philip A. Chapman [EMAIL PROTECTED] wrote: Eelco Hillenius wrote: SNIP Only thing for us is that we have to support both 1.2 and 1.3. Does that mean supporting 3 branches;1.2, 1.3 and eventually 2.0?Or did you mean support 1.2 and 1.3 until 2.0 comes out; then supporting 1.3 and 2.0? Just curious on how much I should pity the committers. -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user- --Justin Leehttp://www.antwerkz.com AIM : evan chooly720.299.0101-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (Cygwin)iD8DBQFD9LudJnQfEGuJ90MRA0EEAJ985iq9DWPAG4RHekGmqiOkqyisBgCeOw2t81qP9GYOjffV+aYOkyhzywQ==67QW-END PGP SIGNATURE- ---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Gili wrote: From past experience, whenever classes require arguments in their constructors there is always some flexibility lost. For example, you absolutely cannot invoke any code before super() if you subclass such a class so if the value of one of the arguments needs to be calculated or modified in any way prior to the super() call you're out of luck. Very true. It was only yesterday that it took me 4 hours to debug a very small piece of code, only to find out that the Swing base-class called my overridden method from the constructor. Yikes! Erik. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
How is this method any different with our current Component.setParent(), called in Component.add() Then we still don't have the parent (==page) already available in the constructor.And what does that last part (flexibility lost) have to do with adding a parent in the constructor You just have to pass that thing through nothing more.johanOn 2/15/06, Gili [EMAIL PROTECTED] wrote:Instead of introducing extra arguments to the constructor, why not simply move all this logic into a new method?That is, introduce Component.bind(Component parent). We'd benefit fromthe fact that Wicket components could become JavaBeans and method-basedbinding is more flexible than constructor-based binding. From past experience, whenever classes require arguments in theirconstructors there is always some flexibility lost. For example, youabsolutely cannot invoke any code before super() if you subclass such a class so if the value of one of the arguments needs to be calculated ormodified in any way prior to the super() call you're out of luck.GiliTimo Stamm wrote: Johan Compagner schrieb: that would be very hard to maintain. For example if you have a panel that is rewritten by using only the new parent in constructor params. And you add that in youre own webpage/panel that doesn't use that parent in constructor param. Then you get all kind of errors because the child panel expect to have it all but because of the hierarchy problem that we have then, he doesn't have it. So i do think it is all or nothing. I see, thanks for the explanation. -1 for constructor change. On 2/14/06, Timo Stamm [EMAIL PROTECTED] wrote: Martijn Dashorst schrieb:- constructor refactor Wow, that's a /major/ change and will probably effect every custom component and every application written using Wicket. I see the benefit of having a complete component hierarchy availably right at the initialization of a class. But wouldn't it suffice to just make the new constructors available, and put a clear statement in the API docs? Then maybe deprecate the public add() in the next major version, and drop it in 2.0 or something like that? This opens up a lot of better markup parsing strategies for the core. Just get rid of markup, it sucks anyway ;) - java 5 support +1 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user-- http://www.desktopbeautifier.com/---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
I know I'm not an wicket expert. But would it help to change the constructors in wicket to factory methods? On 2/15/06, Johan Compagner [EMAIL PROTECTED] wrote: How is this method any different with our current Component.setParent(), called in Component.add() Then we still don't have the parent (==page) already available in the constructor. And what does that last part (flexibility lost) have to do with adding a parent in the constructor You just have to pass that thing through nothing more. johan On 2/15/06, Gili [EMAIL PROTECTED] wrote: Instead of introducing extra arguments to the constructor, why not simply move all this logic into a new method? That is, introduce Component.bind(Component parent). We'd benefit from the fact that Wicket components could become JavaBeans and method-based binding is more flexible than constructor-based binding. From past experience, whenever classes require arguments in their constructors there is always some flexibility lost. For example, you absolutely cannot invoke any code before super() if you subclass such a class so if the value of one of the arguments needs to be calculated or modified in any way prior to the super() call you're out of luck. Gili Timo Stamm wrote: Johan Compagner schrieb: that would be very hard to maintain. For example if you have a panel that is rewritten by using only the new parent in constructor params. And you add that in youre own webpage/panel that doesn't use that parent in constructor param. Then you get all kind of errors because the child panel expect to have it all but because of the hierarchy problem that we have then, he doesn't have it. So i do think it is all or nothing. I see, thanks for the explanation. -1 for constructor change. On 2/14/06, Timo Stamm [EMAIL PROTECTED] wrote: Martijn Dashorst schrieb: - constructor refactor Wow, that's a /major/ change and will probably effect every custom component and every application written using Wicket. I see the benefit of having a complete component hierarchy availably right at the initialization of a class. But wouldn't it suffice to just make the new constructors available, and put a clear statement in the API docs? Then maybe deprecate the public add() in the next major version, and drop it in 2.0 or something like that? This opens up a lot of better markup parsing strategies for the core. Just get rid of markup, it sucks anyway ;) - java 5 support +1 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- http://www.desktopbeautifier.com/ --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
You have a big problem when a class depends on the behavior of a sub-class during construction time. This is because sub-classes are initialized after the initialization of the base-class. When there is no dependency, there is no problem. So, although I recognize Gili's point in general, I think Johan is right here: just passing the thing can't be a serious problem. Erik. Johan Compagner wrote: How is this method any different with our current Component.setParent(), called in Component.add() Then we still don't have the parent (==page) already available in the constructor. And what does that last part (flexibility lost) have to do with adding a parent in the constructor You just have to pass that thing through nothing more. johan --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
urghhHow would factory methods help?and how would i use standaard factory methods to create components/panels and the like?What then when i want to construct this panel:MyPanel(Container parent, MyObject object, int size)
{}On 2/15/06, Jesper Preuss [EMAIL PROTECTED] wrote:
I know I'm not an wicket expert. But would it help to change theconstructors in wicket to factory methods?On 2/15/06, Johan Compagner [EMAIL PROTECTED] wrote:
How is this method any different with our current Component.setParent(), called in Component.add() Then we still don't have the parent (==page) already available in the constructor.
And what does that last part (flexibility lost) have to do with adding a parent in the constructor You just have to pass that thing through nothing more. johan On 2/15/06, Gili
[EMAIL PROTECTED] wrote: Instead of introducing extra arguments to the constructor, why not simply move all this logic into a new method?
That is, introduce Component.bind(Component parent). We'd benefit from the fact that Wicket components could become JavaBeans and method-based binding is more flexible than constructor-based binding.
>From past experience, whenever classes require arguments in their constructors there is always some flexibility lost. For example, you absolutely cannot invoke any code before super() if you subclass such a
class so if the value of one of the arguments needs to be calculated or modified in any way prior to the super() call you're out of luck. Gili Timo Stamm wrote:
Johan Compagner schrieb: that would be very hard to maintain. For example if you have a panel that is rewritten by using only the new parent in constructor params.
And you add that in youre own webpage/panel that doesn't use that parent in constructor param. Then you get all kind of errors because the child panel expect to have
it all but because of the hierarchy problem that we have then, he doesn't have it. So i do think it is all or nothing.
I see, thanks for the explanation. -1 for constructor change. On 2/14/06, Timo Stamm
[EMAIL PROTECTED] wrote: Martijn Dashorst schrieb: - constructor refactor Wow, that's a /major/ change and will probably effect every custom
component and every application written using Wicket. I see the benefit of having a complete component hierarchy availably right at the initialization of a class.
But wouldn't it suffice to just make the new constructors available, and put a clear statement in the API docs? Then maybe deprecate the public
add() in the next major version, and drop it in 2.0 or something like that? This opens up a lot of better markup parsing strategies for
the core. Just get rid of markup, it sucks anyway ;) - java 5 support
+1 ---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes
searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___
Wicket-user mailing list Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user -- http://www.desktopbeautifier.com/
--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes
searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user ---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
This is what seems the safest to me... - v1.2 : Stop adding features RC/Release it :-) - v1.3 : v1.2 + Constructor Change + /maybe/ minimal other (ajax?) changes... (Try *really* hard not to feature-creep!) - v2.0 : Requies Java 1.5 (Try to release sometime before Java 1.6 ships!) /Gwyn On 14/02/06, Eelco Hillenius [EMAIL PROTECTED] wrote: Here are mine: The questions I'm seeking answers to are the following: - should the post 1.2 version of Wicket involve both changes? No. The constructor changes first, we can call it 1.3, and that version should be primarily just that change and some minor ones around it. - should we make different releases for either change, and thus postponing 1.5 to Wicket 3? Yes. If we call the constructor change Wicket 1.3, we can call the JDK 1.5 version Wicket 2.0. - how many of you still require for current or future projects to run on JDK 1.4? - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run 1.5 code on a 1.4 JRE? I agree with Igor that we should move to 1.5, and don't wait for a year to do it. Not everyone will be happy with it, but we'll have a very decent version out with 1.3 which we should support for a long time (by which I mean bug fixing, not so much back porting new features). Moving to 1.5 will eleminate a few of the weak features we still have and can't fix. As Wicket is all about Java code and strong typing, it sucks we can't have that strong typing in one of our major concepts yet - the model. With generics we can have this. I think that alone is worth the move, and as a lot of other frameworks - either for UI stuff or other purposes - already moved to 1.5, I don't think it is too early. We are already a year further since our first 1.5 discussions. Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
we have considered both options when figuring out the solution. we called it init() instead of bind() but it was basically the same thing.here are some advantages of a constructor over an init() method:1) constructors are atomic 2) an exception thrown from a constructor will prevent the object from being created (security)3) constructor parameters are much easier to pass. if you have a parameter that you want to pass from a constructor you would have to store it as a field so it is available in init(), this makes things really really dirty and break encapsulation. 4) constructors insure the proper order of creation. you cant have things like. Panel p1=new Panel(); p2=new Panel(); p2.init(p1) == error because p1 hasnt been initted and bound to the page yet.5) constructors, as the name implies, are used for constructing things in java. 6) constructors give component creators the ability to use the good citizen patternso in the end using construcors leads to a much more concise and clear code both for component creators and component users. also saying things vague like its better because components can be javabeans doesnt mean much. why not give arguments as to /why/ it would be better to have components as javabeans.anyways, this is not what this thread was about. if anyone is interested in discussing any of the points above please start a different thread. -IgorOn 2/14/06, Gili [EMAIL PROTECTED] wrote: Instead of introducing extra arguments to the constructor, why notsimply move all this logic into a new method? That is, introduce Component.bind(Component parent). We'd benefit fromthe fact that Wicket components could become JavaBeans and method-basedbinding is more flexible than constructor-based binding. From past experience, whenever classes require arguments in theirconstructors there is always some flexibility lost. For example, youabsolutely cannot invoke any code before super() if you subclass such a class so if the value of one of the arguments needs to be calculated ormodified in any way prior to the super() call you're out of luck.GiliTimo Stamm wrote: Johan Compagner schrieb: that would be very hard to maintain. For example if you have a panel that is rewritten by using only the new parent in constructor params. And you add that in youre own webpage/panel that doesn't use that parent in constructor param. Then you get all kind of errors because the child panel expect to have it all but because of the hierarchy problem that we have then, he doesn't have it. So i do think it is all or nothing. I see, thanks for the explanation. -1 for constructor change. On 2/14/06, Timo Stamm [EMAIL PROTECTED] wrote: Martijn Dashorst schrieb:- constructor refactor Wow, that's a /major/ change and will probably effect every custom component and every application written using Wicket. I see the benefit of having a complete component hierarchy availably right at the initialization of a class. But wouldn't it suffice to just make the new constructors available, and put a clear statement in the API docs? Then maybe deprecate the public add() in the next major version, and drop it in 2.0 or something like that? This opens up a lot of better markup parsing strategies for the core. Just get rid of markup, it sucks anyway ;) - java 5 support +1 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- http://www.desktopbeautifier.com/---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Yes, it uses concurrent-backport.On 2/14/06, Mark Derricutt [EMAIL PROTECTED] wrote: On 2/15/06, Jesse Sightler [EMAIL PROTECTED] wrote: Actually, the really nice thing about Retrotranslator (as opposed to Retroweaver) is that it does support quite a few of the new Java 1.5 APIs. java.util.concurrent and StringBuilder are both supported. Interesting - does it make use of the concurrent-backport and map the bytecode over?-- i like my video games - mamma said they are gonna melt my brains i like my video games - i don't care what daddy said; they're my reality - henning pauly
Re: [Wicket-user] Post 1.2 roadmap
Replies below... Igor Vaynberg wrote: we have considered both options when figuring out the solution. we called it init() instead of bind() but it was basically the same thing. here are some advantages of a constructor over an init() method: 1) constructors are atomic Wicket components have always been thread-unsafe by design, so I fail to see how this is relevant. Do you plan on sharing Wicket components across threads anytime soon? Just define Component.isInit() and set it to true if a component has been initialized, and prevent double-initialization. 2) an exception thrown from a constructor will prevent the object from being created (security) Correct me if I'm wrong (you probably know more about this issue than me) but isn't the real security concern whether or not the Component may be rendered as opposed to whether or not it may be constructed? For example, normal users do not have admin access, so they should not be able to visit admin-only WebPages. You could enforce this security check at render time. 3) constructor parameters are much easier to pass. if you have a parameter that you want to pass from a constructor you would have to store it as a field so it is available in init(), this makes things really really dirty and break encapsulation. I think that is subjective. All JavaBeans work this way (if you need to use a variable later on, you are forced to store it as a field) but this has never bothered me. I already do this kind of thing with Wicket when I need a variable at render time (this happens quite often). In my view, this is no more ugly. 4) constructors insure the proper order of creation. you cant have things like. Panel p1=new Panel(); p2=new Panel(); p2.init(p1) == error because p1 hasnt been initted and bound to the page yet. The situation you describe exists with the current implementation (i.e. this is nothing new). IMHO this is common sense. I don't think anyone would find it confusing. 5) constructors, as the name implies, are used for constructing things in java. Right, but we're not constructing, we're binding. A WebPage floating in space is just fine. You should be able to use a constructor to create such an instance. Using Swing as an example (since Wicket is based upon it), you often create a component using a constructor and bind it using add() or setParent(). 6) constructors give component creators the ability to use the good citizen pattern so in the end using construcors leads to a much more concise and clear code both for component creators and component users. also saying things vague like its better because components can be javabeans doesnt mean much. why not give arguments as to /why/ it would be better to have components as javabeans. For one, many frameworks play very nicely with JavaBeans. If Wicket components were beans we could seamlessly plug them into things like XMLEncoder and the various bean APIs that manipulate them. anyways, this is not what this thread was about. if anyone is interested in discussing any of the points above please start a different thread. This discussion is regarding whether or not we should be passing the parent into the constructor as opposed to the current add() mechanism. I would argue that the current discussion is quite relevant in that we are trying to give our feedback on this proposal. I'm not arguing against the existence of constructors just for the sake of argument. Gili --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
1) constructors are atomic Wicket components have always been thread-unsafe by design, so I fail to see how this is relevant. Do you plan on sharing Wicket components across threads anytime soon? Just define Component.isInit() and set it to true if a component has been initialized, and prevent double-initialization. Atomic != threadsafe. See http://en.wikipedia.org/wiki/Atomicity. Either a component's construction completes including the parents it is added, or not. One of the side effects of the add method is that the hierarchical position of the component is postponed until it is added to a parent, and even then the action is not complete, as those components might still need to be added to their parents. 2) an exception thrown from a constructor will prevent the object from being created (security) Correct me if I'm wrong (you probably know more about this issue than me) but isn't the real security concern whether or not the Component may be rendered as opposed to whether or not it may be constructed? For example, normal users do not have admin access, so they should not be able to visit admin-only WebPages. You could enforce this security check at render time. It's just the concept of fail early. It is generally a good idea in programming to fail as early as possible if you know you are going to fail. Objects might be expensive to create etc. 3) constructor parameters are much easier to pass. if you have a parameter that you want to pass from a constructor you would have to store it as a field so it is available in init(), this makes things really really dirty and break encapsulation. I think that is subjective. All JavaBeans work this way (if you need to use a variable later on, you are forced to store it as a field) but this has never bothered me. I already do this kind of thing with Wicket when I need a variable at render time (this happens quite often). In my view, this is no more ugly. If you want to tighten things up and force users of your class to provide it's dependencies at construction time, requiring constructor arguments is a robust technique. This is not a new concept, and even has been one of the main battle arguments in the constructor vs property dependency IoC camp. We don't have to join that discussion though, as we are not building a managed IoC framework. 4) constructors insure the proper order of creation. you cant have things like. Panel p1=new Panel(); p2=new Panel(); p2.init(p1) == error because p1 hasnt been initted and bound to the page yet. The situation you describe exists with the current implementation (i.e. this is nothing new). IMHO this is common sense. I don't think anyone would find it confusing. I made mistakes with it. Why wouldn't anyone else? Furthermore, lots of times you don't own the whole component creation code, giving rise to more uncertainties. 5) constructors, as the name implies, are used for constructing things in java. Right, but we're not constructing, we're binding. A WebPage floating in space is just fine. You should be able to use a constructor to create such an instance. Using Swing as an example (since Wicket is based upon it), you often create a component using a constructor and bind it using add() or setParent(). As we want component creation and setting of parents to be atomic, we are not merely binding. A component floating into space has problems, particalarly if you depend on its place in the hierarchy in the constructor. This is not just theory. People are having troubles with this, especially when it comes to ajax/ javascript integration and component interaction. This discussion is regarding whether or not we should be passing the parent into the constructor as opposed to the current add() mechanism. I would argue that the current discussion is quite relevant in that we are trying to give our feedback on this proposal. I'm not arguing against the existence of constructors just for the sake of argument. No 'we' (the committers) decided on using the constructor pattern and were asking you about your opinion as to when this should be implement. Or actually, whether this change should be made together with the move to JDK 5. Here is what Martijn asked: quote The questions I'm seeking answers to are the following: - should the post 1.2 version of Wicket involve both changes? - should we make different releases for either change, and thus postponing 1.5 to Wicket 3? - how many of you still require for current or future projects to run on JDK 1.4? - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run 1.5 code on a 1.4 JRE? /quote Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy
Re: [Wicket-user] Post 1.2 roadmap
first of all we have already decided that this is going to happen. there was a vote and it passed. this is what the original posting by martijn implied, he asked for /when/ not /how/.second of all i asked you to not post any discussion of this to this thread, i really dont understand why this is so difficult. can you not follow simple directions? why do you add noise to what already is a busy thread? why should people who are interested in the outcome of this thread waste their time reading your off topic posts. my better judgement tells me to ignore your replies and not add any noise myself. but i am affraid that course of action is too implicit for you to understand, so i am making it very explicit hoping that the noise can stop at this. you are more then welcome to reply to this if you have anything further to say, but pelase do it in another thread.thank you,-IgorOn 2/15/06, Gili [EMAIL PROTECTED] wrote: Replies below...Igor Vaynberg wrote: we have considered both options when figuring out the solution. we called it init() instead of bind() but it was basically the same thing. here are some advantages of a constructor over an init() method: 1) constructors are atomicWicket components have always been thread-unsafe by design, so I failto see how this is relevant. Do you plan on sharing Wicket components across threads anytime soon? Just define Component.isInit() and set itto true if a component has been initialized, and preventdouble-initialization. 2) an exception thrown from a constructor will prevent the object from being created (security)Correct me if I'm wrong (you probably know more about this issue thanme) but isn't the real security concern whether or not the Component maybe rendered as opposed to whether or not it may be constructed? For example, normal users do not have admin access, so they should not beable to visit admin-only WebPages. You could enforce this security checkat render time. 3) constructor parameters are much easier to pass. if you have a parameter that you want to pass from a constructor you would have to store it as a field so it is available in init(), this makes things really really dirty and break encapsulation.I think that is subjective. All JavaBeans work this way (if you need to use a variable later on, you are forced to store it as a field) but thishas never bothered me. I already do this kind of thing with Wicket whenI need a variable at render time (this happens quite often). In my view, this is no more ugly. 4) constructors insure the proper order of creation. you cant have things like. Panel p1=new Panel(); p2=new Panel(); p2.init(p1) == error because p1 hasnt been initted and bound to the page yet. The situation you describe exists with the current implementation (i.e.this is nothing new). IMHO this is common sense. I don't think anyonewould find it confusing. 5) constructors, as the name implies, are used for constructing things in java.Right, but we're not constructing, we're binding. A WebPage floating inspace is just fine. You should be able to use a constructor to createsuch an instance. Using Swing as an example (since Wicket is based upon it), you often create a component using a constructor and bind it usingadd() or setParent(). 6) constructors give component creators the ability to use the good citizen pattern so in the end using construcors leads to a much more concise and clear code both for component creators and component users. also saying things vague like its better because components can be javabeans doesnt mean much. why not give arguments as to /why/ it would be better to have components as javabeans.For one, many frameworks play very nicely with JavaBeans. If Wicketcomponents were beans we could seamlessly plug them into things likeXMLEncoder and the various bean APIs that manipulate them. anyways, this is not what this thread was about. if anyone is interested in discussing any of the points above please start a different thread.This discussion is regarding whether or not we should be passing the parent into the constructor as opposed to the current add() mechanism. Iwould argue that the current discussion is quite relevant in that we aretrying to give our feedback on this proposal. I'm not arguing against the existence of constructors just for the sake of argument.Gili---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642___Wicket-user mailing list Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
We are starting a Wicket project, we use JDK 1.4 because our old software can't run on 1.5. It's a problem, to move to 1.5, but we will eventually do it. But will take a few years. So I vote for waiting with Java 1.5 until Wicket version 3.0. On 2/14/06, wang lei [EMAIL PROTECTED] wrote: Here is my opinions: - should the post 1.2 version of Wicket involve both changes? Absolutely not. I support the constructor change ,because it force the programmer to do in a right way. I don't want wicket support JDK1.5 soon. I know generics can bring many benefits.But there is a long time before most of us move to JDK1.5. Some projects from my clients are stilling run on JDK1.4 even JDK1.3.One year ,at least, is necessary for waiting. My clients would just move to JDK1.4 easily,because they need to pay a lot of money and not sure the old software can move to the new JDK easily. - should we make different releases for either change, and thus postponing 1.5 to Wicket 3? No, one version is enough. Wicket2 or wicket3 are not important. I think if you move to JDK1.5 too soon.You will lose many users.It's not good for wicket. Wicket still has a long way to go. - how many of you s till require for current or future projects to run on JDK 1.4? In fact,this question is suitable.Most time,the clients choose the platform,instead of us. Many clients are running different jdk, I can't predict. But for you,i would prefer JDK1.4. - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run 1.5 code on a 1.4 JRE? I never try to do that. 无限容量雅虎相册，原图等大下载，超快速度，赶快抢注！
Re: [Wicket-user] Post 1.2 roadmap
+1 for the Constructor refactoring to 1.3 +1 for Java 1.5 ASAP! I see more and more momentum for 1.5 out amongst our customers and the switch is going on already as more and more realise that it's really not such a scary move. And the fringing faces of the few bound to 1.4 should be weighted to the awe of all not-yet-wicketeers when they discover this extraterrestially excellent framework! Why delay excellency? ;-) | Per Ejeklint Mobile: +46 (0)70-5090052 Web: http://www.ejeklint.se Skype: callto://ejeklint --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
are we sure we just one to package that in the wicket.jar?Why not release it as a seperate jar? What is wrong with that? Then people can choose to use it or not.(just like extentions)We just have to sync the release cycle. On 2/14/06, Jonathan Locke [EMAIL PROTECTED] wrote: +1 on Java 5 sooner. for one thing, we can't fold the authentication package into the core until we adopt it. for another, the lack of typesafe models is something we ought to remedy as soon as we possibly can. so i like the idea of doing 1.3 VERY quickly (JUST the constructor change and associated ajax work over a few short weeks) and then immediately have HEAD for 2.0 be Java 5 based. and i'd like us to get 2.0 out pretty quickly too so that WIA can include stuff about typesafe models and so forth. On 2/13/06, Eelco Hillenius [EMAIL PROTECTED] wrote: Here are mine: The questions I'm seeking answers to are the following:- should the post 1.2 version of Wicket involve both changes?No. The constructor changes first, we can call it 1.3 , and thatversion should be primarily just that change and some minor onesaround it.- should we make different releases for either change, and thus postponing 1.5 toWicket 3? Yes. If we call the constructor change Wicket 1.3, we can call the JDK1.5 version Wicket 2.0.- how many of you still require for current or future projects to run on JDK 1.4?- how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run 1.5 code on a 1.4 JRE?I agree with Igor that we should move to 1.5, and don't wait for ayear to do it. Not everyone will be happy with it, but we'll have avery decent version out with 1.3 which we should support for a longtime (by which I mean bug fixing, not so much back porting newfeatures).Moving to 1.5 will eleminate a few of the weak features we still haveand can't fix. As Wicket is all about Java code and strong typing, it sucks we can't have that strong typing in one of our major conceptsyet - the model. With generics we can have this. I think that alone isworth the move, and as a lot of other frameworks - either for UI stuff or other purposes - already moved to 1.5, I don't think it is tooearly. We are already a year further since our first 1.5 discussions.Eelco--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___ Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
having 1.3 with constructor change and fixes and maybe one or 2 things more (ajax related) looks fine to meand then 2.0 with java 5 support.I will then try to backport most wanted features and bug fixes if possible because i can't use
1.5 because manymany customers don't run 1.5 on there servers. And i think that will be so for the comming year. So my focus willthen be on 1.3.XjohanOn 2/14/06,
Martijn Dashorst [EMAIL PROTECTED] wrote:
All,We are of course very busy finalizing Wicket 1.2, and we /really/ hopeto get it done soon. This will benefit everyone. So I want to take alook beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.There are two very big things ahead of us: - constructor refactorwe have reached a limit to the support we want to providefor Ajax and _javascript_. In order to provide the best support
we need to know the markup id before it is available. Manyhave been bitten by trying to retrieve an attribute from acomponent tag in the page constructor.We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the componentconstructor, which sets the parent of the component. public MyPage() {WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));c.add(new Label(bar2));c.add(new Label(bar3));add(c); } will become:
public MyPage() { WebMarkupContainer c = new WebMarkupContainer(this, foo); new TextField(c, bar1); new Label(c, bar2);
new Label(c, bar3); }This opens up a lot of better markup parsing strategies for thecore. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward. - java 5 supportThis is something a lot of people are waiting for. I understand thatmany people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,can't move to java 1.5 as a server platform. We don't know howmany users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only supportso many projects. Supporting both a 1.4 and 1.5 project willdrain our resources too far, and won't be possible. So we have to
make a choice.The questions I'm seeking answers to are the following: - should the post 1.2 version of Wicket involve both changes? - should we make different releases for either change, and thus
postponing 1.5 to Wicket 3? - how many of you still require for current or future projects to runon JDK 1.4? - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run
1.5 code on a 1.4 JRE?Thanks for your answers,Martijn--Living a wicket life...Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Java 5 support would be a really big plus
(esp. with tools like Retrotranslator and Retroweaver) for me as well.
We've tried Retroweaver with our desktop applications and it failed
completely for non-trivial stuff. A few days ago I've tried
Retrotranslator (did not know about it before) and so far I'm very happy
with it and not had any crash.
--
Cheers,
Tom
Jesse Sightler wrote:
I'm completely in favor of jumping to Wicket 2.0 and implementing both
of these changes with it. Java 5 support would be a really big plus
(esp. with tools like Retrotranslator and Retroweaver) for me as well.
I'm sure that won't be perfect for some people, but I think it is
reasonable to cut over now and keep a 1.2 version as a maintenance
branch.
--
Jess
On 2/13/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this, foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5 Wicket, which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing
Re: [Wicket-user] Post 1.2 roadmap
Martijn Dashorst schrieb: - constructor refactor Wow, that's a /major/ change and will probably effect every custom component and every application written using Wicket. I see the benefit of having a complete component hierarchy availably right at the initialization of a class. But wouldn't it suffice to just make the new constructors available, and put a clear statement in the API docs? Then maybe deprecate the public add() in the next major version, and drop it in 2.0 or something like that? This opens up a lot of better markup parsing strategies for the core. Just get rid of markup, it sucks anyway ;) - java 5 support +1 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Here is my opinion:+1 for the Constructor refactoring to 1.3 for JDK5 it's better to split another wicket-jdk5.jar so we can benefit from it *now*.And merging both together when wicket 2.5 or 3 finished.
I hope future wicket can buddle all fundamentals in one single package, say,
download one wicket-dep.zip that contains:wicket.jarwicket-jdk5.jarwicket-spring.jarwicket-spring-annot.jarwicket-auth-roles.jarwicket-auth-roles-anont.jaror even better, pack all into one big
wicket-all.jar just like Spring does.On 2/14/06,
Martijn Dashorst [EMAIL PROTECTED] wrote:
All,We are of course very busy finalizing Wicket 1.2, and we /really/ hopeto get it done soon. This will benefit everyone. So I want to take alook beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.There are two very big things ahead of us: - constructor refactorwe have reached a limit to the support we want to providefor Ajax and _javascript_. In order to provide the best support
we need to know the markup id before it is available. Manyhave been bitten by trying to retrieve an attribute from acomponent tag in the page constructor.We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the componentconstructor, which sets the parent of the component. public MyPage() {WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));c.add(new Label(bar2));c.add(new Label(bar3));add(c); }
will become:
public MyPage() { WebMarkupContainer c = new WebMarkupContainer(this, foo); new TextField(c, bar1); new Label(c, bar2);
new Label(c, bar3); }This opens up a lot of better markup parsing strategies for thecore. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward. - java 5 supportThis is something a lot of people are waiting for. I understand thatmany people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,can't move to java 1.5 as a server platform. We don't know howmany users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only supportso many projects. Supporting both a 1.4 and 1.5 project willdrain our resources too far, and won't be possible. So we have to
make a choice.The questions I'm seeking answers to are the following: - should the post 1.2 version of Wicket involve both changes? - should we make different releases for either change, and thus
postponing 1.5 to Wicket 3? - how many of you still require for current or future projects to runon JDK 1.4? - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run
1.5 code on a 1.4 JRE?Thanks for your answers,Martijn--Living a wicket life...Martijn Dashorst -
http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-- Ingram ChenJava [EMAIL PROTECTED]
Institue of BioMedical Sciences Academia Sinica Taiwanblog: http://www.javaworld.com.tw/roller/page/ingramchen
Re: [Wicket-user] Post 1.2 roadmap
that would be very hard to maintain.For example if you have a panel that is rewritten by using only the new parent in constructor params.And you add that in youre own webpage/panel that doesn't use that parent in constructor param. Then you get all kind of errors because the child panel expect to have it all but because of the hierarchy problem that we have then, he doesn't have it.So i do think it is all or nothing.johan On 2/14/06, Timo Stamm [EMAIL PROTECTED] wrote: Martijn Dashorst schrieb:- constructor refactorWow, that's a /major/ change and will probably effect every customcomponent and every application written using Wicket.I see the benefit of having a complete component hierarchy availably right at the initialization of a class.But wouldn't it suffice to just make the new constructors available, andput a clear statement in the API docs? Then maybe deprecate the publicadd() in the next major version, and drop it in 2.0 or something like that? This opens up a lot of better markup parsing strategies for the core.Just get rid of markup, it sucks anyway ;)- java 5 support +1---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
another java5 jar that is an add on for the normal wicket.jar?If we introduce generics i think it will be ALL over the place throughout the complete code base of wicket.There is no real seperation.johan
On 2/14/06, Ingram Chen [EMAIL PROTECTED] wrote:
Here is my opinion:+1 for the Constructor refactoring to 1.3 for JDK5 it's better to split another wicket-jdk5.jar so we can benefit from it *now*.And merging both together when wicket
2.5 or 3 finished.
I hope future wicket can buddle all fundamentals in one single package, say,
download one wicket-dep.zip that contains:wicket.jarwicket-jdk5.jarwicket-spring.jarwicket-spring-annot.jarwicket-auth-roles.jarwicket-auth-roles-anont.jaror even better, pack all into one big
wicket-all.jar just like Spring does.On 2/14/06,
Martijn Dashorst [EMAIL PROTECTED] wrote:
All,We are of course very busy finalizing Wicket 1.2, and we /really/ hopeto get it done soon. This will benefit everyone. So I want to take alook beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.There are two very big things ahead of us: - constructor refactorwe have reached a limit to the support we want to providefor Ajax and _javascript_. In order to provide the best support
we need to know the markup id before it is available. Manyhave been bitten by trying to retrieve an attribute from acomponent tag in the page constructor.We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the componentconstructor, which sets the parent of the component. public MyPage() {WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));c.add(new Label(bar2));c.add(new Label(bar3));add(c); }
will become:
public MyPage() { WebMarkupContainer c = new WebMarkupContainer(this, foo); new TextField(c, bar1); new Label(c, bar2);
new Label(c, bar3); }This opens up a lot of better markup parsing strategies for thecore. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward. - java 5 supportThis is something a lot of people are waiting for. I understand thatmany people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,can't move to java 1.5 as a server platform. We don't know howmany users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only supportso many projects. Supporting both a 1.4 and 1.5 project willdrain our resources too far, and won't be possible. So we have to
make a choice.The questions I'm seeking answers to are the following: - should the post 1.2 version of Wicket involve both changes? - should we make different releases for either change, and thus
postponing 1.5 to Wicket 3? - how many of you still require for current or future projects to runon JDK 1.4? - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run
1.5 code on a 1.4 JRE?Thanks for your answers,Martijn--Living a wicket life...Martijn Dashorst -
http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-- Ingram ChenJava [EMAIL PROTECTED]
Institue of BioMedical Sciences Academia Sinica Taiwanblog: http://www.javaworld.com.tw/roller/page/ingramchen
Re: [Wicket-user] Post 1.2 roadmap
Johan Compagner schrieb: that would be very hard to maintain. For example if you have a panel that is rewritten by using only the new parent in constructor params. And you add that in youre own webpage/panel that doesn't use that parent in constructor param. Then you get all kind of errors because the child panel expect to have it all but because of the hierarchy problem that we have then, he doesn't have it. So i do think it is all or nothing. I see, thanks for the explanation. -1 for constructor change. On 2/14/06, Timo Stamm [EMAIL PROTECTED] wrote: Martijn Dashorst schrieb: - constructor refactor Wow, that's a /major/ change and will probably effect every custom component and every application written using Wicket. I see the benefit of having a complete component hierarchy availably right at the initialization of a class. But wouldn't it suffice to just make the new constructors available, and put a clear statement in the API docs? Then maybe deprecate the public add() in the next major version, and drop it in 2.0 or something like that? This opens up a lot of better markup parsing strategies for the core. Just get rid of markup, it sucks anyway ;) - java 5 support +1 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
But wouldn't it suffice to just make the new constructors available, and put a clear statement in the API docs? Then maybe deprecate the public add() in the next major version, and drop it in 2.0 or something like that? That's an option we discussed, and as usual is has opponents and proponents. I am against this as we would end up doing extra work supporting it, probably resulting in a half baked solution. Furthermore, it wouldn't be enough incentive for people to make to move. I am always in favor of clarity and breaking early in these matters. Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
After reading everybody's posts and thinking what I myself would want to
have in future wicket releases:
JDK 1.5 support is here for too long not to have it in. I know it's
tough for the people who need to deploy on 1.4 in the future but Os is
supposed to drive innovation. How to do it if wicket doesn't get all the
marvels as generics and annotations in 1.5 while JDK 1.6 is almost beta
? It's gone too far :-), it's just my oppinion, please don't take it as
a critique, it's not. I just believe that in the end 1.5 will bring a
lot more good than bad to wicket users. And I suggest for us/others who
will need 1.4 to use a retrotranslated
(http://retrotranslator.sourceforge.net/ is alive and kicking, is
actively developed in contrast to retroweaver, and people report good
experiences with it) version of a Wicket for JDK 1.5.
Martijn Dashorst wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this, foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
preferable not
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
I'm the fortunate one, I can choose the paltform in the majority of my
company's projects. so go jdk1.5. I'm running 1.4 code on it anyway.
- how many would object to having a retroweaver build of a JDK 5 Wicket, which
enables you to run 1.5 code on a 1.4 JRE?
If it passes all the tests I believe it's acceptable.
Thanks for your answers,
Thanks a lot wicket team for your efforts. It feels bad not having the
time and skills to get involved in development.
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Yeah. One of our most important use of generics would be IModel. It's
just not possible to seperate that from core without having to
maintain seperate code bases.
Eelco
On 2/14/06, Johan Compagner [EMAIL PROTECTED] wrote:
another java5 jar that is an add on for the normal wicket.jar?
If we introduce generics i think it will be ALL over the place throughout
the complete code base of wicket.
There is no real seperation.
johan
On 2/14/06, Ingram Chen [EMAIL PROTECTED] wrote:
Here is my opinion:
+1 for the Constructor refactoring to 1.3
for JDK5 it's better to split another wicket-jdk5.jar so we can benefit
from it *now*.
And merging both together when wicket 2.5 or 3 finished.
I hope future wicket can buddle all fundamentals in one single package,
say,
download one wicket-dep.zip that contains:
wicket.jar
wicket-jdk5.jar
wicket-spring.jar
wicket-spring-annot.jar
wicket-auth-roles.jar
wicket-auth-roles-anont.jar
or even better, pack all into one big wicket-all.jar just like Spring
does.
On 2/14/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new
WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this,
foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is
necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand
that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of
you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only
support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have
to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5 Wicket,
which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out:
http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
Ingram Chen
Java [EMAIL PROTECTED]
Institue of BioMedical Sciences Academia Sinica Taiwan
blog: http://www.javaworld.com.tw/roller/page/ingramchen
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
Re: [Wicket-user] Post 1.2 roadmap
On Tuesday 14 Feb 2006 11:43, Eelco Hillenius wrote: move. I am always in favor of clarity and breaking early in these matters. I would certainly rather see wicket become a better framework than be held back by backwards compatibility. Those who are not willing to refactor their ui code can simply keep using wicket 1.2. It is a good product now and always will be! --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I'm +1 for the 1.5 change and the constructor change. I think upgrading
to 1.5 has many advantages and while it sucks for those left on 1.4 (or
god forbid 1.3!) we can't keep dragging our feet for stragglers.
Eelco Hillenius wrote:
Yeah. One of our most important use of generics would be IModel. It's
just not possible to seperate that from core without having to
maintain seperate code bases.
Eelco
On 2/14/06, Johan Compagner [EMAIL PROTECTED] wrote:
another java5 jar that is an add on for the normal wicket.jar?
If we introduce generics i think it will be ALL over the place throughout
the complete code base of wicket.
There is no real seperation.
johan
On 2/14/06, Ingram Chen [EMAIL PROTECTED] wrote:
Here is my opinion:
+1 for the Constructor refactoring to 1.3
for JDK5 it's better to split another wicket-jdk5.jar so we can benefit
from it *now*.
And merging both together when wicket 2.5 or 3 finished.
I hope future wicket can buddle all fundamentals in one single package,
say,
download one wicket-dep.zip that contains:
wicket.jar
wicket-jdk5.jar
wicket-spring.jar
wicket-spring-annot.jar
wicket-auth-roles.jar
wicket-auth-roles-anont.jar
or even better, pack all into one big wicket-all.jar just like Spring
does.
On 2/14/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new
WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this,
foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is
necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand
that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of
you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only
support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have
to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5 Wicket,
which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out:
http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
Ingram Chen
Java [EMAIL PROTECTED]
Institue of BioMedical Sciences Academia Sinica Taiwan
blog: http://www.javaworld.com.tw/roller/page/ingramchen
---
This SF.net email is sponsored by: Splunk Inc. Do you grep
Re: [Wicket-user] Post 1.2 roadmap
i think wicket starting out on 1.4 will need to stabilize properly on 1.4 before leaping to tiger. even though tiger has many tasty features like annotations and generics but since servers are still quite 1.4 friendly than 1.5, its important to consider that. although if it has to change to 1.5, it should quickly make that jump before the user base grows too big so dat users wont have issues then also if wicket suddenly leverages features in Tiger which many developers may still be learning, it may suddenly affect the learning curve of wicket. on the overall, i want to vote for wicket staying at 1.4 for a while more On 2/14/06, John Patterson [EMAIL PROTECTED] wrote: On Tuesday 14 Feb 2006 11:43, Eelco Hillenius wrote: move. I am always in favor of clarity and breaking early in these matters.I would certainly rather see wicket become a better framework than be heldback by backwards compatibility.Those who are not willing to refactor theirui code can simply keep using wicket 1.2.It is a good product now andalways will be!---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user-- The more life's risk you take, the more life's reward you get - MeAladejebi Ayodeji A., Project Leads PentaSoft Technologies Nigeria LimitedFloor 1, AP Plaza, Ademola Adetokunbo Crescent, Wuse IIAbuja, Nigeria |Tel: 234-09-5233478 | Fax: 234-09-5233470Interested in Java Development?Visit my blog: Ayodeji Aladejebi's JBlog | http://blog.dabarobjects.com/Community: Visit Cowblock.net, Nigeria
Re: [Wicket-user] Post 1.2 roadmap
On Feb 13, 2006, at 4:53 PM, Martijn Dashorst wrote: All, - constructor refactor we have reached a limit to the support we want to provide for Ajax and javascript. In order to provide the best support +1 on the constructor refactor, just means I'll have to convert a few things over once its done .. oh well :) - java 5 support This is something a lot of people are waiting for. I understand that many people want, Igor states /need/, Java 5 support in Wicket. +1 on java 5 support, I've had this in production for at least a year ... and the benefits outweigh any drawbacks. The questions I'm seeking answers to are the following: - should the post 1.2 version of Wicket involve both changes? no, get that out the door, and do this for 1.3 or future .. - should we make different releases for either change, and thus postponing 1.5 to Wicket 3? bundle it all in one, so the pain is localized and controlled. - how many of you still require for current or future projects to run on JDK 1.4? - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run 1.5 code on a 1.4 JRE? Thanks for your answers, Martijn -- Living a wicket life... Martijn Dashorst - http://www.jroller.com/page/dashorst Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel? cmd___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
On Feb 13, 2006, at 5:53 PM, Martijn Dashorst wrote: The questions I'm seeking answers to are the following: - should the post 1.2 version of Wicket involve both changes? +1 on the upgrade to 1.5 +1 on adding parent to the constructor 1.2 will serve well for those who can't be bothered to upgrade their JVM, and it has the added benefit of not having to upgrade their framework :-) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
+1 for Jonathan Locke´s statement. regardsOn 2/14/06, Jonathan Locke [EMAIL PROTECTED] wrote: +1 on Java 5 sooner. for one thing, we can't fold the authentication package into the core until we adopt it. for another, the lack of typesafe models is something we ought to remedy as soon as we possibly can. so i like the idea of doing 1.3 VERY quickly (JUST the constructor change and associated ajax work over a few short weeks) and then immediately have HEAD for 2.0 be Java 5 based. and i'd like us to get 2.0 out pretty quickly too so that WIA can include stuff about typesafe models and so forth. On 2/13/06, Eelco Hillenius [EMAIL PROTECTED] wrote: Here are mine: The questions I'm seeking answers to are the following:- should the post 1.2 version of Wicket involve both changes?No. The constructor changes first, we can call it 1.3 , and thatversion should be primarily just that change and some minor onesaround it.- should we make different releases for either change, and thus postponing 1.5 toWicket 3? Yes. If we call the constructor change Wicket 1.3, we can call the JDK1.5 version Wicket 2.0.- how many of you still require for current or future projects to run on JDK 1.4?- how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run 1.5 code on a 1.4 JRE?I agree with Igor that we should move to 1.5, and don't wait for ayear to do it. Not everyone will be happy with it, but we'll have avery decent version out with 1.3 which we should support for a longtime (by which I mean bug fixing, not so much back porting newfeatures).Moving to 1.5 will eleminate a few of the weak features we still haveand can't fix. As Wicket is all about Java code and strong typing, it sucks we can't have that strong typing in one of our major conceptsyet - the model. With generics we can have this. I think that alone isworth the move, and as a lot of other frameworks - either for UI stuff or other purposes - already moved to 1.5, I don't think it is tooearly. We are already a year further since our first 1.5 discussions.Eelco--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___ Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap (Java {1.}5)
Please ensure, that wicket still can be used on old 1.4 platforms (e.g. with retrotranslator). Not every provider has already switched to Java 1.5. -- Cheers, Tom Tom S. wrote: Java 5 support would be a really big plus (esp. with tools like Retrotranslator and Retroweaver) for me as well. We've tried Retroweaver with our desktop applications and it failed completely for non-trivial stuff. A few days ago I've tried Retrotranslator (did not know about it before) and so far I'm very happy with it and not had any crash. -- Cheers, Tom --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Hi,
The main trunk of TestNG (http:/testng.org/) is JDK 1.5 source base. Still we are able to release it
for JDK1.4. The trick is simple: a compiler flag. There is still some small restriction: the code
should not use JDK1.5-only API. If you can avoid this, than I can definitely pass you the details of
how you can build/compiler JDK1.5 source code to be compatible on priori JVMs.
hth,
./alex
--
.w( the_mindstorm )p.
#: Martijn Dashorst changed the world a bit at a time by saying (astral date:
2/14/2006 2:53 AM) :#
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this, foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5 Wicket, which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Actually, the really nice thing about Retrotranslator (as opposed to Retroweaver) is that it does support quite a few of the new Java 1.5 APIs. java.util.concurrent and StringBuilder are both supported.-- Jess http://www.jroller.com/page/jsight/On 2/14/06, Erik van Oosten [EMAIL PROTECTED] wrote:I have no personal experience with retrowaever. However, there are many success stories on the internet. I have at least one colleague that usedit without problems.If I understand correctly, there is one slight drawback: you can not usethe new java 5 APIs (like StringBuilder and java.util.concurrent).However, you do get all the new language stuff: generics, extended forloops, static imports, autoboxing/unboxing, varargs, enumerations andannotations.But since the move to java 5 is all about generics and not about API's I would say: go for both!Regards, Erik.JasonB schreef: As Jesse referenced, once we move to Java 1.5 we can still release Java 1.4 versions via tools such as Retroweaver... assuming that the tool works as advertised. Has anyone had more experience in these types of tools?- Jason B.---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642___Wicket-user mailing list Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
On 2/15/06, Jesse Sightler [EMAIL PROTECTED] wrote: Actually, the really nice thing about Retrotranslator (as opposed to Retroweaver) is that it does support quite a few of the new Java 1.5 APIs. java.util.concurrent and StringBuilder are both supported. Interesting - does it make use of the concurrent-backport and map the bytecode over?-- i like my video games - mamma said they are gonna melt my brainsi like my video games - i don't care what daddy said; they're my reality - henning pauly
Re: [Wicket-user] Post 1.2 roadmap
Just curious, can you be more specific about problems with Retroweaver?
Thanks,
Gili
Tom S. wrote:
Java 5 support would be a really big plus
(esp. with tools like Retrotranslator and Retroweaver) for me as well.
We've tried Retroweaver with our desktop applications and it failed
completely for non-trivial stuff. A few days ago I've tried
Retrotranslator (did not know about it before) and so far I'm very happy
with it and not had any crash.
--
Cheers,
Tom
Jesse Sightler wrote:
I'm completely in favor of jumping to Wicket 2.0 and implementing both
of these changes with it. Java 5 support would be a really big plus
(esp. with tools like Retrotranslator and Retroweaver) for me as well.
I'm sure that won't be perfect for some people, but I think it is
reasonable to cut over now and keep a 1.2 version as a maintenance
branch.
--
Jess
On 2/13/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this,
foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is
necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I
understand that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of
you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only
support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we
have to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5
Wicket, which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
Re: [Wicket-user] Post 1.2 roadmap
Instead of introducing extra arguments to the constructor, why not simply move all this logic into a new method? That is, introduce Component.bind(Component parent). We'd benefit from the fact that Wicket components could become JavaBeans and method-based binding is more flexible than constructor-based binding. From past experience, whenever classes require arguments in their constructors there is always some flexibility lost. For example, you absolutely cannot invoke any code before super() if you subclass such a class so if the value of one of the arguments needs to be calculated or modified in any way prior to the super() call you're out of luck. Gili Timo Stamm wrote: Johan Compagner schrieb: that would be very hard to maintain. For example if you have a panel that is rewritten by using only the new parent in constructor params. And you add that in youre own webpage/panel that doesn't use that parent in constructor param. Then you get all kind of errors because the child panel expect to have it all but because of the hierarchy problem that we have then, he doesn't have it. So i do think it is all or nothing. I see, thanks for the explanation. -1 for constructor change. On 2/14/06, Timo Stamm [EMAIL PROTECTED] wrote: Martijn Dashorst schrieb: - constructor refactor Wow, that's a /major/ change and will probably effect every custom component and every application written using Wicket. I see the benefit of having a complete component hierarchy availably right at the initialization of a class. But wouldn't it suffice to just make the new constructors available, and put a clear statement in the API docs? Then maybe deprecate the public add() in the next major version, and drop it in 2.0 or something like that? This opens up a lot of better markup parsing strategies for the core. Just get rid of markup, it sucks anyway ;) - java 5 support +1 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- http://www.desktopbeautifier.com/ --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Here are mine: The questions I'm seeking answers to are the following: - should the post 1.2 version of Wicket involve both changes? No. The constructor changes first, we can call it 1.3, and that version should be primarily just that change and some minor ones around it. - should we make different releases for either change, and thus postponing 1.5 to Wicket 3? Yes. If we call the constructor change Wicket 1.3, we can call the JDK 1.5 version Wicket 2.0. - how many of you still require for current or future projects to run on JDK 1.4? - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run 1.5 code on a 1.4 JRE? I agree with Igor that we should move to 1.5, and don't wait for a year to do it. Not everyone will be happy with it, but we'll have a very decent version out with 1.3 which we should support for a long time (by which I mean bug fixing, not so much back porting new features). Moving to 1.5 will eleminate a few of the weak features we still have and can't fix. As Wicket is all about Java code and strong typing, it sucks we can't have that strong typing in one of our major concepts yet - the model. With generics we can have this. I think that alone is worth the move, and as a lot of other frameworks - either for UI stuff or other purposes - already moved to 1.5, I don't think it is too early. We are already a year further since our first 1.5 discussions. Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
I'm completely in favor of jumping to Wicket 2.0 and implementing both
of these changes with it. Java 5 support would be a really big plus
(esp. with tools like Retrotranslator and Retroweaver) for me as well.
I'm sure that won't be perfect for some people, but I think it is
reasonable to cut over now and keep a 1.2 version as a maintenance
branch.
--
Jess
On 2/13/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this, foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5 Wicket,
which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Here is my opinions: - should the post 1.2 version of Wicket involve both changes?Absolutely not.I support the constructor change ,because it force the programmer to do in a right way.I don't want wicket support JDK1.5 soon.I know generics can bring many benefits.But there is a long time before most of us move to JDK1.5.Some projects from my clients are stilling run on JDK1.4 even JDK1.3.One year ,at least, is necessary for waiting.My clients would just move to JDK1.4 easily,because they need to pay a lot of money and not sure the old software can move to the new JDK easily.- should we make different releases for either change, and thus postponing 1.5 to Wicket 3?No, one version is enough. Wicket2 or wicket3 are not important.I think if you move to JDK1.5 too soon.You will lose many users.It's not good for wicket.Wicket still has a long way to go.- how many of you s till require for current or future projects to run on JDK 1.4?In fact,this question is suitable.Most time,the clients choose the platform,instead of us.Many clients are running different jdk, I can't predict. But for you,i would prefer JDK1.4. - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run 1.5 code on a 1.4 JRE?I never try to do that. 无限容量雅虎相册，原图等大下载，超快速度，赶快抢注！
Re: [Wicket-user] Post 1.2 roadmap
Seems to me you guys are quickly running out of things to work on.
Might I humbly suggest you schedule RFE #1228367 for the next release?
On a related note, I believe RFE #1167649 can be closed as fixed.
Thanks,
Gili
Martijn Dashorst wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this, foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5 Wicket, which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
http://www.desktopbeautifier.com/
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Say what? Running out of things to work on? That's a joke, right? May
I remind you that we are doing this largely in our spare time, and
have been doing that for a long time already?
Eelco
On 2/13/06, Gili [EMAIL PROTECTED] wrote:
Seems to me you guys are quickly running out of things to work on.
Might I humbly suggest you schedule RFE #1228367 for the next release?
On a related note, I believe RFE #1167649 can be closed as fixed.
Thanks,
Gili
Martijn Dashorst wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this, foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5 Wicket,
which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
http://www.desktopbeautifier.com/
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
We /will/ evaluate all bugs, issues and patches before we bring out
any final release. We can't make any guarantees on fixes and schedules
however.
On 2/13/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Say what? Running out of things to work on? That's a joke, right? May
I remind you that we are doing this largely in our spare time, and
have been doing that for a long time already?
Eelco
On 2/13/06, Gili [EMAIL PROTECTED] wrote:
Seems to me you guys are quickly running out of things to work on.
Might I humbly suggest you schedule RFE #1228367 for the next release?
On a related note, I believe RFE #1167649 can be closed as fixed.
Thanks,
Gili
Martijn Dashorst wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this, foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is
necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand
that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5 Wicket,
which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
http://www.desktopbeautifier.com/
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that
Re: [Wicket-user] Post 1.2 roadmap
may i humbly suggest you do not post off topic.-IgorOn 2/13/06, Gili [EMAIL PROTECTED]
wrote:Seems to me you guys are quickly running out of things to work on.
Might I humbly suggest you schedule RFE #1228367 for the next release?On a related note, I believe RFE #1167649 can be closed as fixed.Thanks,GiliMartijn Dashorst wrote: All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope to get it done soon. This will benefit everyone. So I want to take a look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate. There are two very big things ahead of us:- constructor refactor we have reached a limit to the support we want to provide for Ajax and _javascript_. In order to provide the best support
we need to know the markup id before it is available. Many have been bitten by trying to retrieve an attribute from a component tag in the page constructor. We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component constructor, which sets the parent of the component.public MyPage() { WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1)); c.add(new Label(bar2)); c.add(new Label(bar3)); add(c);}
will become:public MyPage() {WebMarkupContainer c = new WebMarkupContainer(this, foo);new TextField(c, bar1);
new Label(c, bar2);new Label(c, bar3);} This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is necessary to implement it in order to move Wicket forward.- java 5 support This is something a lot of people are waiting for. I understand that
many people want, Igor states /need/, Java 5 support in Wicket. There is also a negative side to this. Some, or even many of you, can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't move to 1.5. As Wicket is a volunteer effort, we can only support so many projects. Supporting both a 1.4 and
1.5 project will drain our resources too far, and won't be possible. So we have to make a choice. The questions I'm seeking answers to are the following:- should the post
1.2 version of Wicket involve both changes?- should we make different releases for either change, and thus postponing 1.5 toWicket 3?- how many of you still require for current or future projects to run
on JDK 1.4?- how many would object to having a retroweaver build of a JDK 5 Wicket, whichenables you to run 1.5 code on a 1.4 JRE? Thanks for your answers, Martijn
-- Living a wicket life... Martijn Dashorst - http://www.jroller.com/page/dashorst Wicket 1.1.1 is out:
http://wicket.sourceforge.net/wicket-1.1 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes
searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642
___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user--http://www.desktopbeautifier.com/---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642___
Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
As Jesse referenced, once we move to Java 1.5 we can still release Java
1.4 versions via tools such as Retroweaver... assuming that the tool
works as advertised. Has anyone had more experience in these types of
tools?
- Jason B.
Jesse Sightler wrote:
I'm completely in favor of jumping to Wicket 2.0 and implementing both
of these changes with it. Java 5 support would be a really big plus
(esp. with tools like Retrotranslator and Retroweaver) for me as well.
I'm sure that won't be perfect for some people, but I think it is
reasonable to cut over now and keep a 1.2 version as a maintenance
branch.
--
Jess
On 2/13/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and _javascript_. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer("foo");
c.add(new TextField("bar1"));
c.add(new Label("bar2"));
c.add(new Label("bar3"));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this, "foo");
new TextField(c, "bar1");
new Label(c, "bar2");
new Label(c, "bar3");
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5 Wicket, which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
Yes, you are correct, that is exactly what I meant. The pace of development seems to be quite nice. :)-- JessOn 2/14/06, Eelco Hillenius [EMAIL PROTECTED] wrote: I think you mean pace of releasing. The pace of development isactually very high, and is - unfortunately - the main reason why wedidn't bring out a release yet :)Eelco Based on the current pace of development, a 2.0 release would probably not land until late this year at the earliest, I would think.Does that make 1.5 sound a little better?---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___ Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Post 1.2 roadmap
I am sorry,i forget the time for 2.0 release. ButI still have doubt aboutone year is enough. I never used Retrotranslator and other retroweaver tools.I am not sure it can run in different jdk with problems.So i avoid it. Stick with the old version is not bad, we seldom change the version for consistence.The last sentence is my fault.There is a wrong word "projects" insteadof "objects". I just want to way "retroweaver" is not a good choice,just a solution for urgency. - Original Message - From: Jesse Sightler To: wicket-user@lists.sourceforge.net Sent: Tuesday, February 14, 2006 1:17 PM Subject: Re: [Wicket-user] Post 1.2 roadmap On 2/13/06, wang lei [EMAIL PROTECTED] wrote: Here is my opinions: - should the post 1.2 version of Wicket involve both changes?Absolutely not.I s upport the constructor change ,because it force the programmer to do in a right way. I don't want wicket support JDK1.5 soon.I know generics can bring many benefits.But there is a long time before most of us move to JDK1.5.Some projects from my clients are stilling run on JDK1.4 even JDK1.3.One year ,at least, is necessary for waiting.My clients would just move to JDK1.4 easily,because they need to pay a lot of money and not sure the old software can move to the new JDK easily. Based on the current pace of development, a 2.0 release would probably not land until late this year at the earliest, I would think. Does that make 1.5 sound a little better?And 1.4 users would have two choices:Use the new version through Retrotranslator Stick with the old version until they can safely migrateI don't think either of those options is particularly bad. - should we make different releases for either change, and thus postponing 1.5 to Wicket 3?No, one version is enough. Wicket2 or wicket3 are not important.I think if you move to JDK1.5 too soon.You will lose many users.It's not good for wicket.Wicket still has a long way to go. Of course, it would also gain users thanks to the nicer development environment. :) - how many would object to having a retroweaver build of a JDK 5 Wicket, which enables you to run 1.5 code on a 1.4 JRE?I never try to do that.I'm not sure what you mean... just that you've never tried it? Or do you have some obje ction to this approach? Thanks,Jesshttp://www.jroller.com/page/jsight/__赶快注册雅虎超大容量免费邮箱?http://cn.mail.yahoo.com
Re: [Wicket-user] Post 1.2 roadmap
All,
I am for 1.5. I am in the happy situation where I have complete control
over deployment of my apps. Not everyone is. I would rather have it
sooner than later, but if it's best for the community as a whole, I am
glad to wait until after the Constructor refactoring. Just not too much
after. :-)
Should I find myself in the position of supporting jdk 1.5, I'd give
retroweaver a try. Whether I use it would depend on how well it works,
of course.
Thanks,
Martijn Dashorst wrote:
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
we need to know the markup id before it is available. Many
have been bitten by trying to retrieve an attribute from a
component tag in the page constructor.
We want to remedie this by removing the add() method,
and replacing it with an extra parameter in the component
constructor, which sets the parent of the component.
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(foo);
c.add(new TextField(bar1));
c.add(new Label(bar2));
c.add(new Label(bar3));
add(c);
}
will become:
public MyPage() {
WebMarkupContainer c = new WebMarkupContainer(this, foo);
new TextField(c, bar1);
new Label(c, bar2);
new Label(c, bar3);
}
This opens up a lot of better markup parsing strategies for the
core. We know this is a major API break, but we feel it is necessary
to implement it in order to move Wicket forward.
- java 5 support
This is something a lot of people are waiting for. I understand that
many people want, Igor states /need/, Java 5 support in Wicket.
There is also a negative side to this. Some, or even many of you,
can't move to java 1.5 as a server platform. We don't know how
many users this affects. Please give a response when you can't
move to 1.5. As Wicket is a volunteer effort, we can only support
so many projects. Supporting both a 1.4 and 1.5 project will
drain our resources too far, and won't be possible. So we have to
make a choice.
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
- should we make different releases for either change, and thus
postponing 1.5 to
Wicket 3?
- how many of you still require for current or future projects to run
on JDK 1.4?
- how many would object to having a retroweaver build of a JDK 5 Wicket,
which
enables you to run 1.5 code on a 1.4 JRE?
Thanks for your answers,
Martijn
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
Philip A. Chapman
Application Development:
Java, Visual Basic (MCP), PostgreSQL, MySQL, MSSQL
Linux, Windows 9x, Windows NT, Windows 2000, Windows XP
signature.asc
Description: OpenPGP digital signature
