subject:"\[Wicket\-user\] ajax refresh on date picker"

Hi Eelco,

I did not feel irritated by your answers and I apologize for having let 
you think I was. I understand perfectly your position and I acknowledge 
the immense amount of work there is behind Wicket and I want to thank 
every one working on it for making such a smart framework available.

I am building a demo/prototype application for a big french 
administration and I want to convince them that they should add Wicket 
to the list of their accepted technologies. That's why I need features 
that are 100% functionnal. If a feature is only 99% functionnal, it's 
probably better not to mention it because somebody will certainly 
pinpoint the 1% that is causing problem, making others forget about the 
working 99%.

So, what I am trying to do is helping to find the cause of the problem 
and (may be) a solution. At this time, I am using a normal link to 
switch locales and I have removed all accented characters in the 
datapicker french strings and saved the file in ascii. I am working to 
find on a better workaround.

Regarding UTF8, this is (in my opinion) not a good solution. AFAIK, it 
as been designed to suit the needs of english language applications 
where only a few exotic foreign characters have to be usable. It's main 
advantage is that the data is nearly the same size as ascci for this 
kind of use. I think UTF16 is a much better solution, even if it is not 
100% perfect since it can't represent all characters needed in all 
languages. Next UNICODE encoding will be 32 bits, which will be enough 
for all characters of all languages in the galaxy. We will then have to 
design an extension for the rest of the universe ;-)

Cheers,

Pierre-Yves

Eelco Hillenius a écrit :
 It is the same kind of problem we have with character encoding. Every
 time someone has a problem with encoding, the answer can be use XXX
 encoding for all and there will be no problem. This is false AND
 irrelevant.
 
 Well, I guess we hoped that UTF-8 would just work for everyone. It's
 certainly advertised as that. But the message comes across, and the
 more reports we have that something is broken, the harder we'll work
 on it. It's just not all easy, and some of the bugs we are
 encountering lately (like a problem with file descriptors) were not
 our fault in the first place. We're not even sure the encoding
 problems are. But the more people that actually use those encodings
 can help us, possibly by supplying fixes/ solutions, the better.
 
 It is irrelevant because the question is how to use this
 functionnality and not how to do without it.
 
 Yes, you are right. You have to understand though that a framework
 can't fix every possible problem in the world. Every time we add a
 feature, there's an open door for 10 additional ones. That doesn't
 mean we don't want to add them, but maybe not now, or we need to be
 convinced about the urgency of the problem.
 
 It is false because it does not solve the problem. In the case of Ajax
 switching locale, remember the problem is updating the datepicker. If
 you switch the locale in a situation where no datepicker is displayed
 and then load a datepicker through Ajax, it is still broken. But of
 course, the solution is not to use Ajax.
 
 Well we fixed header contribution through Ajax. It seems that the
 datepicker is the component from hell, as we're having all kinds of
 issues with it we don't have with other components. But Matej and
 others spent many of his free nights trying to fix it and they have
 been progressing very well. It's a pretty tough problem, really.
 
 Or a slightly better solution:
 do not use Ajax to switch locales AND do not use anything else than US
 ASCII in the datepicker labels.
 
 I didn't get the datepicker labels. Anything that has to do with the
 JavaScript part that is faulty: I'm sorry but we can't do much about
 it as we adopted that component from another project (jscalendar).
 We're working on a replacement, and people can always create their own
 replacement too (for intance, look at wicket-contrib-datepicker and
 wicket-contrib-yui.
 
 I'm sorry you feel irritated by our answers. You are right that
 telling you you can't do that is not a very satisfying answer.
 Please understand that we are working our asses off in our free time,
 un-sponsored etc to make this framework as good as we can, as fast as
 we can. Keep those reports coming, and the best and fastest way to get
 a bug fixed is to give us a solution for fixing it.
 
 Cheers,
 
 Eelco
 
 
 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net

Re: [Wicket-user] ajax refresh on date picker

2006-09-27 Thread Igor Vaynberg

Next UNICODE encoding will be 32 bits, which will be enoughfor all characters of all languages in the galaxy. 
thats what they said about ipv4 :)-Igor
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] ajax refresh on date picker

Hi,

I'm working on the date picker encoding problem. What I'll probably do 
is to convert all non-unicode (latin1, ...) date picker locale strings 
to utf-8 and add charset=utf-8 to the script element that includes 
the script.

This should sove the problem, as xmlhttprequest (used to load script 
during ajax header contribution) treats the response as utf-8. And the 
charset in script that should ensure that during regular header 
contribution the script will be loaded with the correct locale. I'll be 
commiting soon, would you mind testing if it works for you?

-Matej

Pierre-Yves Saumont wrote:
 Hi Eelco,
 
 I did not feel irritated by your answers and I apologize for having let 
 you think I was. I understand perfectly your position and I acknowledge 
 the immense amount of work there is behind Wicket and I want to thank 
 every one working on it for making such a smart framework available.
 
 I am building a demo/prototype application for a big french 
 administration and I want to convince them that they should add Wicket 
 to the list of their accepted technologies. That's why I need features 
 that are 100% functionnal. If a feature is only 99% functionnal, it's 
 probably better not to mention it because somebody will certainly 
 pinpoint the 1% that is causing problem, making others forget about the 
 working 99%.
 
 So, what I am trying to do is helping to find the cause of the problem 
 and (may be) a solution. At this time, I am using a normal link to 
 switch locales and I have removed all accented characters in the 
 datapicker french strings and saved the file in ascii. I am working to 
 find on a better workaround.
 
 Regarding UTF8, this is (in my opinion) not a good solution. AFAIK, it 
 as been designed to suit the needs of english language applications 
 where only a few exotic foreign characters have to be usable. It's main 
 advantage is that the data is nearly the same size as ascci for this 
 kind of use. I think UTF16 is a much better solution, even if it is not 
 100% perfect since it can't represent all characters needed in all 
 languages. Next UNICODE encoding will be 32 bits, which will be enough 
 for all characters of all languages in the galaxy. We will then have to 
 design an extension for the rest of the universe ;-)
 
 Cheers,
 
 Pierre-Yves
 
 Eelco Hillenius a écrit :
 It is the same kind of problem we have with character encoding. Every
 time someone has a problem with encoding, the answer can be use XXX
 encoding for all and there will be no problem. This is false AND
 irrelevant.
 Well, I guess we hoped that UTF-8 would just work for everyone. It's
 certainly advertised as that. But the message comes across, and the
 more reports we have that something is broken, the harder we'll work
 on it. It's just not all easy, and some of the bugs we are
 encountering lately (like a problem with file descriptors) were not
 our fault in the first place. We're not even sure the encoding
 problems are. But the more people that actually use those encodings
 can help us, possibly by supplying fixes/ solutions, the better.

 It is irrelevant because the question is how to use this
 functionnality and not how to do without it.
 Yes, you are right. You have to understand though that a framework
 can't fix every possible problem in the world. Every time we add a
 feature, there's an open door for 10 additional ones. That doesn't
 mean we don't want to add them, but maybe not now, or we need to be
 convinced about the urgency of the problem.

 It is false because it does not solve the problem. In the case of Ajax
 switching locale, remember the problem is updating the datepicker. If
 you switch the locale in a situation where no datepicker is displayed
 and then load a datepicker through Ajax, it is still broken. But of
 course, the solution is not to use Ajax.
 Well we fixed header contribution through Ajax. It seems that the
 datepicker is the component from hell, as we're having all kinds of
 issues with it we don't have with other components. But Matej and
 others spent many of his free nights trying to fix it and they have
 been progressing very well. It's a pretty tough problem, really.

 Or a slightly better solution:
 do not use Ajax to switch locales AND do not use anything else than US
 ASCII in the datepicker labels.
 I didn't get the datepicker labels. Anything that has to do with the
 JavaScript part that is faulty: I'm sorry but we can't do much about
 it as we adopted that component from another project (jscalendar).
 We're working on a replacement, and people can always create their own
 replacement too (for intance, look at wicket-contrib-datepicker and
 wicket-contrib-yui.

 I'm sorry you feel irritated by our answers. You are right that
 telling you you can't do that is not a very satisfying answer.
 Please understand that we are working our asses off in our free time,
 un-sponsored etc to make this framework as good as we can, as fast as
 we can. Keep those

Re: [Wicket-user] ajax refresh on date picker

Hi Matej,

Of course I will test it as soon as you commit it. BTW, there are plenty 
of typos and spelling mistakes in the french script, and even an error 
in the abreviated day names (it says monday, tuesday, tuesday, thursday 
and there is no wednesday!). Do you want me to send you an edited file?

Pierre-Yves

Matej Knopp a écrit :
 Hi,
 
 I'm working on the date picker encoding problem. What I'll probably do 
 is to convert all non-unicode (latin1, ...) date picker locale strings 
 to utf-8 and add charset=utf-8 to the script element that includes 
 the script.
 
 This should sove the problem, as xmlhttprequest (used to load script 
 during ajax header contribution) treats the response as utf-8. And the 
 charset in script that should ensure that during regular header 
 contribution the script will be loaded with the correct locale. I'll be 
 commiting soon, would you mind testing if it works for you?
 
 -Matej
 
 Pierre-Yves Saumont wrote:
 Hi Eelco,

 I did not feel irritated by your answers and I apologize for having 
 let you think I was. I understand perfectly your position and I 
 acknowledge the immense amount of work there is behind Wicket and I 
 want to thank every one working on it for making such a smart 
 framework available.

 I am building a demo/prototype application for a big french 
 administration and I want to convince them that they should add Wicket 
 to the list of their accepted technologies. That's why I need features 
 that are 100% functionnal. If a feature is only 99% functionnal, it's 
 probably better not to mention it because somebody will certainly 
 pinpoint the 1% that is causing problem, making others forget about 
 the working 99%.

 So, what I am trying to do is helping to find the cause of the problem 
 and (may be) a solution. At this time, I am using a normal link to 
 switch locales and I have removed all accented characters in the 
 datapicker french strings and saved the file in ascii. I am working to 
 find on a better workaround.

 Regarding UTF8, this is (in my opinion) not a good solution. AFAIK, it 
 as been designed to suit the needs of english language applications 
 where only a few exotic foreign characters have to be usable. It's 
 main advantage is that the data is nearly the same size as ascci for 
 this kind of use. I think UTF16 is a much better solution, even if it 
 is not 100% perfect since it can't represent all characters needed in 
 all languages. Next UNICODE encoding will be 32 bits, which will be 
 enough for all characters of all languages in the galaxy. We will then 
 have to design an extension for the rest of the universe ;-)

 Cheers,

 Pierre-Yves

 Eelco Hillenius a écrit :
 It is the same kind of problem we have with character encoding. Every
 time someone has a problem with encoding, the answer can be use XXX
 encoding for all and there will be no problem. This is false AND
 irrelevant.
 Well, I guess we hoped that UTF-8 would just work for everyone. It's
 certainly advertised as that. But the message comes across, and the
 more reports we have that something is broken, the harder we'll work
 on it. It's just not all easy, and some of the bugs we are
 encountering lately (like a problem with file descriptors) were not
 our fault in the first place. We're not even sure the encoding
 problems are. But the more people that actually use those encodings
 can help us, possibly by supplying fixes/ solutions, the better.

 It is irrelevant because the question is how to use this
 functionnality and not how to do without it.
 Yes, you are right. You have to understand though that a framework
 can't fix every possible problem in the world. Every time we add a
 feature, there's an open door for 10 additional ones. That doesn't
 mean we don't want to add them, but maybe not now, or we need to be
 convinced about the urgency of the problem.

 It is false because it does not solve the problem. In the case of Ajax
 switching locale, remember the problem is updating the datepicker. If
 you switch the locale in a situation where no datepicker is displayed
 and then load a datepicker through Ajax, it is still broken. But of
 course, the solution is not to use Ajax.
 Well we fixed header contribution through Ajax. It seems that the
 datepicker is the component from hell, as we're having all kinds of
 issues with it we don't have with other components. But Matej and
 others spent many of his free nights trying to fix it and they have
 been progressing very well. It's a pretty tough problem, really.

 Or a slightly better solution:
 do not use Ajax to switch locales AND do not use anything else than US
 ASCII in the datepicker labels.
 I didn't get the datepicker labels. Anything that has to do with the
 JavaScript part that is faulty: I'm sorry but we can't do much about
 it as we adopted that component from another project (jscalendar).
 We're working on a replacement, and people can always create their own
 replacement too (for intance, look at

Re: [Wicket-user] ajax refresh on date picker

I remember the first days of Java: UNICODE (UTF16) was the ultimate 
encoding scheme that would definitely solve the problem for all 
languages on earth. There was plenty of unused room for future use. The 
Java designers even create a special type (char) for this. They would 
have been much better inspired to use int to represent characters  ;-)

Pierre-Yves

Igor Vaynberg a écrit :
 Next UNICODE encoding will be 32 bits, which will be enough
 for all characters of all languages in the galaxy. 
 
 
 
 thats what they said about ipv4 :)
 
 -Igor
  
 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] ajax refresh on date picker

Sure, why not? I had the same problem with Slovak locale. Just send me 
the corrected (utf-8 encoded) file and I'll commit it.

-Matej

Pierre-Yves Saumont wrote:
 Hi Matej,
 
 Of course I will test it as soon as you commit it. BTW, there are plenty 
 of typos and spelling mistakes in the french script, and even an error 
 in the abreviated day names (it says monday, tuesday, tuesday, thursday 
 and there is no wednesday!). Do you want me to send you an edited file?
 
 Pierre-Yves
 
 Matej Knopp a écrit :
 Hi,

 I'm working on the date picker encoding problem. What I'll probably do 
 is to convert all non-unicode (latin1, ...) date picker locale strings 
 to utf-8 and add charset=utf-8 to the script element that includes 
 the script.

 This should sove the problem, as xmlhttprequest (used to load script 
 during ajax header contribution) treats the response as utf-8. And the 
 charset in script that should ensure that during regular header 
 contribution the script will be loaded with the correct locale. I'll be 
 commiting soon, would you mind testing if it works for you?

 -Matej

 Pierre-Yves Saumont wrote:
 Hi Eelco,

 I did not feel irritated by your answers and I apologize for having 
 let you think I was. I understand perfectly your position and I 
 acknowledge the immense amount of work there is behind Wicket and I 
 want to thank every one working on it for making such a smart 
 framework available.

 I am building a demo/prototype application for a big french 
 administration and I want to convince them that they should add Wicket 
 to the list of their accepted technologies. That's why I need features 
 that are 100% functionnal. If a feature is only 99% functionnal, it's 
 probably better not to mention it because somebody will certainly 
 pinpoint the 1% that is causing problem, making others forget about 
 the working 99%.

 So, what I am trying to do is helping to find the cause of the problem 
 and (may be) a solution. At this time, I am using a normal link to 
 switch locales and I have removed all accented characters in the 
 datapicker french strings and saved the file in ascii. I am working to 
 find on a better workaround.

 Regarding UTF8, this is (in my opinion) not a good solution. AFAIK, it 
 as been designed to suit the needs of english language applications 
 where only a few exotic foreign characters have to be usable. It's 
 main advantage is that the data is nearly the same size as ascci for 
 this kind of use. I think UTF16 is a much better solution, even if it 
 is not 100% perfect since it can't represent all characters needed in 
 all languages. Next UNICODE encoding will be 32 bits, which will be 
 enough for all characters of all languages in the galaxy. We will then 
 have to design an extension for the rest of the universe ;-)

 Cheers,

 Pierre-Yves

 Eelco Hillenius a écrit :
 It is the same kind of problem we have with character encoding. Every
 time someone has a problem with encoding, the answer can be use XXX
 encoding for all and there will be no problem. This is false AND
 irrelevant.
 Well, I guess we hoped that UTF-8 would just work for everyone. It's
 certainly advertised as that. But the message comes across, and the
 more reports we have that something is broken, the harder we'll work
 on it. It's just not all easy, and some of the bugs we are
 encountering lately (like a problem with file descriptors) were not
 our fault in the first place. We're not even sure the encoding
 problems are. But the more people that actually use those encodings
 can help us, possibly by supplying fixes/ solutions, the better.

 It is irrelevant because the question is how to use this
 functionnality and not how to do without it.
 Yes, you are right. You have to understand though that a framework
 can't fix every possible problem in the world. Every time we add a
 feature, there's an open door for 10 additional ones. That doesn't
 mean we don't want to add them, but maybe not now, or we need to be
 convinced about the urgency of the problem.

 It is false because it does not solve the problem. In the case of Ajax
 switching locale, remember the problem is updating the datepicker. If
 you switch the locale in a situation where no datepicker is displayed
 and then load a datepicker through Ajax, it is still broken. But of
 course, the solution is not to use Ajax.
 Well we fixed header contribution through Ajax. It seems that the
 datepicker is the component from hell, as we're having all kinds of
 issues with it we don't have with other components. But Matej and
 others spent many of his free nights trying to fix it and they have
 been progressing very well. It's a pretty tough problem, really.

 Or a slightly better solution:
 do not use Ajax to switch locales AND do not use anything else than US
 ASCII in the datepicker labels.
 I didn't get the datepicker labels. Anything that has to do with the
 JavaScript part that is faulty: I'm sorry but we can't do much about
 it as we

Re: [Wicket-user] ajax refresh on date picker

btw. it should be already in.

Pierre-Yves Saumont wrote:
 Hi Matej,
 
 Of course I will test it as soon as you commit it. BTW, there are plenty 
 of typos and spelling mistakes in the french script, and even an error 
 in the abreviated day names (it says monday, tuesday, tuesday, thursday 
 and there is no wednesday!). Do you want me to send you an edited file?
 
 Pierre-Yves
 
 Matej Knopp a écrit :
 Hi,

 I'm working on the date picker encoding problem. What I'll probably do 
 is to convert all non-unicode (latin1, ...) date picker locale strings 
 to utf-8 and add charset=utf-8 to the script element that includes 
 the script.

 This should sove the problem, as xmlhttprequest (used to load script 
 during ajax header contribution) treats the response as utf-8. And the 
 charset in script that should ensure that during regular header 
 contribution the script will be loaded with the correct locale. I'll be 
 commiting soon, would you mind testing if it works for you?

 -Matej

 Pierre-Yves Saumont wrote:
 Hi Eelco,

 I did not feel irritated by your answers and I apologize for having 
 let you think I was. I understand perfectly your position and I 
 acknowledge the immense amount of work there is behind Wicket and I 
 want to thank every one working on it for making such a smart 
 framework available.

 I am building a demo/prototype application for a big french 
 administration and I want to convince them that they should add Wicket 
 to the list of their accepted technologies. That's why I need features 
 that are 100% functionnal. If a feature is only 99% functionnal, it's 
 probably better not to mention it because somebody will certainly 
 pinpoint the 1% that is causing problem, making others forget about 
 the working 99%.

 So, what I am trying to do is helping to find the cause of the problem 
 and (may be) a solution. At this time, I am using a normal link to 
 switch locales and I have removed all accented characters in the 
 datapicker french strings and saved the file in ascii. I am working to 
 find on a better workaround.

 Regarding UTF8, this is (in my opinion) not a good solution. AFAIK, it 
 as been designed to suit the needs of english language applications 
 where only a few exotic foreign characters have to be usable. It's 
 main advantage is that the data is nearly the same size as ascci for 
 this kind of use. I think UTF16 is a much better solution, even if it 
 is not 100% perfect since it can't represent all characters needed in 
 all languages. Next UNICODE encoding will be 32 bits, which will be 
 enough for all characters of all languages in the galaxy. We will then 
 have to design an extension for the rest of the universe ;-)

 Cheers,

 Pierre-Yves

 Eelco Hillenius a écrit :
 It is the same kind of problem we have with character encoding. Every
 time someone has a problem with encoding, the answer can be use XXX
 encoding for all and there will be no problem. This is false AND
 irrelevant.
 Well, I guess we hoped that UTF-8 would just work for everyone. It's
 certainly advertised as that. But the message comes across, and the
 more reports we have that something is broken, the harder we'll work
 on it. It's just not all easy, and some of the bugs we are
 encountering lately (like a problem with file descriptors) were not
 our fault in the first place. We're not even sure the encoding
 problems are. But the more people that actually use those encodings
 can help us, possibly by supplying fixes/ solutions, the better.

 It is irrelevant because the question is how to use this
 functionnality and not how to do without it.
 Yes, you are right. You have to understand though that a framework
 can't fix every possible problem in the world. Every time we add a
 feature, there's an open door for 10 additional ones. That doesn't
 mean we don't want to add them, but maybe not now, or we need to be
 convinced about the urgency of the problem.

 It is false because it does not solve the problem. In the case of Ajax
 switching locale, remember the problem is updating the datepicker. If
 you switch the locale in a situation where no datepicker is displayed
 and then load a datepicker through Ajax, it is still broken. But of
 course, the solution is not to use Ajax.
 Well we fixed header contribution through Ajax. It seems that the
 datepicker is the component from hell, as we're having all kinds of
 issues with it we don't have with other components. But Matej and
 others spent many of his free nights trying to fix it and they have
 been progressing very well. It's a pretty tough problem, really.

 Or a slightly better solution:
 do not use Ajax to switch locales AND do not use anything else than US
 ASCII in the datepicker labels.
 I didn't get the datepicker labels. Anything that has to do with the
 JavaScript part that is faulty: I'm sorry but we can't do much about
 it as we adopted that component from another project (jscalendar).
 We're working on a replacement, and people

Re: [Wicket-user] ajax refresh on date picker

What should already be in? Is it your fix? Or are you talking about the 
edited file I sent to the list few days ago? This is no complete since 
at that time I had not noticed the tuesday error!

Pierre-Yves

Matej Knopp a écrit :
 btw. it should be already in.
 
 Pierre-Yves Saumont wrote:
 Hi Matej,

 Of course I will test it as soon as you commit it. BTW, there are 
 plenty of typos and spelling mistakes in the french script, and even 
 an error in the abreviated day names (it says monday, tuesday, 
 tuesday, thursday and there is no wednesday!). Do you want me to send 
 you an edited file?

 Pierre-Yves

 Matej Knopp a écrit :
 Hi,

 I'm working on the date picker encoding problem. What I'll probably 
 do is to convert all non-unicode (latin1, ...) date picker locale 
 strings to utf-8 and add charset=utf-8 to the script element that 
 includes the script.

 This should sove the problem, as xmlhttprequest (used to load script 
 during ajax header contribution) treats the response as utf-8. And 
 the charset in script that should ensure that during regular header 
 contribution the script will be loaded with the correct locale. I'll 
 be commiting soon, would you mind testing if it works for you?

 -Matej

 Pierre-Yves Saumont wrote:
 Hi Eelco,

 I did not feel irritated by your answers and I apologize for having 
 let you think I was. I understand perfectly your position and I 
 acknowledge the immense amount of work there is behind Wicket and I 
 want to thank every one working on it for making such a smart 
 framework available.

 I am building a demo/prototype application for a big french 
 administration and I want to convince them that they should add 
 Wicket to the list of their accepted technologies. That's why I need 
 features that are 100% functionnal. If a feature is only 99% 
 functionnal, it's probably better not to mention it because somebody 
 will certainly pinpoint the 1% that is causing problem, making 
 others forget about the working 99%.

 So, what I am trying to do is helping to find the cause of the 
 problem and (may be) a solution. At this time, I am using a normal 
 link to switch locales and I have removed all accented characters in 
 the datapicker french strings and saved the file in ascii. I am 
 working to find on a better workaround.

 Regarding UTF8, this is (in my opinion) not a good solution. AFAIK, 
 it as been designed to suit the needs of english language 
 applications where only a few exotic foreign characters have to be 
 usable. It's main advantage is that the data is nearly the same size 
 as ascci for this kind of use. I think UTF16 is a much better 
 solution, even if it is not 100% perfect since it can't represent 
 all characters needed in all languages. Next UNICODE encoding will 
 be 32 bits, which will be enough for all characters of all languages 
 in the galaxy. We will then have to design an extension for the rest 
 of the universe ;-)

 Cheers,

 Pierre-Yves

 Eelco Hillenius a écrit :
 It is the same kind of problem we have with character encoding. Every
 time someone has a problem with encoding, the answer can be use XXX
 encoding for all and there will be no problem. This is false AND
 irrelevant.
 Well, I guess we hoped that UTF-8 would just work for everyone. It's
 certainly advertised as that. But the message comes across, and the
 more reports we have that something is broken, the harder we'll work
 on it. It's just not all easy, and some of the bugs we are
 encountering lately (like a problem with file descriptors) were not
 our fault in the first place. We're not even sure the encoding
 problems are. But the more people that actually use those encodings
 can help us, possibly by supplying fixes/ solutions, the better.

 It is irrelevant because the question is how to use this
 functionnality and not how to do without it.
 Yes, you are right. You have to understand though that a framework
 can't fix every possible problem in the world. Every time we add a
 feature, there's an open door for 10 additional ones. That doesn't
 mean we don't want to add them, but maybe not now, or we need to be
 convinced about the urgency of the problem.

 It is false because it does not solve the problem. In the case of 
 Ajax
 switching locale, remember the problem is updating the datepicker. If
 you switch the locale in a situation where no datepicker is displayed
 and then load a datepicker through Ajax, it is still broken. But of
 course, the solution is not to use Ajax.
 Well we fixed header contribution through Ajax. It seems that the
 datepicker is the component from hell, as we're having all kinds of
 issues with it we don't have with other components. But Matej and
 others spent many of his free nights trying to fix it and they have
 been progressing very well. It's a pretty tough problem, really.

 Or a slightly better solution:
 do not use Ajax to switch locales AND do not use anything else 
 than US
 ASCII in the datepicker labels.
 I didn't get

Re: [Wicket-user] ajax refresh on date picker

Sorry for ambiguity. The fix should be already in.

-Matej

Pierre-Yves Saumont wrote:
 What should already be in? Is it your fix? Or are you talking about the 
 edited file I sent to the list few days ago? This is no complete since 
 at that time I had not noticed the tuesday error!
 
 Pierre-Yves
 
 Matej Knopp a écrit :
 btw. it should be already in.

 Pierre-Yves Saumont wrote:
 Hi Matej,

 Of course I will test it as soon as you commit it. BTW, there are 
 plenty of typos and spelling mistakes in the french script, and even 
 an error in the abreviated day names (it says monday, tuesday, 
 tuesday, thursday and there is no wednesday!). Do you want me to send 
 you an edited file?

 Pierre-Yves

 Matej Knopp a écrit :
 Hi,

 I'm working on the date picker encoding problem. What I'll probably 
 do is to convert all non-unicode (latin1, ...) date picker locale 
 strings to utf-8 and add charset=utf-8 to the script element that 
 includes the script.

 This should sove the problem, as xmlhttprequest (used to load script 
 during ajax header contribution) treats the response as utf-8. And 
 the charset in script that should ensure that during regular header 
 contribution the script will be loaded with the correct locale. I'll 
 be commiting soon, would you mind testing if it works for you?

 -Matej

 Pierre-Yves Saumont wrote:
 Hi Eelco,

 I did not feel irritated by your answers and I apologize for having 
 let you think I was. I understand perfectly your position and I 
 acknowledge the immense amount of work there is behind Wicket and I 
 want to thank every one working on it for making such a smart 
 framework available.

 I am building a demo/prototype application for a big french 
 administration and I want to convince them that they should add 
 Wicket to the list of their accepted technologies. That's why I need 
 features that are 100% functionnal. If a feature is only 99% 
 functionnal, it's probably better not to mention it because somebody 
 will certainly pinpoint the 1% that is causing problem, making 
 others forget about the working 99%.

 So, what I am trying to do is helping to find the cause of the 
 problem and (may be) a solution. At this time, I am using a normal 
 link to switch locales and I have removed all accented characters in 
 the datapicker french strings and saved the file in ascii. I am 
 working to find on a better workaround.

 Regarding UTF8, this is (in my opinion) not a good solution. AFAIK, 
 it as been designed to suit the needs of english language 
 applications where only a few exotic foreign characters have to be 
 usable. It's main advantage is that the data is nearly the same size 
 as ascci for this kind of use. I think UTF16 is a much better 
 solution, even if it is not 100% perfect since it can't represent 
 all characters needed in all languages. Next UNICODE encoding will 
 be 32 bits, which will be enough for all characters of all languages 
 in the galaxy. We will then have to design an extension for the rest 
 of the universe ;-)

 Cheers,

 Pierre-Yves

 Eelco Hillenius a écrit :
 It is the same kind of problem we have with character encoding. Every
 time someone has a problem with encoding, the answer can be use XXX
 encoding for all and there will be no problem. This is false AND
 irrelevant.
 Well, I guess we hoped that UTF-8 would just work for everyone. It's
 certainly advertised as that. But the message comes across, and the
 more reports we have that something is broken, the harder we'll work
 on it. It's just not all easy, and some of the bugs we are
 encountering lately (like a problem with file descriptors) were not
 our fault in the first place. We're not even sure the encoding
 problems are. But the more people that actually use those encodings
 can help us, possibly by supplying fixes/ solutions, the better.

 It is irrelevant because the question is how to use this
 functionnality and not how to do without it.
 Yes, you are right. You have to understand though that a framework
 can't fix every possible problem in the world. Every time we add a
 feature, there's an open door for 10 additional ones. That doesn't
 mean we don't want to add them, but maybe not now, or we need to be
 convinced about the urgency of the problem.

 It is false because it does not solve the problem. In the case of 
 Ajax
 switching locale, remember the problem is updating the datepicker. If
 you switch the locale in a situation where no datepicker is displayed
 and then load a datepicker through Ajax, it is still broken. But of
 course, the solution is not to use Ajax.
 Well we fixed header contribution through Ajax. It seems that the
 datepicker is the component from hell, as we're having all kinds of
 issues with it we don't have with other components. But Matej and
 others spent many of his free nights trying to fix it and they have
 been progressing very well. It's a pretty tough problem, really.

 Or a slightly better solution:
 do not use Ajax to switch

Re: [Wicket-user] ajax refresh on date picker

I can't find it in releases/wicket-1.2.2, only in trunk, but my app does 
not work with 2.0 :-(

Pierre-Yves

Matej Knopp a écrit :
 Sorry for ambiguity. The fix should be already in.
 
 -Matej
 
 Pierre-Yves Saumont wrote:
 What should already be in? Is it your fix? Or are you talking about 
 the edited file I sent to the list few days ago? This is no complete 
 since at that time I had not noticed the tuesday error!

 Pierre-Yves

 Matej Knopp a écrit :
 btw. it should be already in.

 Pierre-Yves Saumont wrote:
 Hi Matej,

 Of course I will test it as soon as you commit it. BTW, there are 
 plenty of typos and spelling mistakes in the french script, and even 
 an error in the abreviated day names (it says monday, tuesday, 
 tuesday, thursday and there is no wednesday!). Do you want me to 
 send you an edited file?

 Pierre-Yves

 Matej Knopp a écrit :
 Hi,

 I'm working on the date picker encoding problem. What I'll probably 
 do is to convert all non-unicode (latin1, ...) date picker locale 
 strings to utf-8 and add charset=utf-8 to the script element 
 that includes the script.

 This should sove the problem, as xmlhttprequest (used to load 
 script during ajax header contribution) treats the response as 
 utf-8. And the charset in script that should ensure that during 
 regular header contribution the script will be loaded with the 
 correct locale. I'll be commiting soon, would you mind testing if 
 it works for you?

 -Matej

 Pierre-Yves Saumont wrote:
 Hi Eelco,

 I did not feel irritated by your answers and I apologize for 
 having let you think I was. I understand perfectly your position 
 and I acknowledge the immense amount of work there is behind 
 Wicket and I want to thank every one working on it for making such 
 a smart framework available.

 I am building a demo/prototype application for a big french 
 administration and I want to convince them that they should add 
 Wicket to the list of their accepted technologies. That's why I 
 need features that are 100% functionnal. If a feature is only 99% 
 functionnal, it's probably better not to mention it because 
 somebody will certainly pinpoint the 1% that is causing problem, 
 making others forget about the working 99%.

 So, what I am trying to do is helping to find the cause of the 
 problem and (may be) a solution. At this time, I am using a normal 
 link to switch locales and I have removed all accented characters 
 in the datapicker french strings and saved the file in ascii. I am 
 working to find on a better workaround.

 Regarding UTF8, this is (in my opinion) not a good solution. 
 AFAIK, it as been designed to suit the needs of english language 
 applications where only a few exotic foreign characters have to be 
 usable. It's main advantage is that the data is nearly the same 
 size as ascci for this kind of use. I think UTF16 is a much better 
 solution, even if it is not 100% perfect since it can't represent 
 all characters needed in all languages. Next UNICODE encoding will 
 be 32 bits, which will be enough for all characters of all 
 languages in the galaxy. We will then have to design an extension 
 for the rest of the universe ;-)

 Cheers,

 Pierre-Yves

 Eelco Hillenius a écrit :
 It is the same kind of problem we have with character encoding. 
 Every
 time someone has a problem with encoding, the answer can be use 
 XXX
 encoding for all and there will be no problem. This is false AND
 irrelevant.
 Well, I guess we hoped that UTF-8 would just work for everyone. It's
 certainly advertised as that. But the message comes across, and the
 more reports we have that something is broken, the harder we'll work
 on it. It's just not all easy, and some of the bugs we are
 encountering lately (like a problem with file descriptors) were not
 our fault in the first place. We're not even sure the encoding
 problems are. But the more people that actually use those encodings
 can help us, possibly by supplying fixes/ solutions, the better.

 It is irrelevant because the question is how to use this
 functionnality and not how to do without it.
 Yes, you are right. You have to understand though that a framework
 can't fix every possible problem in the world. Every time we add a
 feature, there's an open door for 10 additional ones. That doesn't
 mean we don't want to add them, but maybe not now, or we need to be
 convinced about the urgency of the problem.

 It is false because it does not solve the problem. In the case 
 of Ajax
 switching locale, remember the problem is updating the 
 datepicker. If
 you switch the locale in a situation where no datepicker is 
 displayed
 and then load a datepicker through Ajax, it is still broken. But of
 course, the solution is not to use Ajax.
 Well we fixed header contribution through Ajax. It seems that the
 datepicker is the component from hell, as we're having all kinds of
 issues with it we don't have with other components. But Matej and
 others spent many of his free nights trying to fix

Re: [Wicket-user] ajax refresh on date picker

You won't find it there. It's wicket-1.x (and trunk).

1.2.2 is release. Current branch for 1.2 is under 1.x

-Matej

Pierre-Yves Saumont wrote:
 I can't find it in releases/wicket-1.2.2, only in trunk, but my app does 
 not work with 2.0 :-(
 
 Pierre-Yves
 
 Matej Knopp a écrit :
 Sorry for ambiguity. The fix should be already in.

 -Matej

 Pierre-Yves Saumont wrote:
 What should already be in? Is it your fix? Or are you talking about 
 the edited file I sent to the list few days ago? This is no complete 
 since at that time I had not noticed the tuesday error!

 Pierre-Yves

 Matej Knopp a écrit :
 btw. it should be already in.

 Pierre-Yves Saumont wrote:
 Hi Matej,

 Of course I will test it as soon as you commit it. BTW, there are 
 plenty of typos and spelling mistakes in the french script, and even 
 an error in the abreviated day names (it says monday, tuesday, 
 tuesday, thursday and there is no wednesday!). Do you want me to 
 send you an edited file?

 Pierre-Yves

 Matej Knopp a écrit :
 Hi,

 I'm working on the date picker encoding problem. What I'll probably 
 do is to convert all non-unicode (latin1, ...) date picker locale 
 strings to utf-8 and add charset=utf-8 to the script element 
 that includes the script.

 This should sove the problem, as xmlhttprequest (used to load 
 script during ajax header contribution) treats the response as 
 utf-8. And the charset in script that should ensure that during 
 regular header contribution the script will be loaded with the 
 correct locale. I'll be commiting soon, would you mind testing if 
 it works for you?

 -Matej

 Pierre-Yves Saumont wrote:
 Hi Eelco,

 I did not feel irritated by your answers and I apologize for 
 having let you think I was. I understand perfectly your position 
 and I acknowledge the immense amount of work there is behind 
 Wicket and I want to thank every one working on it for making such 
 a smart framework available.

 I am building a demo/prototype application for a big french 
 administration and I want to convince them that they should add 
 Wicket to the list of their accepted technologies. That's why I 
 need features that are 100% functionnal. If a feature is only 99% 
 functionnal, it's probably better not to mention it because 
 somebody will certainly pinpoint the 1% that is causing problem, 
 making others forget about the working 99%.

 So, what I am trying to do is helping to find the cause of the 
 problem and (may be) a solution. At this time, I am using a normal 
 link to switch locales and I have removed all accented characters 
 in the datapicker french strings and saved the file in ascii. I am 
 working to find on a better workaround.

 Regarding UTF8, this is (in my opinion) not a good solution. 
 AFAIK, it as been designed to suit the needs of english language 
 applications where only a few exotic foreign characters have to be 
 usable. It's main advantage is that the data is nearly the same 
 size as ascci for this kind of use. I think UTF16 is a much better 
 solution, even if it is not 100% perfect since it can't represent 
 all characters needed in all languages. Next UNICODE encoding will 
 be 32 bits, which will be enough for all characters of all 
 languages in the galaxy. We will then have to design an extension 
 for the rest of the universe ;-)

 Cheers,

 Pierre-Yves

 Eelco Hillenius a écrit :
 It is the same kind of problem we have with character encoding. 
 Every
 time someone has a problem with encoding, the answer can be use 
 XXX
 encoding for all and there will be no problem. This is false AND
 irrelevant.
 Well, I guess we hoped that UTF-8 would just work for everyone. It's
 certainly advertised as that. But the message comes across, and the
 more reports we have that something is broken, the harder we'll work
 on it. It's just not all easy, and some of the bugs we are
 encountering lately (like a problem with file descriptors) were not
 our fault in the first place. We're not even sure the encoding
 problems are. But the more people that actually use those encodings
 can help us, possibly by supplying fixes/ solutions, the better.

 It is irrelevant because the question is how to use this
 functionnality and not how to do without it.
 Yes, you are right. You have to understand though that a framework
 can't fix every possible problem in the world. Every time we add a
 feature, there's an open door for 10 additional ones. That doesn't
 mean we don't want to add them, but maybe not now, or we need to be
 convinced about the urgency of the problem.

 It is false because it does not solve the problem. In the case 
 of Ajax
 switching locale, remember the problem is updating the 
 datepicker. If
 you switch the locale in a situation where no datepicker is 
 displayed
 and then load a datepicker through Ajax, it is still broken. But of
 course, the solution is not to use Ajax.
 Well we fixed header contribution through Ajax. It seems that the
 datepicker is the component from hell,

Re: [Wicket-user] ajax refresh on date picker

Now it seems to work fine provided the locale switching is made through 
reloading the page and not through Ajax. (I enclosed the modified french 
scripts, in utf8 and iso.)


If switching is made through Ajax, it works much better than it did 
before. If the datepicker is visible when switching, switching works 
fine. If the datepicker is not visible when switching, and then is is 
loaded through Ajax, it does not always acknowledge the switch.


But the worst problem is that reloading the page after a locale switch 
(which before made the datepicker to swith to the new locale) now cause 
an exception:


Root cause:java.lang.IllegalStateException: Cannot remove 
[MarkupContainer [Component id = 6, page = No Page, path = 
6.Loop$LoopItem]] from null parent! at 
wicket.Component.remove(Component.java:1475) at 
wicket.version.undo.Add.undo(Add.java:81) at 
wicket.version.undo.ChangeList.undo(ChangeList.java:93) at 
wicket.version.undo.UndoPageVersionManager.undo(UndoPageVersionManager.java:217) 
at 
wicket.version.undo.UndoPageVersionManager.getVersion(UndoPageVersionManager.java:167)


I also somtime get this exception:

java.lang.NullPointerException
at wicket.MarkupFragmentFinder.find(MarkupFragmentFinder.java:76)
at wicket.Component.renderComponent(Component.java:1599)
	at 
wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:474)



However, having it working with full page reload is a very good point. I 
think it will be enough



Pierre-Yves

Matej Knopp a écrit :

You won't find it there. It's wicket-1.x (and trunk).

1.2.2 is release. Current branch for 1.2 is under 1.x

-Matej

Pierre-Yves Saumont wrote:
I can't find it in releases/wicket-1.2.2, only in trunk, but my app 
does not work with 2.0 :-(


Pierre-Yves

Matej Knopp a écrit :

Sorry for ambiguity. The fix should be already in.

-Matej

Pierre-Yves Saumont wrote:
What should already be in? Is it your fix? Or are you talking about 
the edited file I sent to the list few days ago? This is no complete 
since at that time I had not noticed the tuesday error!


Pierre-Yves

Matej Knopp a écrit :

btw. it should be already in.

Pierre-Yves Saumont wrote:

Hi Matej,

Of course I will test it as soon as you commit it. BTW, there are 
plenty of typos and spelling mistakes in the french script, and 
even an error in the abreviated day names (it says monday, 
tuesday, tuesday, thursday and there is no wednesday!). Do you 
want me to send you an edited file?


Pierre-Yves

Matej Knopp a écrit :

Hi,

I'm working on the date picker encoding problem. What I'll 
probably do is to convert all non-unicode (latin1, ...) date 
picker locale strings to utf-8 and add charset=utf-8 to the 
script element that includes the script.


This should sove the problem, as xmlhttprequest (used to load 
script during ajax header contribution) treats the response as 
utf-8. And the charset in script that should ensure that during 
regular header contribution the script will be loaded with the 
correct locale. I'll be commiting soon, would you mind testing if 
it works for you?


-Matej

Pierre-Yves Saumont wrote:

Hi Eelco,

I did not feel irritated by your answers and I apologize for 
having let you think I was. I understand perfectly your position 
and I acknowledge the immense amount of work there is behind 
Wicket and I want to thank every one working on it for making 
such a smart framework available.


I am building a demo/prototype application for a big french 
administration and I want to convince them that they should add 
Wicket to the list of their accepted technologies. That's why I 
need features that are 100% functionnal. If a feature is only 
99% functionnal, it's probably better not to mention it because 
somebody will certainly pinpoint the 1% that is causing problem, 
making others forget about the working 99%.


So, what I am trying to do is helping to find the cause of the 
problem and (may be) a solution. At this time, I am using a 
normal link to switch locales and I have removed all accented 
characters in the datapicker french strings and saved the file 
in ascii. I am working to find on a better workaround.


Regarding UTF8, this is (in my opinion) not a good solution. 
AFAIK, it as been designed to suit the needs of english language 
applications where only a few exotic foreign characters have to 
be usable. It's main advantage is that the data is nearly the 
same size as ascci for this kind of use. I think UTF16 is a much 
better solution, even if it is not 100% perfect since it can't 
represent all characters needed in all languages. Next UNICODE 
encoding will be 32 bits, which will be enough for all 
characters of all languages in the galaxy. We will then have to 
design an extension for the rest of the universe ;-)


Cheers,

Pierre-Yves

Eelco Hillenius a écrit :
It is the same kind of problem we have with character 
encoding. Every
time someone has a problem with encoding, the answer can

Re: [Wicket-user] ajax refresh on date picker

2006-09-26 Thread Matej Knopp

The problem was that AjaxRequestTarget called component.renderHead(), 
without calling rendered() on component behaviors after that (co the 
thread local has not been cleaned).

The fix is in SVN. Can you please test if it works for you? It works 
with the quick start you've provided, so I'd say it should also work 
with your application.

Thanks a lot for helping to nail down this nasty bug.

-Matej

samyem wrote:
 Okay I have got something that'll make you happy: wicket quickstart! Pick it
 up at  http://www.yomari.net/~samyem/problem-wicket-quickstart.zip
 
 It has two pages. The first page is okay. Click on the link to go to the
 second one. And click on the Click here to add one link. Nothing will
 happen. Refresh the page (F5 will do). Now click on the same link again, and
 everything works. 
 
 I've identified the problem to be the way the ajax behaviour clears the
 ThreadLocal variable, as I've explained in the other email. But I am not too
 sure what is a proper fix for this problem.
 
 This quick start has the essentials of the way I am using wicket. I cannot
 do it anyother way due to the application's requirements. I've got it
 working in my case for now by moving the ThreadLocal variable one step up in
 AbstractBehavior and making the cleanup method in AbstractBehavior set the
 ThreadLocal to null. That fixed this  problem apparently, but I'll let you
 have the final say on this.
 
 - Samyem
 
 
 
 Matej Knopp wrote:
 No matter what I do I just can't reproduce this. Can you please double 
 check that you're using branch wicket-1.x or trunk, and a clean build?

 If the problem persists, can you please either check if it happens with 
 wicket-examples too or try to isolate the problem and provide a 
 quickstart example? I'll be more than happy to look at it.

 Thanks,

 -Matej

 samyem wrote:
 Upon further investigations, what is clear is that when the page first
 loads,
 it loads up all the java scripts in the header. When I do a page refresh
 by
 pressing F5, the ensuing page does not render the javascript references
 at
 all. Looks like there is some logic which prevents javascripts from
 rendering after the initial page display. Here is what I am seeing in my
 HEAD tag :

 Initial page load:

 ?
 head
 meta http-equiv=Content-Type content=text/html;
 charset=ISO-8859-1title?/title
 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js/script
 script type=text/javascript
 id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/
 wicketAjaxDebugEnable=true;
 /*--]]*//script

 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js/script
 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js/script
 script type=text/javascript
 src=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js/script
 link rel=stylesheet type=text/css
 href=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css
 link rel=stylesheet type=text/css
 href=/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css
 script type=text/javascript!--/*--![CDATA[/*!--*/
 if (window.name=='') {
 window.location=/mm/app?wicket:bookmarkablePage=wicket-0:com.wsi.mm.ui.media.MediaPage;
 }
 /*--]]*//script
 /head

 Subsequent refreshes:

 head
 meta http-equiv=Content-Type content=text/html;
 charset=ISO-8859-1title?/title
 
 script type=text/javascript!--/*--![CDATA[/*!--*/
 if (window.name=='') {
 window.location=/mm/app?wicket:bookmarkablePage=wicket-1:com.wsi.mm.ui.media.MediaPage;
 }
 /*--]]*//script
 /head

 Now I think we should be able to pinpoint the problem at the moment.




 samyem wrote:
 I am also getting this new error after the update:

 Error: wicketAjaxGet is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:11:1:
 Line: 1



 samyem wrote:
 I updated wicket and wicket-extension and now my modal window is not
 even
 showing and the date picker does not show up in non modal window pages
 as
 well. I can only see the error through the ajax debugger as:

 ...
 NFO: Response parsed. Now invoking steps...
 INFO:
 INFO: Initiating Ajax GET request on /mm/calendar.js
 INFO: Invoking pre-call handler(s)...
 ERROR: Received Ajax response with code: 404
 INFO: Invoking post-call handler(s)...
 INFO: Invoking failure handler(s)...
 ...

 After this, further clicks gives this error:

 INFO: Chanel busy - postponing...

 On non-modal pages, I get things like:

 Error: Calendar is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:13::
 Line: 214

 And even my auto-complete text box is broken now with the latest code.
 I
 get things like:

 Error: Wicket.Ajax has no properties
 Source File: http://localhost:8081/mm/javascript/wicket-autocomplete.js
 Line: 7

 And the auto-complete fails to work. Nontheless, other ajax behaviour
 like

Re: [Wicket-user] ajax refresh on date picker

2006-09-26 Thread Pierre-Yves Saumont

Is it fixed only in trunk or also in releases ?

Pierre-Yves

Matej Knopp a écrit :
 The problem was that AjaxRequestTarget called component.renderHead(), 
 without calling rendered() on component behaviors after that (co the 
 thread local has not been cleaned).
 
 The fix is in SVN. Can you please test if it works for you? It works 
 with the quick start you've provided, so I'd say it should also work 
 with your application.
 
 Thanks a lot for helping to nail down this nasty bug.
 
 -Matej
 
 samyem wrote:
 Okay I have got something that'll make you happy: wicket quickstart! Pick it
 up at  http://www.yomari.net/~samyem/problem-wicket-quickstart.zip

 It has two pages. The first page is okay. Click on the link to go to the
 second one. And click on the Click here to add one link. Nothing will
 happen. Refresh the page (F5 will do). Now click on the same link again, and
 everything works. 

 I've identified the problem to be the way the ajax behaviour clears the
 ThreadLocal variable, as I've explained in the other email. But I am not too
 sure what is a proper fix for this problem.

 This quick start has the essentials of the way I am using wicket. I cannot
 do it anyother way due to the application's requirements. I've got it
 working in my case for now by moving the ThreadLocal variable one step up in
 AbstractBehavior and making the cleanup method in AbstractBehavior set the
 ThreadLocal to null. That fixed this  problem apparently, but I'll let you
 have the final say on this.

 - Samyem



 Matej Knopp wrote:
 No matter what I do I just can't reproduce this. Can you please double 
 check that you're using branch wicket-1.x or trunk, and a clean build?

 If the problem persists, can you please either check if it happens with 
 wicket-examples too or try to isolate the problem and provide a 
 quickstart example? I'll be more than happy to look at it.

 Thanks,

 -Matej

 samyem wrote:
 Upon further investigations, what is clear is that when the page first
 loads,
 it loads up all the java scripts in the header. When I do a page refresh
 by
 pressing F5, the ensuing page does not render the javascript references
 at
 all. Looks like there is some logic which prevents javascripts from
 rendering after the initial page display. Here is what I am seeing in my
 HEAD tag :

 Initial page load:

 ?
 head
meta http-equiv=Content-Type content=text/html;
 charset=ISO-8859-1title?/title
 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js/script
 script type=text/javascript
 id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/
 wicketAjaxDebugEnable=true;
 /*--]]*//script

 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js/script
 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js/script
 script type=text/javascript
 src=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js/script
 link rel=stylesheet type=text/css
 href=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css
 link rel=stylesheet type=text/css
 href=/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css
 script type=text/javascript!--/*--![CDATA[/*!--*/
 if (window.name=='') {
 window.location=/mm/app?wicket:bookmarkablePage=wicket-0:com.wsi.mm.ui.media.MediaPage;
 }
 /*--]]*//script
 /head

 Subsequent refreshes:

 head
meta http-equiv=Content-Type content=text/html;
 charset=ISO-8859-1title?/title

 script type=text/javascript!--/*--![CDATA[/*!--*/
 if (window.name=='') {
 window.location=/mm/app?wicket:bookmarkablePage=wicket-1:com.wsi.mm.ui.media.MediaPage;
 }
 /*--]]*//script
 /head

 Now I think we should be able to pinpoint the problem at the moment.




 samyem wrote:
 I am also getting this new error after the update:

 Error: wicketAjaxGet is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:11:1:
 Line: 1



 samyem wrote:
 I updated wicket and wicket-extension and now my modal window is not
 even
 showing and the date picker does not show up in non modal window pages
 as
 well. I can only see the error through the ajax debugger as:

 ...
 NFO: Response parsed. Now invoking steps...
 INFO:
 INFO: Initiating Ajax GET request on /mm/calendar.js
 INFO: Invoking pre-call handler(s)...
 ERROR: Received Ajax response with code: 404
 INFO: Invoking post-call handler(s)...
 INFO: Invoking failure handler(s)...
 ...

 After this, further clicks gives this error:

 INFO: Chanel busy - postponing...

 On non-modal pages, I get things like:

 Error: Calendar is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:13::
 Line: 214

 And even my auto-complete text box is broken now with the latest code.
 I
 get things like:

 Error: Wicket.Ajax has no properties
 Source File: http://localhost:8081/mm/javascript/wicket-autocomplete.js

Re: [Wicket-user] ajax refresh on date picker

2006-09-26 Thread samyem


So far so good. Now if only the z-index issue can be cleanly fixed. I still
have other issues that I'll post in other threads.

- Samyem


Matej Knopp wrote:
 
 The problem was that AjaxRequestTarget called component.renderHead(), 
 without calling rendered() on component behaviors after that (co the 
 thread local has not been cleaned).
 
 The fix is in SVN. Can you please test if it works for you? It works 
 with the quick start you've provided, so I'd say it should also work 
 with your application.
 
 Thanks a lot for helping to nail down this nasty bug.
 
 -Matej
 
 samyem wrote:
 Okay I have got something that'll make you happy: wicket quickstart! Pick
 it
 up at  http://www.yomari.net/~samyem/problem-wicket-quickstart.zip
 
 It has two pages. The first page is okay. Click on the link to go to the
 second one. And click on the Click here to add one link. Nothing will
 happen. Refresh the page (F5 will do). Now click on the same link again,
 and
 everything works. 
 
 I've identified the problem to be the way the ajax behaviour clears the
 ThreadLocal variable, as I've explained in the other email. But I am not
 too
 sure what is a proper fix for this problem.
 
 This quick start has the essentials of the way I am using wicket. I
 cannot
 do it anyother way due to the application's requirements. I've got it
 working in my case for now by moving the ThreadLocal variable one step up
 in
 AbstractBehavior and making the cleanup method in AbstractBehavior set
 the
 ThreadLocal to null. That fixed this  problem apparently, but I'll let
 you
 have the final say on this.
 
 - Samyem
 
 
 
 Matej Knopp wrote:
 No matter what I do I just can't reproduce this. Can you please double 
 check that you're using branch wicket-1.x or trunk, and a clean build?

 If the problem persists, can you please either check if it happens with 
 wicket-examples too or try to isolate the problem and provide a 
 quickstart example? I'll be more than happy to look at it.

 Thanks,

 -Matej

 samyem wrote:
 Upon further investigations, what is clear is that when the page first
 loads,
 it loads up all the java scripts in the header. When I do a page
 refresh
 by
 pressing F5, the ensuing page does not render the javascript references
 at
 all. Looks like there is some logic which prevents javascripts from
 rendering after the initial page display. Here is what I am seeing in
 my
 HEAD tag :

 Initial page load:

 ?
 head
meta http-equiv=Content-Type content=text/html;
 charset=ISO-8859-1title?/title
 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js/script
 script type=text/javascript
 id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/
 wicketAjaxDebugEnable=true;
 /*--]]*//script

 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js/script
 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js/script
 script type=text/javascript
 src=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js/script
 link rel=stylesheet type=text/css
 href=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css
 link rel=stylesheet type=text/css
 href=/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css
 script type=text/javascript!--/*--![CDATA[/*!--*/
 if (window.name=='') {
 window.location=/mm/app?wicket:bookmarkablePage=wicket-0:com.wsi.mm.ui.media.MediaPage;
 }
 /*--]]*//script
 /head

 Subsequent refreshes:

 head
meta http-equiv=Content-Type content=text/html;
 charset=ISO-8859-1title?/title

 script type=text/javascript!--/*--![CDATA[/*!--*/
 if (window.name=='') {
 window.location=/mm/app?wicket:bookmarkablePage=wicket-1:com.wsi.mm.ui.media.MediaPage;
 }
 /*--]]*//script
 /head

 Now I think we should be able to pinpoint the problem at the moment.




 samyem wrote:
 I am also getting this new error after the update:

 Error: wicketAjaxGet is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:11:1:
 Line: 1



 samyem wrote:
 I updated wicket and wicket-extension and now my modal window is not
 even
 showing and the date picker does not show up in non modal window
 pages
 as
 well. I can only see the error through the ajax debugger as:

 ...
 NFO: Response parsed. Now invoking steps...
 INFO:
 INFO: Initiating Ajax GET request on /mm/calendar.js
 INFO: Invoking pre-call handler(s)...
 ERROR: Received Ajax response with code: 404
 INFO: Invoking post-call handler(s)...
 INFO: Invoking failure handler(s)...
 ...

 After this, further clicks gives this error:

 INFO: Chanel busy - postponing...

 On non-modal pages, I get things like:

 Error: Calendar is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:13::
 Line: 214

 And even my auto-complete text box is broken now with the latest
 code.
 I
 get things like:

 Error: Wicket.Ajax

Re: [Wicket-user] ajax refresh on date picker

2006-09-26 Thread Matej Knopp

It also is fixed in wicket-1.x

-Matej

Pierre-Yves Saumont wrote:
 Is it fixed only in trunk or also in releases ?
 
 Pierre-Yves
 
 Matej Knopp a écrit :
 The problem was that AjaxRequestTarget called component.renderHead(), 
 without calling rendered() on component behaviors after that (co the 
 thread local has not been cleaned).

 The fix is in SVN. Can you please test if it works for you? It works 
 with the quick start you've provided, so I'd say it should also work 
 with your application.

 Thanks a lot for helping to nail down this nasty bug.

 -Matej

 samyem wrote:
 Okay I have got something that'll make you happy: wicket quickstart! Pick it
 up at  http://www.yomari.net/~samyem/problem-wicket-quickstart.zip

 It has two pages. The first page is okay. Click on the link to go to the
 second one. And click on the Click here to add one link. Nothing will
 happen. Refresh the page (F5 will do). Now click on the same link again, and
 everything works. 

 I've identified the problem to be the way the ajax behaviour clears the
 ThreadLocal variable, as I've explained in the other email. But I am not too
 sure what is a proper fix for this problem.

 This quick start has the essentials of the way I am using wicket. I cannot
 do it anyother way due to the application's requirements. I've got it
 working in my case for now by moving the ThreadLocal variable one step up in
 AbstractBehavior and making the cleanup method in AbstractBehavior set the
 ThreadLocal to null. That fixed this  problem apparently, but I'll let you
 have the final say on this.

 - Samyem



 Matej Knopp wrote:
 No matter what I do I just can't reproduce this. Can you please double 
 check that you're using branch wicket-1.x or trunk, and a clean build?

 If the problem persists, can you please either check if it happens with 
 wicket-examples too or try to isolate the problem and provide a 
 quickstart example? I'll be more than happy to look at it.

 Thanks,

 -Matej

 samyem wrote:
 Upon further investigations, what is clear is that when the page first
 loads,
 it loads up all the java scripts in the header. When I do a page refresh
 by
 pressing F5, the ensuing page does not render the javascript references
 at
 all. Looks like there is some logic which prevents javascripts from
 rendering after the initial page display. Here is what I am seeing in my
 HEAD tag :

 Initial page load:

 ?
 head
   meta http-equiv=Content-Type content=text/html;
 charset=ISO-8859-1title?/title
 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js/script
 script type=text/javascript
 id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/
 wicketAjaxDebugEnable=true;
 /*--]]*//script

 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js/script
 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js/script
 script type=text/javascript
 src=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js/script
 link rel=stylesheet type=text/css
 href=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css
 link rel=stylesheet type=text/css
 href=/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css
 script type=text/javascript!--/*--![CDATA[/*!--*/
 if (window.name=='') {
 window.location=/mm/app?wicket:bookmarkablePage=wicket-0:com.wsi.mm.ui.media.MediaPage;
 }
 /*--]]*//script
 /head

 Subsequent refreshes:

 head
   meta http-equiv=Content-Type content=text/html;
 charset=ISO-8859-1title?/title
   
 script type=text/javascript!--/*--![CDATA[/*!--*/
 if (window.name=='') {
 window.location=/mm/app?wicket:bookmarkablePage=wicket-1:com.wsi.mm.ui.media.MediaPage;
 }
 /*--]]*//script
 /head

 Now I think we should be able to pinpoint the problem at the moment.




 samyem wrote:
 I am also getting this new error after the update:

 Error: wicketAjaxGet is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:11:1:
 Line: 1



 samyem wrote:
 I updated wicket and wicket-extension and now my modal window is not
 even
 showing and the date picker does not show up in non modal window pages
 as
 well. I can only see the error through the ajax debugger as:

 ...
 NFO: Response parsed. Now invoking steps...
 INFO:
 INFO: Initiating Ajax GET request on /mm/calendar.js
 INFO: Invoking pre-call handler(s)...
 ERROR: Received Ajax response with code: 404
 INFO: Invoking post-call handler(s)...
 INFO: Invoking failure handler(s)...
 ...

 After this, further clicks gives this error:

 INFO: Chanel busy - postponing...

 On non-modal pages, I get things like:

 Error: Calendar is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:13::
 Line: 214

 And even my auto-complete text box is broken now with the latest code.
 I
 get things like:

 Error: Wicket.Ajax has no properties
 Source

Re: [Wicket-user] ajax refresh on date picker

2006-09-26 Thread Pierre-Yves Saumont

It works now much better, but still not correctly. Changing the locale
when the datepicker is not displayed, and then loading the datepicker
through Ajax dont work. The datepicker does not use the new locale.

I finally decided to apply the solution proposed by Eelco (only change
locale through a normal link so that the whole page is reloaded)
although I feel it is like closing our eyes and pretended the problem is
solved. Anyway, it does not work neither. When the locale switch is done
by reloading a page that contains a datepicker, its ok. However, if the
switch is done on a page that does not contain the date picker, and then
the datepicker is loaded through Ajax, it produces an error. The error
reported by IE6 is:

Line: 100514085
Char: 6
Error: String constant not closed
Code: 0
URL: http://localhost:8080/myapp/app?wicket:interface=:1:3

(A very big application with 100514085 lines!)

I think this is due to a character encoding problem with the
calendar-fr.js script. The file is in ascii. Switching to UNICODE solves
the problem. Switching to UTF-8 does not. If the app is in ISO, UTF8
character in scripts won't be correctly interpreted. As far as I tested
(not very deeply though) UNICODE (UTF16) is ok.

But unfortunately, it's only ok in IE. Now, it is broken in Firefox. On
Ajax load, the datepicker don't work. It works through Ajax with a UTF8
file, but it don't if the entire page is loaded. (Datepicker work, but
the encoding is wrong.)

Pierre-Yves

Matej Knopp a écrit :
It also is fixed in wicket-1.x

-Matej

Pierre-Yves Saumont wrote:
Is it fixed only in trunk or also in releases ?

Pierre-Yves

Matej Knopp a écrit :
The problem was that AjaxRequestTarget called component.renderHead(),
without calling rendered() on component behaviors after that (co the
thread local has not been cleaned).

The fix is in SVN. Can you please test if it works for you? It works
with the quick start you've provided, so I'd say it should also work
with your application.

Thanks a lot for helping to nail down this nasty bug.

-Matej

samyem wrote:
Okay I have got something that'll make you happy: wicket quickstart!
Pick it
up at http://www.yomari.net/~samyem/problem-wicket-quickstart.zip

It has two pages. The first page is okay. Click on the link to go to
the
second one. And click on the Click here to add one link. Nothing will
happen. Refresh the page (F5 will do). Now click on the same link
again, and
everything works.
I've identified the problem to be the way the ajax behaviour clears the
ThreadLocal variable, as I've explained in the other email. But I am
not too
sure what is a proper fix for this problem.

This quick start has the essentials of the way I am using wicket. I
cannot
do it anyother way due to the application's requirements. I've got it
working in my case for now by moving the ThreadLocal variable one
step up in
AbstractBehavior and making the cleanup method in AbstractBehavior
set the
ThreadLocal to null. That fixed this problem apparently, but I'll
let you
have the final say on this.

- Samyem

Matej Knopp wrote:
No matter what I do I just can't reproduce this. Can you please
double check that you're using branch wicket-1.x or trunk, and a
clean build?

If the problem persists, can you please either check if it happens
with wicket-examples too or try to isolate the problem and provide
a quickstart example? I'll be more than happy to look at it.

Thanks,

-Matej

samyem wrote:
Upon further investigations, what is clear is that when the page
first
loads,
it loads up all the java scripts in the header. When I do a page
refresh
by
pressing F5, the ensuing page does not render the javascript
references
at
all. Looks like there is some logic which prevents javascripts from
rendering after the initial page display. Here is what I am seeing
in my
HEAD tag :

Initial page load:

?
head
meta http-equiv=Content-Type content=text/html;
charset=ISO-8859-1title?/title
script type=text/javascript
src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js/script

script type=text/javascript
id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/
wicketAjaxDebugEnable=true;
/*--]]*//script

script type=text/javascript
src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js/script

script type=text/javascript
src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js/script

script type=text/javascript
src=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js/script

link rel=stylesheet type=text/css
href=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css

link rel=stylesheet type=text/css
href=/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css

script type=text/javascript!--/*--![CDATA[/*!--*/
if (window.name=='') {

Re: [Wicket-user] ajax refresh on date picker

2006-09-26 Thread Eelco Hillenius

 I finally decided to apply the solution proposed by Eelco (only change
 locale through a normal link so that the whole page is reloaded)
 although I feel it is like closing our eyes and pretended the problem is
 solved.

I don't agree with that. Changing the locale potentially has effect on
the whole page anyway, so changing it with a full refresh makes sense.
Also, I think it's a pretty extreme corner case to want to use Ajax to
switch the session's locale. Unless it is something users do 50 times
per session, which seems unlikely.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] ajax refresh on date picker

2006-09-26 Thread Pierre-Yves Saumont

Well, I believe a functionnality should work whatever teh reason you 
have to use it. I agree it make sense to refresh the whole page... if it 
is what you want. If it is not what you need, it makes very little 
sense. Of course, it it does not work, I will not use it. No choice. But 
I think it would be safer to know why it does not work, since 
technically, it should. Or shouldn't it? But why?

It is the same kind of problem we have with character encoding. Every 
time someone has a problem with encoding, the answer can be use XXX 
encoding for all and there will be no problem. This is false AND 
irrelevant.

It is irrelevant because the question is how to use this 
functionnality and not how to do without it.

It is false because it does not solve the problem. In the case of Ajax 
switching locale, remember the problem is updating the datepicker. If 
you switch the locale in a situation where no datepicker is displayed 
and then load a datepicker through Ajax, it is still broken. But of 
course, the solution is not to use Ajax. Or a slightly better solution: 
do not use Ajax to switch locales AND do not use anything else than US 
ASCII in the datepicker labels.

Pierre-Yves


Eelco Hillenius a écrit :
 I finally decided to apply the solution proposed by Eelco (only change
 locale through a normal link so that the whole page is reloaded)
 although I feel it is like closing our eyes and pretended the problem is
 solved.
 
 I don't agree with that. Changing the locale potentially has effect on
 the whole page anyway, so changing it with a full refresh makes sense.
 Also, I think it's a pretty extreme corner case to want to use Ajax to
 switch the session's locale. Unless it is something users do 50 times
 per session, which seems unlikely.
 
 Eelco
 
 
 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] ajax refresh on date picker

2006-09-26 Thread Eelco Hillenius

 It is the same kind of problem we have with character encoding. Every
 time someone has a problem with encoding, the answer can be use XXX
 encoding for all and there will be no problem. This is false AND
 irrelevant.

Well, I guess we hoped that UTF-8 would just work for everyone. It's
certainly advertised as that. But the message comes across, and the
more reports we have that something is broken, the harder we'll work
on it. It's just not all easy, and some of the bugs we are
encountering lately (like a problem with file descriptors) were not
our fault in the first place. We're not even sure the encoding
problems are. But the more people that actually use those encodings
can help us, possibly by supplying fixes/ solutions, the better.

 It is irrelevant because the question is how to use this
 functionnality and not how to do without it.

Yes, you are right. You have to understand though that a framework
can't fix every possible problem in the world. Every time we add a
feature, there's an open door for 10 additional ones. That doesn't
mean we don't want to add them, but maybe not now, or we need to be
convinced about the urgency of the problem.

 It is false because it does not solve the problem. In the case of Ajax
 switching locale, remember the problem is updating the datepicker. If
 you switch the locale in a situation where no datepicker is displayed
 and then load a datepicker through Ajax, it is still broken. But of
 course, the solution is not to use Ajax.

Well we fixed header contribution through Ajax. It seems that the
datepicker is the component from hell, as we're having all kinds of
issues with it we don't have with other components. But Matej and
others spent many of his free nights trying to fix it and they have
been progressing very well. It's a pretty tough problem, really.

 Or a slightly better solution:
 do not use Ajax to switch locales AND do not use anything else than US
 ASCII in the datepicker labels.

I didn't get the datepicker labels. Anything that has to do with the
JavaScript part that is faulty: I'm sorry but we can't do much about
it as we adopted that component from another project (jscalendar).
We're working on a replacement, and people can always create their own
replacement too (for intance, look at wicket-contrib-datepicker and
wicket-contrib-yui.

I'm sorry you feel irritated by our answers. You are right that
telling you you can't do that is not a very satisfying answer.
Please understand that we are working our asses off in our free time,
un-sponsored etc to make this framework as good as we can, as fast as
we can. Keep those reports coming, and the best and fastest way to get
a bug fixed is to give us a solution for fixing it.

Cheers,

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] ajax refresh on date picker

2006-09-26 Thread Matej Knopp

The reason why locale switching using ajax link on datepicker is, that 
ajax header contribution is for performance reasons done only once per 
component instance (until the entire page is refreshed).
The reason is reduce amount of data sent to browser on every ajax call.

The Unicode problem also happens when using datepicker without ajax 
header contribution? Because during header contribution the javascript 
file is retrieved using an xmlhttprequest. There is no way how to 
specify encoding in javascript, is it? Maybe we could send encoding in 
the header from server, but how do we detect it?

Datepicker is an external component. There are all kinds of trouble with 
it, it definitely wasn't built with header contribution in mind, but we 
are working to support is as good as we can.

Does the String constant not closed error happens for all locales, or 
only for specific one?

-Matej

Pierre-Yves Saumont wrote:
 It works now much better, but still not correctly. Changing the locale 
 when the datepicker is not displayed, and then loading the datepicker 
 through Ajax dont work. The datepicker does not use the new locale.
 
 I finally decided to apply the solution proposed by Eelco (only change 
 locale through a normal link so that the whole page is reloaded) 
 although I feel it is like closing our eyes and pretended the problem is 
 solved. Anyway, it does not work neither. When the locale switch is done 
 by reloading a page that contains a datepicker, its ok. However, if the 
 switch is done on a page that does not contain the date picker, and then 
 the datepicker is loaded through Ajax, it produces an error. The error 
 reported by IE6 is:
 
 Line: 100514085
 Char: 6
 Error: String constant not closed
 Code: 0
 URL: http://localhost:8080/myapp/app?wicket:interface=:1:3
 
 (A very big application with 100514085 lines!)
 
 I think this is due to a character encoding problem with the 
 calendar-fr.js script. The file is in ascii. Switching to UNICODE solves 
 the problem. Switching to UTF-8 does not. If the app is in ISO, UTF8 
 character in scripts won't be correctly interpreted. As far as I tested 
 (not very deeply though) UNICODE (UTF16) is ok.
 
 But unfortunately, it's only ok in IE. Now, it is broken in Firefox. On 
 Ajax load, the datepicker don't work. It works through Ajax with a UTF8 
 file, but it don't if the entire page is loaded. (Datepicker work, but 
 the encoding is wrong.)
 
 Pierre-Yves
 
 Matej Knopp a écrit :
 It also is fixed in wicket-1.x

 -Matej

 Pierre-Yves Saumont wrote:
 Is it fixed only in trunk or also in releases ?

 Pierre-Yves

 Matej Knopp a écrit :
 The problem was that AjaxRequestTarget called component.renderHead(), 
 without calling rendered() on component behaviors after that (co the 
 thread local has not been cleaned).

 The fix is in SVN. Can you please test if it works for you? It works 
 with the quick start you've provided, so I'd say it should also work 
 with your application.

 Thanks a lot for helping to nail down this nasty bug.

 -Matej

 samyem wrote:
 Okay I have got something that'll make you happy: wicket quickstart! 
 Pick it
 up at  http://www.yomari.net/~samyem/problem-wicket-quickstart.zip

 It has two pages. The first page is okay. Click on the link to go to 
 the
 second one. And click on the Click here to add one link. Nothing will
 happen. Refresh the page (F5 will do). Now click on the same link 
 again, and
 everything works.
 I've identified the problem to be the way the ajax behaviour clears the
 ThreadLocal variable, as I've explained in the other email. But I am 
 not too
 sure what is a proper fix for this problem.

 This quick start has the essentials of the way I am using wicket. I 
 cannot
 do it anyother way due to the application's requirements. I've got it
 working in my case for now by moving the ThreadLocal variable one 
 step up in
 AbstractBehavior and making the cleanup method in AbstractBehavior 
 set the
 ThreadLocal to null. That fixed this  problem apparently, but I'll 
 let you
 have the final say on this.

 - Samyem



 Matej Knopp wrote:
 No matter what I do I just can't reproduce this. Can you please 
 double check that you're using branch wicket-1.x or trunk, and a 
 clean build?

 If the problem persists, can you please either check if it happens 
 with wicket-examples too or try to isolate the problem and provide 
 a quickstart example? I'll be more than happy to look at it.

 Thanks,

 -Matej

 samyem wrote:
 Upon further investigations, what is clear is that when the page 
 first
 loads,
 it loads up all the java scripts in the header. When I do a page 
 refresh
 by
 pressing F5, the ensuing page does not render the javascript 
 references
 at
 all. Looks like there is some logic which prevents javascripts from
 rendering after the initial page display. Here is what I am seeing 
 in my
 HEAD tag :

 Initial page load:

 ?
 head
 meta http-equiv=Content-Type content=text/html;

Re: [Wicket-user] ajax refresh on date picker

2006-09-25 Thread Martijn Dashorst

Just thinking out loud:

the modal window knows its z-index. can't we put an extra div (or
span) inside that elevates all components inside to have
newModalWindow.z-index + 1?

As the modal window is displayed we use javascript. It wouldn't be
hard I suspect to change the z-index of the inner span?

Martijn

On 9/24/06, samyem [EMAIL PROTECTED] wrote:

 Thanks. I've fixed the z-index problem in my app by manually resetting the
 z-index in my HTML, thus overriding the default values set by the
 components. So hopefully now everything will run smoothly.

 Thanks for the fix again,
 Samyem


 Matej Knopp wrote:
 
  The fix is in svn. (both 1.x and 2.0)
  DatePicker in modal window panel now works, although the issue with
  z-index still remains. As a side effect this also fixes the component
  use check for components that render into head, so calling
  getDebugSettings().setComponentUseCheck(false) in application#init is no
  longer necessary.
 
  I'd appreciate if everyone who has issues with header contribution test
  it with current svn. The more bugs we nail down the better! :)
 
  -Matej
 
  Matej Knopp wrote:
  Hi,
 
  It indeed is problem with modal window. Or, better said, with
  AjaxRequestTarget. I've tried to put date picker to modal window, and it
  didn't work. The reason is that component is not attached when rendering
  it's header contribution from AjaxRequestTarget. I've tried to refactor
  AjaxRequestTarget a bit to call responseComponent first, and that way it
  worked (of course the problem with date picker having lower z order than
  modal window is still there).
 
  Anyway, to fix this, we have to refactor AjaxRequestTarget to render
  component prior rendering the header contribution (although in response
  these should be reversed, e.g. header contribution before component
  body). And the header contribution should be rendered between
  page.startComponentRender(component) and
  page.endComponentRender(component);
 
  -Matej
 
  samyem wrote:
  Well it might actually be just a problem with this component. In my
  case, all
  I have is a date picker in a modal window which is shown as a result of
  clicking on a link. This produced the shown error and the modal window
  fail
  to display. I am sure you can replicate this condition with the current
  SVN
  source with this much info.
 
  - Samyem
 
 
  Matej Knopp wrote:
  I don'y really understand why. I was able to reproduce the problem with
  the files attached to bug report. And after I fixed the debug console,
  the problems were no longer there (though there was other problem -
  component not rendered except - for which it is necessary to disable
  component render check, at least for now).
 
  Are you sure you have cleared the browser cache?
 
  So far I had no problems with ajax header contribution apart from this
  one. But that doesn't mean there are none. Can you please provide a
  testcase/quick start for the problems you are encountering now?
 
  Thanks,
  -Matej
 
  samyem wrote:
  The header contribution logic seems to be still flawed. The javascript
  references were not added to the HTML's HEAD at all when the component
  is
  added by ajax. I guess this is a larger problem than the date picker.
  The
  same problem would occur everytime the javascript/stylesheet are added
  dynamically.
 
 
  Matej Knopp wrote:
  Well, I was working on it. But only to the degree that I disabled the
  disabling of check during ajax request, because it was no longer
  necessary.
 
  Unfortunately head contribution is something else, I'm not sure how
  to
  do it the best way, again, it's not my domain. I think that I've
  posted
  mail about it to the list, I'm not sure what the outcome was.
 
  -Matej
 
  Igor Vaynberg wrote:
  i thought you _were_ working on the component use check and ajax
  target
  stuff?
 
  -Igor
 
 
  On 9/22/06, *Matej Knopp*  [EMAIL PROTECTED] mailto:[EMAIL 
  PROTECTED]
  wrote:
 
  I don't think so. I was working on header contribution and
  problem
  with
  debug console calling document.write() (thus removing all head
  elements
  from DOM).
 
  This is something completely different, it's related to the
  component
  rendered check. That's not my domain. I believe the problem are
  components in wicket:head section of DataPicker.
 
  Anyway, what can temporary help is to disable component render
  check
  in
  appication settings. Juergen?
 
  -Matej
 
  Igor Vaynberg wrote:
matej was working to fix this, i thought he did matej?
   
-Igor
   
   
On 9/21/06, *samyem* [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]  wrote:
   
   
I took the latest SVN code today and suddenly, I am
  getting
  the
following
error everytime there is an ajax refresh on panels with
  date
  pickers:
   
2006-09-21 14:16:07,728

Re: [Wicket-user] ajax refresh on date picker

2006-09-25 Thread Martijn Dashorst

ah... so a solution would be to have the datepicker insert its panel
inside the containing div, and adjust its z-index accordingly. Not
sure if that is simple or not though.

Martijn

On 9/25/06, Matej Knopp [EMAIL PROTECTED] wrote:
 Problem is the z-index of the datepicker div. The div is shown only when
 you click on the calendar icon. At that time there is no way for us to
 set the z-index of the datepicker. When showing modal dialog the
 datepicker div is probably not even in the DOM tree.

 -Matej

 Martijn Dashorst wrote:
  Just thinking out loud:
 
  the modal window knows its z-index. can't we put an extra div (or
  span) inside that elevates all components inside to have
  newModalWindow.z-index + 1?
 
  As the modal window is displayed we use javascript. It wouldn't be
  hard I suspect to change the z-index of the inner span?
 
  Martijn
 
  On 9/24/06, samyem [EMAIL PROTECTED] wrote:
  Thanks. I've fixed the z-index problem in my app by manually resetting the
  z-index in my HTML, thus overriding the default values set by the
  components. So hopefully now everything will run smoothly.
 
  Thanks for the fix again,
  Samyem
 
 
  Matej Knopp wrote:
  The fix is in svn. (both 1.x and 2.0)
  DatePicker in modal window panel now works, although the issue with
  z-index still remains. As a side effect this also fixes the component
  use check for components that render into head, so calling
  getDebugSettings().setComponentUseCheck(false) in application#init is no
  longer necessary.
 
  I'd appreciate if everyone who has issues with header contribution test
  it with current svn. The more bugs we nail down the better! :)
 
  -Matej
 
  Matej Knopp wrote:
  Hi,
 
  It indeed is problem with modal window. Or, better said, with
  AjaxRequestTarget. I've tried to put date picker to modal window, and it
  didn't work. The reason is that component is not attached when rendering
  it's header contribution from AjaxRequestTarget. I've tried to refactor
  AjaxRequestTarget a bit to call responseComponent first, and that way it
  worked (of course the problem with date picker having lower z order than
  modal window is still there).
 
  Anyway, to fix this, we have to refactor AjaxRequestTarget to render
  component prior rendering the header contribution (although in response
  these should be reversed, e.g. header contribution before component
  body). And the header contribution should be rendered between
  page.startComponentRender(component) and
  page.endComponentRender(component);
 
  -Matej
 
  samyem wrote:
  Well it might actually be just a problem with this component. In my
  case, all
  I have is a date picker in a modal window which is shown as a result of
  clicking on a link. This produced the shown error and the modal window
  fail
  to display. I am sure you can replicate this condition with the current
  SVN
  source with this much info.
 
  - Samyem
 
 
  Matej Knopp wrote:
  I don'y really understand why. I was able to reproduce the problem with
  the files attached to bug report. And after I fixed the debug console,
  the problems were no longer there (though there was other problem -
  component not rendered except - for which it is necessary to disable
  component render check, at least for now).
 
  Are you sure you have cleared the browser cache?
 
  So far I had no problems with ajax header contribution apart from this
  one. But that doesn't mean there are none. Can you please provide a
  testcase/quick start for the problems you are encountering now?
 
  Thanks,
  -Matej
 
  samyem wrote:
  The header contribution logic seems to be still flawed. The javascript
  references were not added to the HTML's HEAD at all when the component
  is
  added by ajax. I guess this is a larger problem than the date picker.
  The
  same problem would occur everytime the javascript/stylesheet are added
  dynamically.
 
 
  Matej Knopp wrote:
  Well, I was working on it. But only to the degree that I disabled the
  disabling of check during ajax request, because it was no longer
  necessary.
 
  Unfortunately head contribution is something else, I'm not sure how
  to
  do it the best way, again, it's not my domain. I think that I've
  posted
  mail about it to the list, I'm not sure what the outcome was.
 
  -Matej
 
  Igor Vaynberg wrote:
  i thought you _were_ working on the component use check and ajax
  target
  stuff?
 
  -Igor
 
 
  On 9/22/06, *Matej Knopp*  [EMAIL PROTECTED] mailto:[EMAIL 
  PROTECTED]
  wrote:
 
  I don't think so. I was working on header contribution and
  problem
  with
  debug console calling document.write() (thus removing all head
  elements
  from DOM).
 
  This is something completely different, it's related to the
  component
  rendered check. That's not my domain. I believe the problem are
  components in wicket:head section of DataPicker.
 
  Anyway, what can temporary help is to disable component render
  check
  in
  appication

Re: [Wicket-user] ajax refresh on date picker

Problem is the z-index of the datepicker div. The div is shown only when 
you click on the calendar icon. At that time there is no way for us to 
set the z-index of the datepicker. When showing modal dialog the 
datepicker div is probably not even in the DOM tree.

-Matej

Martijn Dashorst wrote:
 Just thinking out loud:
 
 the modal window knows its z-index. can't we put an extra div (or
 span) inside that elevates all components inside to have
 newModalWindow.z-index + 1?
 
 As the modal window is displayed we use javascript. It wouldn't be
 hard I suspect to change the z-index of the inner span?
 
 Martijn
 
 On 9/24/06, samyem [EMAIL PROTECTED] wrote:
 Thanks. I've fixed the z-index problem in my app by manually resetting the
 z-index in my HTML, thus overriding the default values set by the
 components. So hopefully now everything will run smoothly.

 Thanks for the fix again,
 Samyem


 Matej Knopp wrote:
 The fix is in svn. (both 1.x and 2.0)
 DatePicker in modal window panel now works, although the issue with
 z-index still remains. As a side effect this also fixes the component
 use check for components that render into head, so calling
 getDebugSettings().setComponentUseCheck(false) in application#init is no
 longer necessary.

 I'd appreciate if everyone who has issues with header contribution test
 it with current svn. The more bugs we nail down the better! :)

 -Matej

 Matej Knopp wrote:
 Hi,

 It indeed is problem with modal window. Or, better said, with
 AjaxRequestTarget. I've tried to put date picker to modal window, and it
 didn't work. The reason is that component is not attached when rendering
 it's header contribution from AjaxRequestTarget. I've tried to refactor
 AjaxRequestTarget a bit to call responseComponent first, and that way it
 worked (of course the problem with date picker having lower z order than
 modal window is still there).

 Anyway, to fix this, we have to refactor AjaxRequestTarget to render
 component prior rendering the header contribution (although in response
 these should be reversed, e.g. header contribution before component
 body). And the header contribution should be rendered between
 page.startComponentRender(component) and
 page.endComponentRender(component);

 -Matej

 samyem wrote:
 Well it might actually be just a problem with this component. In my
 case, all
 I have is a date picker in a modal window which is shown as a result of
 clicking on a link. This produced the shown error and the modal window
 fail
 to display. I am sure you can replicate this condition with the current
 SVN
 source with this much info.

 - Samyem


 Matej Knopp wrote:
 I don'y really understand why. I was able to reproduce the problem with
 the files attached to bug report. And after I fixed the debug console,
 the problems were no longer there (though there was other problem -
 component not rendered except - for which it is necessary to disable
 component render check, at least for now).

 Are you sure you have cleared the browser cache?

 So far I had no problems with ajax header contribution apart from this
 one. But that doesn't mean there are none. Can you please provide a
 testcase/quick start for the problems you are encountering now?

 Thanks,
 -Matej

 samyem wrote:
 The header contribution logic seems to be still flawed. The javascript
 references were not added to the HTML's HEAD at all when the component
 is
 added by ajax. I guess this is a larger problem than the date picker.
 The
 same problem would occur everytime the javascript/stylesheet are added
 dynamically.


 Matej Knopp wrote:
 Well, I was working on it. But only to the degree that I disabled the
 disabling of check during ajax request, because it was no longer
 necessary.

 Unfortunately head contribution is something else, I'm not sure how
 to
 do it the best way, again, it's not my domain. I think that I've
 posted
 mail about it to the list, I'm not sure what the outcome was.

 -Matej

 Igor Vaynberg wrote:
 i thought you _were_ working on the component use check and ajax
 target
 stuff?

 -Igor


 On 9/22/06, *Matej Knopp*  [EMAIL PROTECTED] mailto:[EMAIL 
 PROTECTED]
 wrote:

 I don't think so. I was working on header contribution and
 problem
 with
 debug console calling document.write() (thus removing all head
 elements
 from DOM).

 This is something completely different, it's related to the
 component
 rendered check. That's not my domain. I believe the problem are
 components in wicket:head section of DataPicker.

 Anyway, what can temporary help is to disable component render
 check
 in
 appication settings. Juergen?

 -Matej

 Igor Vaynberg wrote:
   matej was working to fix this, i thought he did matej?
  
   -Igor
  
  
   On 9/21/06, *samyem* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]  wrote:
  
  
   I took the latest SVN code today and suddenly,

Re: [Wicket-user] ajax refresh on date picker

2006-09-25 Thread Pierre-Yves Saumont

I tried to build the last version from trunk, but it fails the tests (32 
failures) most failures report inversion of two html attributes, for 
exemple:

=== wicket.markup.MarkupInheritanceExtension_11 ===
3c3
 link wicket:id=css src=myStyle.css/
---
  link src=myStyle.css wicket:id=css/

Checkout reported version # 7486.

Pierre-Yves

Matej Knopp a écrit :
 I've tested your quick start example with current svn and I worked as it 
 should. Tested with FF1.5, IE6 and opera 9.
 
 Can you please test your project with current svn, if the problem persists?
 
 -Matej
 
 
 Pierre-Yves Saumont wrote:
 And in some conditions (see my other post with a quickstart example), 
 the setup script is not even executed !!

 Pierre-Yves

 samyem a écrit :
 The header contribution logic seems to be still flawed. The javascript
 references were not added to the HTML's HEAD at all when the 
 component is
 added by ajax. I guess this is a larger problem than the date picker. 
 The
 same problem would occur everytime the javascript/stylesheet are added
 dynamically.


 Matej Knopp wrote:
 Well, I was working on it. But only to the degree that I disabled 
 the disabling of check during ajax request, because it was no longer
 necessary.

 Unfortunately head contribution is something else, I'm not sure how 
 to do it the best way, again, it's not my domain. I think that I've 
 posted mail about it to the list, I'm not sure what the outcome was.

 -Matej

 Igor Vaynberg wrote:
 i thought you _were_ working on the component use check and ajax 
 target stuff?

 -Igor


 On 9/22/06, *Matej Knopp*  [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
 wrote:

 I don't think so. I was working on header contribution and problem
 with
 debug console calling document.write() (thus removing all head
 elements
 from DOM).

 This is something completely different, it's related to the 
 component
 rendered check. That's not my domain. I believe the problem are
 components in wicket:head section of DataPicker.

 Anyway, what can temporary help is to disable component render 
 check
 in
 appication settings. Juergen?

 -Matej

 Igor Vaynberg wrote:
   matej was working to fix this, i thought he did matej?
  
   -Igor
  
  
   On 9/21/06, *samyem* [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]  wrote:
  
  
   I took the latest SVN code today and suddenly, I am getting
 the
   following
   error everytime there is an ajax refresh on panels with 
 date
 pickers:
  
   2006-09-21 14:16:07,728 ERROR 
 wicket.ajax.AjaxRequestTarget -
 Error
   while
   responding to an AJAX request: 
 [EMAIL PROTECTED]
   markupIdToComponent [{pageBody_sidePanel=[MarkupContainer
 [Component
   id =
   sidePanel, page =
 com.wsi.mm.ui.directship.item.ItemDirectShipPage,
   path =
   4:pageBody:sidePanel.DirectShipSideBarPanel, isVisible = 
 true,
   isVersioned =
   false]]}], prependJavascript [[]], appendJavascript 
 [[var win;
   try {
   win = window.parent.Wicket.Window;
   } catch (ignore) {
   }
   if (typeof(win) != undefined  typeof(win.current ) !=
 undefined) {
   window.parent.setTimeout(function() {
   win.current.close();
   }, 0);
   }]]
   wicket.WicketRuntimeException: The component(s) below 
 failed
 to
   render. A
   common problem is that you have added a component in 
 code but
 forgot to
   reference it in the markup (thus the component will 
 never be
 rendered).
  
   1. [MarkupContainer [Component id = calendarMain, page =
   com.wsi.mm.ui.directship.item.ItemDirectShipPage , path =
 
 4:pageBody:sidePanel:massUpdate:massUpdateForm:releaseDate:picker:calendarMain.JavaScriptReference,
  

   isVisible = true, isVersioned = false]]
   2. [MarkupContainer [Component id = calendarSetup, page =
   com.wsi.mm.ui.directship.item.ItemDirectShipPage , path =
 
 4:pageBody:sidePanel:massUpdate:massUpdateForm:releaseDate:picker:calendarSetup.JavaScriptReference
  

 ,
   isVisible = true, isVersioned = false]]
   3. [MarkupContainer [Component id = calendarLanguage, 
 page =
   com.wsi.mm.ui.directship.item.ItemDirectShipPage, path =
  
 4:pageBody:sidePanel:massUpdate:massUpdateForm:releaseDate:picker:
 calendarLanguage.JavaScriptReference,
   isVisible = true, isVersioned = false]]
   4. [MarkupContainer [Component id = calendarStyle, page =
   com.wsi.mm.ui.directship.item.ItemDirectShipPage, path =
 
 4:pageBody:sidePanel:massUpdate:massUpdateForm:releaseDate:picker:calendarStyle.StyleSheetReference,

Re: [Wicket-user] ajax refresh on date picker

This is strange. I've tested both current 1.x and 2.0

in 1.x all tests completed with no problem for me,
in 2.0 there are 4 errors and 1 failure.

I don't know where the problem can be. Have you tried clean build?

-Matej

Pierre-Yves Saumont wrote:
 I tried to build the last version from trunk, but it fails the tests (32 
 failures) most failures report inversion of two html attributes, for 
 exemple:
 
 === wicket.markup.MarkupInheritanceExtension_11 ===
 3c3
  link wicket:id=css src=myStyle.css/
 ---
   link src=myStyle.css wicket:id=css/
 
 Checkout reported version # 7486.
 
 Pierre-Yves
 
 Matej Knopp a écrit :
 I've tested your quick start example with current svn and I worked as it 
 should. Tested with FF1.5, IE6 and opera 9.

 Can you please test your project with current svn, if the problem persists?

 -Matej


 Pierre-Yves Saumont wrote:
 And in some conditions (see my other post with a quickstart example), 
 the setup script is not even executed !!

 Pierre-Yves

 samyem a écrit :
 The header contribution logic seems to be still flawed. The javascript
 references were not added to the HTML's HEAD at all when the 
 component is
 added by ajax. I guess this is a larger problem than the date picker. 
 The
 same problem would occur everytime the javascript/stylesheet are added
 dynamically.


 Matej Knopp wrote:
 Well, I was working on it. But only to the degree that I disabled 
 the disabling of check during ajax request, because it was no longer
 necessary.

 Unfortunately head contribution is something else, I'm not sure how 
 to do it the best way, again, it's not my domain. I think that I've 
 posted mail about it to the list, I'm not sure what the outcome was.

 -Matej

 Igor Vaynberg wrote:
 i thought you _were_ working on the component use check and ajax 
 target stuff?

 -Igor


 On 9/22/06, *Matej Knopp*  [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
 wrote:

 I don't think so. I was working on header contribution and problem
 with
 debug console calling document.write() (thus removing all head
 elements
 from DOM).

 This is something completely different, it's related to the 
 component
 rendered check. That's not my domain. I believe the problem are
 components in wicket:head section of DataPicker.

 Anyway, what can temporary help is to disable component render 
 check
 in
 appication settings. Juergen?

 -Matej

 Igor Vaynberg wrote:
   matej was working to fix this, i thought he did matej?
  
   -Igor
  
  
   On 9/21/06, *samyem* [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]  wrote:
  
  
   I took the latest SVN code today and suddenly, I am getting
 the
   following
   error everytime there is an ajax refresh on panels with 
 date
 pickers:
  
   2006-09-21 14:16:07,728 ERROR 
 wicket.ajax.AjaxRequestTarget -
 Error
   while
   responding to an AJAX request: 
 [EMAIL PROTECTED]
   markupIdToComponent [{pageBody_sidePanel=[MarkupContainer
 [Component
   id =
   sidePanel, page =
 com.wsi.mm.ui.directship.item.ItemDirectShipPage,
   path =
   4:pageBody:sidePanel.DirectShipSideBarPanel, isVisible = 
 true,
   isVersioned =
   false]]}], prependJavascript [[]], appendJavascript 
 [[var win;
   try {
   win = window.parent.Wicket.Window;
   } catch (ignore) {
   }
   if (typeof(win) != undefined  typeof(win.current ) !=
 undefined) {
   window.parent.setTimeout(function() {
   win.current.close();
   }, 0);
   }]]
   wicket.WicketRuntimeException: The component(s) below 
 failed
 to
   render. A
   common problem is that you have added a component in 
 code but
 forgot to
   reference it in the markup (thus the component will 
 never be
 rendered).
  
   1. [MarkupContainer [Component id = calendarMain, page =
   com.wsi.mm.ui.directship.item.ItemDirectShipPage , path =
 
 4:pageBody:sidePanel:massUpdate:massUpdateForm:releaseDate:picker:calendarMain.JavaScriptReference,
  

   isVisible = true, isVersioned = false]]
   2. [MarkupContainer [Component id = calendarSetup, page =
   com.wsi.mm.ui.directship.item.ItemDirectShipPage , path =
 
 4:pageBody:sidePanel:massUpdate:massUpdateForm:releaseDate:picker:calendarSetup.JavaScriptReference
  

 ,
   isVisible = true, isVersioned = false]]
   3. [MarkupContainer [Component id = calendarLanguage, 
 page =
   com.wsi.mm.ui.directship.item.ItemDirectShipPage, path =
  
 4:pageBody:sidePanel:massUpdate:massUpdateForm:releaseDate:picker:
 calendarLanguage.JavaScriptReference,
   isVisible = true, isVersioned =

Re: [Wicket-user] ajax refresh on date picker

2006-09-25 Thread Pierre-Yves Saumont

Yes. I have even deleted everything and checked out a new complete fresh 
version, tried mvn clean, deleted manually the target and tried again !!

I have no problem with wicket-extensions.

Pierre-Yves

Matej Knopp a écrit :
 This is strange. I've tested both current 1.x and 2.0
 
 in 1.x all tests completed with no problem for me,
 in 2.0 there are 4 errors and 1 failure.
 
 I don't know where the problem can be. Have you tried clean build?
 
 -Matej
 
 Pierre-Yves Saumont wrote:
 I tried to build the last version from trunk, but it fails the tests 
 (32 failures) most failures report inversion of two html attributes, 
 for exemple:

 === wicket.markup.MarkupInheritanceExtension_11 ===
 3c3
  link wicket:id=css src=myStyle.css/
 ---
   link src=myStyle.css wicket:id=css/

 Checkout reported version # 7486.

 Pierre-Yves

 Matej Knopp a écrit :
 I've tested your quick start example with current svn and I worked as 
 it should. Tested with FF1.5, IE6 and opera 9.

 Can you please test your project with current svn, if the problem 
 persists?

 -Matej


 Pierre-Yves Saumont wrote:
 And in some conditions (see my other post with a quickstart 
 example), the setup script is not even executed !!

 Pierre-Yves

 samyem a écrit :
 The header contribution logic seems to be still flawed. The javascript
 references were not added to the HTML's HEAD at all when the 
 component is
 added by ajax. I guess this is a larger problem than the date 
 picker. The
 same problem would occur everytime the javascript/stylesheet are added
 dynamically.


 Matej Knopp wrote:
 Well, I was working on it. But only to the degree that I disabled 
 the disabling of check during ajax request, because it was no longer
 necessary.

 Unfortunately head contribution is something else, I'm not sure 
 how to do it the best way, again, it's not my domain. I think that 
 I've posted mail about it to the list, I'm not sure what the 
 outcome was.

 -Matej

 Igor Vaynberg wrote:
 i thought you _were_ working on the component use check and ajax 
 target stuff?

 -Igor


 On 9/22/06, *Matej Knopp*  [EMAIL PROTECTED] mailto:[EMAIL 
 PROTECTED]
 wrote:

 I don't think so. I was working on header contribution and 
 problem
 with
 debug console calling document.write() (thus removing all head
 elements
 from DOM).

 This is something completely different, it's related to the 
 component
 rendered check. That's not my domain. I believe the problem are
 components in wicket:head section of DataPicker.

 Anyway, what can temporary help is to disable component 
 render check
 in
 appication settings. Juergen?

 -Matej

 Igor Vaynberg wrote:
   matej was working to fix this, i thought he did matej?
  
   -Igor
  
  
   On 9/21/06, *samyem* [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]  wrote:
  
  
   I took the latest SVN code today and suddenly, I am 
 getting
 the
   following
   error everytime there is an ajax refresh on panels 
 with date
 pickers:
  
   2006-09-21 14:16:07,728 ERROR 
 wicket.ajax.AjaxRequestTarget -
 Error
   while
   responding to an AJAX request: 
 [EMAIL PROTECTED]
   markupIdToComponent [{pageBody_sidePanel=[MarkupContainer
 [Component
   id =
   sidePanel, page =
 com.wsi.mm.ui.directship.item.ItemDirectShipPage,
   path =
   4:pageBody:sidePanel.DirectShipSideBarPanel, isVisible 
 = true,
   isVersioned =
   false]]}], prependJavascript [[]], appendJavascript 
 [[var win;
   try {
   win = window.parent.Wicket.Window;
   } catch (ignore) {
   }
   if (typeof(win) != undefined  typeof(win.current ) !=
 undefined) {
   window.parent.setTimeout(function() {
   win.current.close();
   }, 0);
   }]]
   wicket.WicketRuntimeException: The component(s) below 
 failed
 to
   render. A
   common problem is that you have added a component in 
 code but
 forgot to
   reference it in the markup (thus the component will 
 never be
 rendered).
  
   1. [MarkupContainer [Component id = calendarMain, page =
   com.wsi.mm.ui.directship.item.ItemDirectShipPage , path =
 
 4:pageBody:sidePanel:massUpdate:massUpdateForm:releaseDate:picker:calendarMain.JavaScriptReference,
  

   isVisible = true, isVersioned = false]]
   2. [MarkupContainer [Component id = calendarSetup, page =
   com.wsi.mm.ui.directship.item.ItemDirectShipPage , path =
 
 4:pageBody:sidePanel:massUpdate:massUpdateForm:releaseDate:picker:calendarSetup.JavaScriptReference
  

 ,
   isVisible = true, isVersioned = false]]
   3. [MarkupContainer [Component id = calendarLanguage, 
 page

Re: [Wicket-user] ajax refresh on date picker


I updated wicket and wicket-extension and now my modal window is not even
showing and the date picker does not show up in non modal window pages as
well. I can only see the error through the ajax debugger as:

...
NFO: Response parsed. Now invoking steps...
INFO:
INFO: Initiating Ajax GET request on /mm/calendar.js
INFO: Invoking pre-call handler(s)...
ERROR: Received Ajax response with code: 404
INFO: Invoking post-call handler(s)...
INFO: Invoking failure handler(s)...
...

After this, further clicks gives this error:

INFO: Chanel busy - postponing...

On non-modal pages, I get things like:

Error: Calendar is not defined
Source File: http://localhost:8081/mm/app?wicket:interface=:13::
Line: 214

And even my auto-complete text box is broken now with the latest code. I get
things like:

Error: Wicket.Ajax has no properties
Source File: http://localhost:8081/mm/javascript/wicket-autocomplete.js
Line: 7

And the auto-complete fails to work. Nontheless, other ajax behaviour like
ajax links and so forth are still working. When I revert the wicket library
to the release version, it does not break like this. Before this fix, the
only thing not working was the date picker not working on ajax refresh.
Looks like the fix actually broke far more things than fixing the original
problem. If you cannot identify the problem, I could prepare a quickstart to
demonstrate these issues.

- Samyem


Matej Knopp wrote:
 
 The fix is in svn. (both 1.x and 2.0)
 DatePicker in modal window panel now works, although the issue with 
 z-index still remains. As a side effect this also fixes the component 
 use check for components that render into head, so calling 
 getDebugSettings().setComponentUseCheck(false) in application#init is no 
 longer necessary.
 
 I'd appreciate if everyone who has issues with header contribution test 
 it with current svn. The more bugs we nail down the better! :)
 
 -Matej
 
 Matej Knopp wrote:
 Hi,
 
 It indeed is problem with modal window. Or, better said, with 
 AjaxRequestTarget. I've tried to put date picker to modal window, and it 
 didn't work. The reason is that component is not attached when rendering 
 it's header contribution from AjaxRequestTarget. I've tried to refactor 
 AjaxRequestTarget a bit to call responseComponent first, and that way it 
 worked (of course the problem with date picker having lower z order than 
 modal window is still there).
 
 Anyway, to fix this, we have to refactor AjaxRequestTarget to render 
 component prior rendering the header contribution (although in response 
 these should be reversed, e.g. header contribution before component 
 body). And the header contribution should be rendered between
 page.startComponentRender(component) and 
 page.endComponentRender(component);
 
 -Matej
 
 samyem wrote:
 Well it might actually be just a problem with this component. In my
 case, all
 I have is a date picker in a modal window which is shown as a result of
 clicking on a link. This produced the shown error and the modal window
 fail
 to display. I am sure you can replicate this condition with the current
 SVN
 source with this much info.

 - Samyem


 Matej Knopp wrote:
 I don'y really understand why. I was able to reproduce the problem with 
 the files attached to bug report. And after I fixed the debug console, 
 the problems were no longer there (though there was other problem - 
 component not rendered except - for which it is necessary to disable 
 component render check, at least for now).

 Are you sure you have cleared the browser cache?

 So far I had no problems with ajax header contribution apart from this 
 one. But that doesn't mean there are none. Can you please provide a 
 testcase/quick start for the problems you are encountering now?

 Thanks,
 -Matej

 samyem wrote:
 The header contribution logic seems to be still flawed. The javascript
 references were not added to the HTML's HEAD at all when the component
 is
 added by ajax. I guess this is a larger problem than the date picker.
 The
 same problem would occur everytime the javascript/stylesheet are added
 dynamically.


 Matej Knopp wrote:
 Well, I was working on it. But only to the degree that I disabled the 
 disabling of check during ajax request, because it was no longer
 necessary.

 Unfortunately head contribution is something else, I'm not sure how
 to 
 do it the best way, again, it's not my domain. I think that I've
 posted 
 mail about it to the list, I'm not sure what the outcome was.

 -Matej

 Igor Vaynberg wrote:
 i thought you _were_ working on the component use check and ajax
 target 
 stuff?

 -Igor


 On 9/22/06, *Matej Knopp*  [EMAIL PROTECTED] mailto:[EMAIL 
 PROTECTED]
 wrote:

 I don't think so. I was working on header contribution and
 problem
 with
 debug console calling document.write() (thus removing all head
 elements
 from DOM).

 This is something completely different, it's related to the
 component
 rendered check. That's not my domain. I

Re: [Wicket-user] ajax refresh on date picker


Just to add emphasis, here the problem is that wicket made a request for the
resource at /mm/calendar.js, which is not a valid path. It should have been
/mm/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js

- Samyem


samyem wrote:
 
 I updated wicket and wicket-extension and now my modal window is not even
 showing and the date picker does not show up in non modal window pages as
 well. I can only see the error through the ajax debugger as:
 
 ...
 NFO: Response parsed. Now invoking steps...
 INFO:
 INFO: Initiating Ajax GET request on /mm/calendar.js
 INFO: Invoking pre-call handler(s)...
 ERROR: Received Ajax response with code: 404
 INFO: Invoking post-call handler(s)...
 INFO: Invoking failure handler(s)...
 ...
 
 After this, further clicks gives this error:
 
 INFO: Chanel busy - postponing...
 
 On non-modal pages, I get things like:
 
 Error: Calendar is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:13::
 Line: 214
 
 And even my auto-complete text box is broken now with the latest code. I
 get things like:
 
 Error: Wicket.Ajax has no properties
 Source File: http://localhost:8081/mm/javascript/wicket-autocomplete.js
 Line: 7
 
 And the auto-complete fails to work. Nontheless, other ajax behaviour like
 ajax links and so forth are still working. When I revert the wicket
 library to the release version, it does not break like this. Before this
 fix, the only thing not working was the date picker not working on ajax
 refresh. Looks like the fix actually broke far more things than fixing the
 original problem. If you cannot identify the problem, I could prepare a
 quickstart to demonstrate these issues.
 
 - Samyem
 
 
 Matej Knopp wrote:
 
 The fix is in svn. (both 1.x and 2.0)
 DatePicker in modal window panel now works, although the issue with 
 z-index still remains. As a side effect this also fixes the component 
 use check for components that render into head, so calling 
 getDebugSettings().setComponentUseCheck(false) in application#init is no 
 longer necessary.
 
 I'd appreciate if everyone who has issues with header contribution test 
 it with current svn. The more bugs we nail down the better! :)
 
 -Matej
 
 Matej Knopp wrote:
 Hi,
 
 It indeed is problem with modal window. Or, better said, with 
 AjaxRequestTarget. I've tried to put date picker to modal window, and it 
 didn't work. The reason is that component is not attached when rendering 
 it's header contribution from AjaxRequestTarget. I've tried to refactor 
 AjaxRequestTarget a bit to call responseComponent first, and that way it 
 worked (of course the problem with date picker having lower z order than 
 modal window is still there).
 
 Anyway, to fix this, we have to refactor AjaxRequestTarget to render 
 component prior rendering the header contribution (although in response 
 these should be reversed, e.g. header contribution before component 
 body). And the header contribution should be rendered between
 page.startComponentRender(component) and 
 page.endComponentRender(component);
 
 -Matej
 
 samyem wrote:
 Well it might actually be just a problem with this component. In my
 case, all
 I have is a date picker in a modal window which is shown as a result of
 clicking on a link. This produced the shown error and the modal window
 fail
 to display. I am sure you can replicate this condition with the current
 SVN
 source with this much info.

 - Samyem


 Matej Knopp wrote:
 I don'y really understand why. I was able to reproduce the problem
 with 
 the files attached to bug report. And after I fixed the debug console, 
 the problems were no longer there (though there was other problem - 
 component not rendered except - for which it is necessary to disable 
 component render check, at least for now).

 Are you sure you have cleared the browser cache?

 So far I had no problems with ajax header contribution apart from this 
 one. But that doesn't mean there are none. Can you please provide a 
 testcase/quick start for the problems you are encountering now?

 Thanks,
 -Matej

 samyem wrote:
 The header contribution logic seems to be still flawed. The
 javascript
 references were not added to the HTML's HEAD at all when the
 component is
 added by ajax. I guess this is a larger problem than the date picker.
 The
 same problem would occur everytime the javascript/stylesheet are
 added
 dynamically.


 Matej Knopp wrote:
 Well, I was working on it. But only to the degree that I disabled
 the 
 disabling of check during ajax request, because it was no longer
 necessary.

 Unfortunately head contribution is something else, I'm not sure how
 to 
 do it the best way, again, it's not my domain. I think that I've
 posted 
 mail about it to the list, I'm not sure what the outcome was.

 -Matej

 Igor Vaynberg wrote:
 i thought you _were_ working on the component use check and ajax
 target 
 stuff?

 -Igor


 On 9/22/06, *Matej Knopp*  [EMAIL PROTECTED] mailto:[EMAIL 
 PROTECTED]

Re: [Wicket-user] ajax refresh on date picker


I am also getting this new error after the update:

Error: wicketAjaxGet is not defined
Source File: http://localhost:8081/mm/app?wicket:interface=:11:1:
Line: 1



samyem wrote:
 
 I updated wicket and wicket-extension and now my modal window is not even
 showing and the date picker does not show up in non modal window pages as
 well. I can only see the error through the ajax debugger as:
 
 ...
 NFO: Response parsed. Now invoking steps...
 INFO:
 INFO: Initiating Ajax GET request on /mm/calendar.js
 INFO: Invoking pre-call handler(s)...
 ERROR: Received Ajax response with code: 404
 INFO: Invoking post-call handler(s)...
 INFO: Invoking failure handler(s)...
 ...
 
 After this, further clicks gives this error:
 
 INFO: Chanel busy - postponing...
 
 On non-modal pages, I get things like:
 
 Error: Calendar is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:13::
 Line: 214
 
 And even my auto-complete text box is broken now with the latest code. I
 get things like:
 
 Error: Wicket.Ajax has no properties
 Source File: http://localhost:8081/mm/javascript/wicket-autocomplete.js
 Line: 7
 
 And the auto-complete fails to work. Nontheless, other ajax behaviour like
 ajax links and so forth are still working. When I revert the wicket
 library to the release version, it does not break like this. Before this
 fix, the only thing not working was the date picker not working on ajax
 refresh. Looks like the fix actually broke far more things than fixing the
 original problem. If you cannot identify the problem, I could prepare a
 quickstart to demonstrate these issues.
 
 - Samyem
 
 
 Matej Knopp wrote:
 
 The fix is in svn. (both 1.x and 2.0)
 DatePicker in modal window panel now works, although the issue with 
 z-index still remains. As a side effect this also fixes the component 
 use check for components that render into head, so calling 
 getDebugSettings().setComponentUseCheck(false) in application#init is no 
 longer necessary.
 
 I'd appreciate if everyone who has issues with header contribution test 
 it with current svn. The more bugs we nail down the better! :)
 
 -Matej
 
 Matej Knopp wrote:
 Hi,
 
 It indeed is problem with modal window. Or, better said, with 
 AjaxRequestTarget. I've tried to put date picker to modal window, and it 
 didn't work. The reason is that component is not attached when rendering 
 it's header contribution from AjaxRequestTarget. I've tried to refactor 
 AjaxRequestTarget a bit to call responseComponent first, and that way it 
 worked (of course the problem with date picker having lower z order than 
 modal window is still there).
 
 Anyway, to fix this, we have to refactor AjaxRequestTarget to render 
 component prior rendering the header contribution (although in response 
 these should be reversed, e.g. header contribution before component 
 body). And the header contribution should be rendered between
 page.startComponentRender(component) and 
 page.endComponentRender(component);
 
 -Matej
 
 samyem wrote:
 Well it might actually be just a problem with this component. In my
 case, all
 I have is a date picker in a modal window which is shown as a result of
 clicking on a link. This produced the shown error and the modal window
 fail
 to display. I am sure you can replicate this condition with the current
 SVN
 source with this much info.

 - Samyem


 Matej Knopp wrote:
 I don'y really understand why. I was able to reproduce the problem
 with 
 the files attached to bug report. And after I fixed the debug console, 
 the problems were no longer there (though there was other problem - 
 component not rendered except - for which it is necessary to disable 
 component render check, at least for now).

 Are you sure you have cleared the browser cache?

 So far I had no problems with ajax header contribution apart from this 
 one. But that doesn't mean there are none. Can you please provide a 
 testcase/quick start for the problems you are encountering now?

 Thanks,
 -Matej

 samyem wrote:
 The header contribution logic seems to be still flawed. The
 javascript
 references were not added to the HTML's HEAD at all when the
 component is
 added by ajax. I guess this is a larger problem than the date picker.
 The
 same problem would occur everytime the javascript/stylesheet are
 added
 dynamically.


 Matej Knopp wrote:
 Well, I was working on it. But only to the degree that I disabled
 the 
 disabling of check during ajax request, because it was no longer
 necessary.

 Unfortunately head contribution is something else, I'm not sure how
 to 
 do it the best way, again, it's not my domain. I think that I've
 posted 
 mail about it to the list, I'm not sure what the outcome was.

 -Matej

 Igor Vaynberg wrote:
 i thought you _were_ working on the component use check and ajax
 target 
 stuff?

 -Igor


 On 9/22/06, *Matej Knopp*  [EMAIL PROTECTED] mailto:[EMAIL 
 PROTECTED]
 wrote:

 I don't think so. I was working on header contribution and
 problem

Re: [Wicket-user] ajax refresh on date picker


Upon further investigations, what is clear is that when the page first loads,
it loads up all the java scripts in the header. When I do a page refresh by
pressing F5, the ensuing page does not render the javascript references at
all. Looks like there is some logic which prevents javascripts from
rendering after the initial page display. Here is what I am seeing in my
HEAD tag :

Initial page load:

?
head
meta http-equiv=Content-Type content=text/html;
charset=ISO-8859-1title?/title
script type=text/javascript
src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js/script
script type=text/javascript
id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/
wicketAjaxDebugEnable=true;
/*--]]*//script

script type=text/javascript
src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js/script
script type=text/javascript
src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js/script
script type=text/javascript
src=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js/script
link rel=stylesheet type=text/css
href=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css
link rel=stylesheet type=text/css
href=/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css
script type=text/javascript!--/*--![CDATA[/*!--*/
if (window.name=='') {
window.location=/mm/app?wicket:bookmarkablePage=wicket-0:com.wsi.mm.ui.media.MediaPage;
}
/*--]]*//script
/head

Subsequent refreshes:

head
meta http-equiv=Content-Type content=text/html;
charset=ISO-8859-1title?/title

script type=text/javascript!--/*--![CDATA[/*!--*/
if (window.name=='') {
window.location=/mm/app?wicket:bookmarkablePage=wicket-1:com.wsi.mm.ui.media.MediaPage;
}
/*--]]*//script
/head

Now I think we should be able to pinpoint the problem at the moment.




samyem wrote:
 
 I am also getting this new error after the update:
 
 Error: wicketAjaxGet is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:11:1:
 Line: 1
 
 
 
 samyem wrote:
 
 I updated wicket and wicket-extension and now my modal window is not even
 showing and the date picker does not show up in non modal window pages as
 well. I can only see the error through the ajax debugger as:
 
 ...
 NFO: Response parsed. Now invoking steps...
 INFO:
 INFO: Initiating Ajax GET request on /mm/calendar.js
 INFO: Invoking pre-call handler(s)...
 ERROR: Received Ajax response with code: 404
 INFO: Invoking post-call handler(s)...
 INFO: Invoking failure handler(s)...
 ...
 
 After this, further clicks gives this error:
 
 INFO: Chanel busy - postponing...
 
 On non-modal pages, I get things like:
 
 Error: Calendar is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:13::
 Line: 214
 
 And even my auto-complete text box is broken now with the latest code. I
 get things like:
 
 Error: Wicket.Ajax has no properties
 Source File: http://localhost:8081/mm/javascript/wicket-autocomplete.js
 Line: 7
 
 And the auto-complete fails to work. Nontheless, other ajax behaviour
 like ajax links and so forth are still working. When I revert the wicket
 library to the release version, it does not break like this. Before this
 fix, the only thing not working was the date picker not working on ajax
 refresh. Looks like the fix actually broke far more things than fixing
 the original problem. If you cannot identify the problem, I could prepare
 a quickstart to demonstrate these issues.
 
 - Samyem
 
 
 Matej Knopp wrote:
 
 The fix is in svn. (both 1.x and 2.0)
 DatePicker in modal window panel now works, although the issue with 
 z-index still remains. As a side effect this also fixes the component 
 use check for components that render into head, so calling 
 getDebugSettings().setComponentUseCheck(false) in application#init is no 
 longer necessary.
 
 I'd appreciate if everyone who has issues with header contribution test 
 it with current svn. The more bugs we nail down the better! :)
 
 -Matej
 
 Matej Knopp wrote:
 Hi,
 
 It indeed is problem with modal window. Or, better said, with 
 AjaxRequestTarget. I've tried to put date picker to modal window, and
 it 
 didn't work. The reason is that component is not attached when
 rendering 
 it's header contribution from AjaxRequestTarget. I've tried to refactor 
 AjaxRequestTarget a bit to call responseComponent first, and that way
 it 
 worked (of course the problem with date picker having lower z order
 than 
 modal window is still there).
 
 Anyway, to fix this, we have to refactor AjaxRequestTarget to render 
 component prior rendering the header contribution (although in response 
 these should be reversed, e.g. header contribution before component 
 body). And the header contribution should be rendered between
 page.startComponentRender(component) and 
 page.endComponentRender(component);
 
 -Matej
 
 samyem wrote:
 Well it might actually be just a problem

Re: [Wicket-user] ajax refresh on date picker

No matter what I do I just can't reproduce this. Can you please double 
check that you're using branch wicket-1.x or trunk, and a clean build?

If the problem persists, can you please either check if it happens with 
wicket-examples too or try to isolate the problem and provide a 
quickstart example? I'll be more than happy to look at it.

Thanks,

-Matej

samyem wrote:
 Upon further investigations, what is clear is that when the page first loads,
 it loads up all the java scripts in the header. When I do a page refresh by
 pressing F5, the ensuing page does not render the javascript references at
 all. Looks like there is some logic which prevents javascripts from
 rendering after the initial page display. Here is what I am seeing in my
 HEAD tag :
 
 Initial page load:
 
 ?
 head
   meta http-equiv=Content-Type content=text/html;
 charset=ISO-8859-1title?/title
 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js/script
 script type=text/javascript
 id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/
 wicketAjaxDebugEnable=true;
 /*--]]*//script
 
 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js/script
 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js/script
 script type=text/javascript
 src=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js/script
 link rel=stylesheet type=text/css
 href=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css
 link rel=stylesheet type=text/css
 href=/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css
 script type=text/javascript!--/*--![CDATA[/*!--*/
 if (window.name=='') {
 window.location=/mm/app?wicket:bookmarkablePage=wicket-0:com.wsi.mm.ui.media.MediaPage;
 }
 /*--]]*//script
 /head
 
 Subsequent refreshes:
 
 head
   meta http-equiv=Content-Type content=text/html;
 charset=ISO-8859-1title?/title
   
 script type=text/javascript!--/*--![CDATA[/*!--*/
 if (window.name=='') {
 window.location=/mm/app?wicket:bookmarkablePage=wicket-1:com.wsi.mm.ui.media.MediaPage;
 }
 /*--]]*//script
 /head
 
 Now I think we should be able to pinpoint the problem at the moment.
 
 
 
 
 samyem wrote:
 I am also getting this new error after the update:

 Error: wicketAjaxGet is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:11:1:
 Line: 1



 samyem wrote:
 I updated wicket and wicket-extension and now my modal window is not even
 showing and the date picker does not show up in non modal window pages as
 well. I can only see the error through the ajax debugger as:

 ...
 NFO: Response parsed. Now invoking steps...
 INFO:
 INFO: Initiating Ajax GET request on /mm/calendar.js
 INFO: Invoking pre-call handler(s)...
 ERROR: Received Ajax response with code: 404
 INFO: Invoking post-call handler(s)...
 INFO: Invoking failure handler(s)...
 ...

 After this, further clicks gives this error:

 INFO: Chanel busy - postponing...

 On non-modal pages, I get things like:

 Error: Calendar is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:13::
 Line: 214

 And even my auto-complete text box is broken now with the latest code. I
 get things like:

 Error: Wicket.Ajax has no properties
 Source File: http://localhost:8081/mm/javascript/wicket-autocomplete.js
 Line: 7

 And the auto-complete fails to work. Nontheless, other ajax behaviour
 like ajax links and so forth are still working. When I revert the wicket
 library to the release version, it does not break like this. Before this
 fix, the only thing not working was the date picker not working on ajax
 refresh. Looks like the fix actually broke far more things than fixing
 the original problem. If you cannot identify the problem, I could prepare
 a quickstart to demonstrate these issues.

 - Samyem


 Matej Knopp wrote:
 The fix is in svn. (both 1.x and 2.0)
 DatePicker in modal window panel now works, although the issue with 
 z-index still remains. As a side effect this also fixes the component 
 use check for components that render into head, so calling 
 getDebugSettings().setComponentUseCheck(false) in application#init is no 
 longer necessary.

 I'd appreciate if everyone who has issues with header contribution test 
 it with current svn. The more bugs we nail down the better! :)

 -Matej

 Matej Knopp wrote:
 Hi,

 It indeed is problem with modal window. Or, better said, with 
 AjaxRequestTarget. I've tried to put date picker to modal window, and
 it 
 didn't work. The reason is that component is not attached when
 rendering 
 it's header contribution from AjaxRequestTarget. I've tried to refactor 
 AjaxRequestTarget a bit to call responseComponent first, and that way
 it 
 worked (of course the problem with date picker having lower z order
 than 
 modal window is still there).

 Anyway, to fix this, we have to

Re: [Wicket-user] ajax refresh on date picker

No Idea. Which version are you using?
Anyway, there is a maven parameter that allows you to build a release 
without running unit test (look at older posts, it's certainly mentioned 
somewhere).

-Matej

Pierre-Yves Saumont wrote:
 Yes. I have even deleted everything and checked out a new complete fresh 
 version, tried mvn clean, deleted manually the target and tried again !!
 
 I have no problem with wicket-extensions.
 
 Pierre-Yves
 
 Matej Knopp a écrit :
 This is strange. I've tested both current 1.x and 2.0

 in 1.x all tests completed with no problem for me,
 in 2.0 there are 4 errors and 1 failure.

 I don't know where the problem can be. Have you tried clean build?

 -Matej

 Pierre-Yves Saumont wrote:
 I tried to build the last version from trunk, but it fails the tests 
 (32 failures) most failures report inversion of two html attributes, 
 for exemple:

 === wicket.markup.MarkupInheritanceExtension_11 ===
 3c3
  link wicket:id=css src=myStyle.css/
 ---
   link src=myStyle.css wicket:id=css/

 Checkout reported version # 7486.

 Pierre-Yves

 Matej Knopp a écrit :
 I've tested your quick start example with current svn and I worked as 
 it should. Tested with FF1.5, IE6 and opera 9.

 Can you please test your project with current svn, if the problem 
 persists?

 -Matej


 Pierre-Yves Saumont wrote:
 And in some conditions (see my other post with a quickstart 
 example), the setup script is not even executed !!

 Pierre-Yves

 samyem a écrit :
 The header contribution logic seems to be still flawed. The javascript
 references were not added to the HTML's HEAD at all when the 
 component is
 added by ajax. I guess this is a larger problem than the date 
 picker. The
 same problem would occur everytime the javascript/stylesheet are added
 dynamically.


 Matej Knopp wrote:
 Well, I was working on it. But only to the degree that I disabled 
 the disabling of check during ajax request, because it was no longer
 necessary.

 Unfortunately head contribution is something else, I'm not sure 
 how to do it the best way, again, it's not my domain. I think that 
 I've posted mail about it to the list, I'm not sure what the 
 outcome was.

 -Matej

 Igor Vaynberg wrote:
 i thought you _were_ working on the component use check and ajax 
 target stuff?

 -Igor


 On 9/22/06, *Matej Knopp*  [EMAIL PROTECTED] mailto:[EMAIL 
 PROTECTED]
 wrote:

 I don't think so. I was working on header contribution and 
 problem
 with
 debug console calling document.write() (thus removing all head
 elements
 from DOM).

 This is something completely different, it's related to the 
 component
 rendered check. That's not my domain. I believe the problem are
 components in wicket:head section of DataPicker.

 Anyway, what can temporary help is to disable component 
 render check
 in
 appication settings. Juergen?

 -Matej

 Igor Vaynberg wrote:
   matej was working to fix this, i thought he did matej?
  
   -Igor
  
  
   On 9/21/06, *samyem* [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]  wrote:
  
  
   I took the latest SVN code today and suddenly, I am 
 getting
 the
   following
   error everytime there is an ajax refresh on panels 
 with date
 pickers:
  
   2006-09-21 14:16:07,728 ERROR 
 wicket.ajax.AjaxRequestTarget -
 Error
   while
   responding to an AJAX request: 
 [EMAIL PROTECTED]
   markupIdToComponent [{pageBody_sidePanel=[MarkupContainer
 [Component
   id =
   sidePanel, page =
 com.wsi.mm.ui.directship.item.ItemDirectShipPage,
   path =
   4:pageBody:sidePanel.DirectShipSideBarPanel, isVisible 
 = true,
   isVersioned =
   false]]}], prependJavascript [[]], appendJavascript 
 [[var win;
   try {
   win = window.parent.Wicket.Window;
   } catch (ignore) {
   }
   if (typeof(win) != undefined  typeof(win.current ) !=
 undefined) {
   window.parent.setTimeout(function() {
   win.current.close();
   }, 0);
   }]]
   wicket.WicketRuntimeException: The component(s) below 
 failed
 to
   render. A
   common problem is that you have added a component in 
 code but
 forgot to
   reference it in the markup (thus the component will 
 never be
 rendered).
  
   1. [MarkupContainer [Component id = calendarMain, page =
   com.wsi.mm.ui.directship.item.ItemDirectShipPage , path =
 
 4:pageBody:sidePanel:massUpdate:massUpdateForm:releaseDate:picker:calendarMain.JavaScriptReference,
  

   isVisible = true, isVersioned = false]]
   2. [MarkupContainer [Component id = calendarSetup, page =
   com.wsi.mm.ui.directship.item.ItemDirectShipPage , path =

Re: [Wicket-user] ajax refresh on date picker

2006-09-25 Thread Martijn Dashorst

http://www.wicket-wiki.org.uk/wiki/index.php/Wicketfromsource

On 9/25/06, Matej Knopp [EMAIL PROTECTED] wrote:
 No Idea. Which version are you using?
 Anyway, there is a maven parameter that allows you to build a release
 without running unit test (look at older posts, it's certainly mentioned
 somewhere).

 -Matej

 Pierre-Yves Saumont wrote:
  Yes. I have even deleted everything and checked out a new complete fresh
  version, tried mvn clean, deleted manually the target and tried again !!
 
  I have no problem with wicket-extensions.
 
  Pierre-Yves
 
  Matej Knopp a écrit :
  This is strange. I've tested both current 1.x and 2.0
 
  in 1.x all tests completed with no problem for me,
  in 2.0 there are 4 errors and 1 failure.
 
  I don't know where the problem can be. Have you tried clean build?
 
  -Matej
 
  Pierre-Yves Saumont wrote:
  I tried to build the last version from trunk, but it fails the tests
  (32 failures) most failures report inversion of two html attributes,
  for exemple:
 
  === wicket.markup.MarkupInheritanceExtension_11 ===
  3c3
   link wicket:id=css src=myStyle.css/
  ---
link src=myStyle.css wicket:id=css/
 
  Checkout reported version # 7486.
 
  Pierre-Yves
 
  Matej Knopp a écrit :
  I've tested your quick start example with current svn and I worked as
  it should. Tested with FF1.5, IE6 and opera 9.
 
  Can you please test your project with current svn, if the problem
  persists?
 
  -Matej
 
 
  Pierre-Yves Saumont wrote:
  And in some conditions (see my other post with a quickstart
  example), the setup script is not even executed !!
 
  Pierre-Yves
 
  samyem a écrit :
  The header contribution logic seems to be still flawed. The javascript
  references were not added to the HTML's HEAD at all when the
  component is
  added by ajax. I guess this is a larger problem than the date
  picker. The
  same problem would occur everytime the javascript/stylesheet are added
  dynamically.
 
 
  Matej Knopp wrote:
  Well, I was working on it. But only to the degree that I disabled
  the disabling of check during ajax request, because it was no longer
  necessary.
 
  Unfortunately head contribution is something else, I'm not sure
  how to do it the best way, again, it's not my domain. I think that
  I've posted mail about it to the list, I'm not sure what the
  outcome was.
 
  -Matej
 
  Igor Vaynberg wrote:
  i thought you _were_ working on the component use check and ajax
  target stuff?
 
  -Igor
 
 
  On 9/22/06, *Matej Knopp*  [EMAIL PROTECTED] mailto:[EMAIL 
  PROTECTED]
  wrote:
 
  I don't think so. I was working on header contribution and
  problem
  with
  debug console calling document.write() (thus removing all head
  elements
  from DOM).
 
  This is something completely different, it's related to the
  component
  rendered check. That's not my domain. I believe the problem are
  components in wicket:head section of DataPicker.
 
  Anyway, what can temporary help is to disable component
  render check
  in
  appication settings. Juergen?
 
  -Matej
 
  Igor Vaynberg wrote:
matej was working to fix this, i thought he did matej?
   
-Igor
   
   
On 9/21/06, *samyem* [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]  wrote:
   
   
I took the latest SVN code today and suddenly, I am
  getting
  the
following
error everytime there is an ajax refresh on panels
  with date
  pickers:
   
2006-09-21 14:16:07,728 ERROR
  wicket.ajax.AjaxRequestTarget -
  Error
while
responding to an AJAX request:
  [EMAIL PROTECTED]
markupIdToComponent [{pageBody_sidePanel=[MarkupContainer
  [Component
id =
sidePanel, page =
  com.wsi.mm.ui.directship.item.ItemDirectShipPage,
path =
4:pageBody:sidePanel.DirectShipSideBarPanel, isVisible
  = true,
isVersioned =
false]]}], prependJavascript [[]], appendJavascript
  [[var win;
try {
win = window.parent.Wicket.Window;
} catch (ignore) {
}
if (typeof(win) != undefined  typeof(win.current ) !=
  undefined) {
window.parent.setTimeout(function() {
win.current.close();
}, 0);
}]]
wicket.WicketRuntimeException: The component(s) below
  failed
  to
render. A
common problem is that you have added a component in
  code but
  forgot to
reference it in the markup (thus the component will
  never be
  rendered).
   
1. [MarkupContainer [Component id = calendarMain, page =
com.wsi.mm.ui.directship.item.ItemDirectShipPage , path =

Re: [Wicket-user] ajax refresh on date picker


This problem is a bit difficult to reproduce. Anyway, I am trying to isolate
this into a quick start. So far, this is what I observed:

AbstractAjaxBehavior has a ThreadLocal variable called headContribHolder. It
is set to null by a call to cleanup() method, which is ment to be called
from AbstractBehavior.rendered(). However, the cleanup() implementation of
AbstractBehavior does not do anything. So the effect of this is that when
AbstractAjaxBehavior.renderHead() is eventually called in an ajax page after
going through a page that does not have ajax, the headContribHolder is not
reset and still assumes the value of a previous visit to another ajax page.
Since there is a check to see if the header has already been rendered, it
thinks the header has been rendered in the following code:

if (!contributors.contains(implementationId))
{
onRenderHeadInitContribution(response);
contributors.add(implementationId);
}

and thus you arrive at the problem I saw. I managed to get a quick fix by
making the AbstractBehavior reset the ThreadLocal variable, but there is
still a problem with the sequence flow that I'll let you fix.

- Samyem



Matej Knopp wrote:
 
 No matter what I do I just can't reproduce this. Can you please double 
 check that you're using branch wicket-1.x or trunk, and a clean build?
 
 If the problem persists, can you please either check if it happens with 
 wicket-examples too or try to isolate the problem and provide a 
 quickstart example? I'll be more than happy to look at it.
 
 Thanks,
 
 -Matej
 
 samyem wrote:
 Upon further investigations, what is clear is that when the page first
 loads,
 it loads up all the java scripts in the header. When I do a page refresh
 by
 pressing F5, the ensuing page does not render the javascript references
 at
 all. Looks like there is some logic which prevents javascripts from
 rendering after the initial page display. Here is what I am seeing in my
 HEAD tag :
 
 Initial page load:
 
 ?
 head
  meta http-equiv=Content-Type content=text/html;
 charset=ISO-8859-1title?/title
 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js/script
 script type=text/javascript
 id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/
 wicketAjaxDebugEnable=true;
 /*--]]*//script
 
 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js/script
 script type=text/javascript
 src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js/script
 script type=text/javascript
 src=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js/script
 link rel=stylesheet type=text/css
 href=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css
 link rel=stylesheet type=text/css
 href=/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css
 script type=text/javascript!--/*--![CDATA[/*!--*/
 if (window.name=='') {
 window.location=/mm/app?wicket:bookmarkablePage=wicket-0:com.wsi.mm.ui.media.MediaPage;
 }
 /*--]]*//script
 /head
 
 Subsequent refreshes:
 
 head
  meta http-equiv=Content-Type content=text/html;
 charset=ISO-8859-1title?/title
  
 script type=text/javascript!--/*--![CDATA[/*!--*/
 if (window.name=='') {
 window.location=/mm/app?wicket:bookmarkablePage=wicket-1:com.wsi.mm.ui.media.MediaPage;
 }
 /*--]]*//script
 /head
 
 Now I think we should be able to pinpoint the problem at the moment.
 
 
 
 
 samyem wrote:
 I am also getting this new error after the update:

 Error: wicketAjaxGet is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:11:1:
 Line: 1



 samyem wrote:
 I updated wicket and wicket-extension and now my modal window is not
 even
 showing and the date picker does not show up in non modal window pages
 as
 well. I can only see the error through the ajax debugger as:

 ...
 NFO: Response parsed. Now invoking steps...
 INFO:
 INFO: Initiating Ajax GET request on /mm/calendar.js
 INFO: Invoking pre-call handler(s)...
 ERROR: Received Ajax response with code: 404
 INFO: Invoking post-call handler(s)...
 INFO: Invoking failure handler(s)...
 ...

 After this, further clicks gives this error:

 INFO: Chanel busy - postponing...

 On non-modal pages, I get things like:

 Error: Calendar is not defined
 Source File: http://localhost:8081/mm/app?wicket:interface=:13::
 Line: 214

 And even my auto-complete text box is broken now with the latest code.
 I
 get things like:

 Error: Wicket.Ajax has no properties
 Source File: http://localhost:8081/mm/javascript/wicket-autocomplete.js
 Line: 7

 And the auto-complete fails to work. Nontheless, other ajax behaviour
 like ajax links and so forth are still working. When I revert the
 wicket
 library to the release version, it does not break like this. Before
 this
 fix, the only thing not working

Re: [Wicket-user] ajax refresh on date picker

2006-09-25 Thread Pierre-Yves Saumont

I am using 1.2.2 from trunk. I compiled the sources skipping the tests.

It still doesn't work in IE6. The only difference is that when I reload 
the page to have the whole page load normally (not through Ajax), it now 
throw an exception (with version 1.2.1, it worked). The exception is:

Root cause:java.lang.IllegalStateException: Cannot remove 
[MarkupContainer [Component id = 6, page = No Page, path = 
6.Loop$LoopItem]] from null parent! at 
wicket.Component.remove(Component.java:1475) at 
wicket.version.undo.Add.undo(Add.java:81) at 
wicket.version.undo.ChangeList.undo(ChangeList.java:93) at 
wicket.version.undo.UndoPageVersionManager.undo(UndoPageVersionManager.java:217)
 
 at 
wicket.version.undo.UndoPageVersionManager.getVersion(UndoPageVersionManager.java:167)
 
 at wicket.Page.getVersion(Page.java:586) at 
wicket.PageMap.get(PageMap.java:461) at 
wicket.Session.getPage(Session.java:418) at 
wicket.request.compound.DefaultRequestTargetResolverStrategy.resolveRenderedPage(DefaultRequestTargetResolverStrategy.java:215)
 
 at 
wicket.request.compound.DefaultRequestTargetResolverStrategy.resolve(DefaultRequestTargetResolverStrategy.java:152)
 
 at 
wicket.request.compound.AbstractCompoundRequestCycleProcessor.resolve(AbstractCompoundRequestCycleProcessor.java:48)
 
 at wicket.RequestCycle.step(RequestCycle.java:948) at 
wicket.RequestCycle.steps(RequestCycle.java:1040) at 
wicket.RequestCycle.request(RequestCycle.java:454) at 
wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:216) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:697) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
 
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 
 at 
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
 
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
 
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 
 at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
 
 at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
 
 at 
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
 
 at 
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) 
 at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) 
 at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) 
 at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
 
 at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) 
 at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) 
 at 
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
 
 at 
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
 
 at 
org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
 
 at java.lang.Thread.run(Thread.java:595)

Pierre-Yves


Matej Knopp a écrit :
 No Idea. Which version are you using?
 Anyway, there is a maven parameter that allows you to build a release 
 without running unit test (look at older posts, it's certainly mentioned 
 somewhere).
 
 -Matej
 
 Pierre-Yves Saumont wrote:
 Yes. I have even deleted everything and checked out a new complete 
 fresh version, tried mvn clean, deleted manually the target and tried 
 again !!

 I have no problem with wicket-extensions.

 Pierre-Yves

 Matej Knopp a écrit :
 This is strange. I've tested both current 1.x and 2.0

 in 1.x all tests completed with no problem for me,
 in 2.0 there are 4 errors and 1 failure.

 I don't know where the problem can be. Have you tried clean build?

 -Matej

 Pierre-Yves Saumont wrote:
 I tried to build the last version from trunk, but it fails the tests 
 (32 failures) most failures report inversion of two html attributes, 
 for exemple:

 === wicket.markup.MarkupInheritanceExtension_11 ===
 3c3
  link wicket:id=css src=myStyle.css/
 ---
   link src=myStyle.css wicket:id=css/

 Checkout reported version # 7486.

 Pierre-Yves

 Matej Knopp a écrit :
 I've tested your quick start example with current svn and I worked 
 as it should. Tested with FF1.5, IE6 and opera 9.

 Can you please test your project with current svn, if the problem 
 persists?

 -Matej


 Pierre-Yves Saumont wrote:
 And in some conditions (see my other post with a quickstart 
 example), the setup script is not even executed !!

 Pierre-Yves

 samyem a écrit :
 The header contribution logic seems to

Re: [Wicket-user] ajax refresh on date picker

Okay I have got something that'll make you happy: wicket quickstart! Pick it
up at http://www.yomari.net/~samyem/problem-wicket-quickstart.zip

I've identified the problem to be the way the ajax behaviour clears the
ThreadLocal variable, as I've explained in the other email. But I am not too
sure what is a proper fix for this problem.

This quick start has the essentials of the way I am using wicket. I cannot
do it anyother way due to the application's requirements. I've got it
working in my case for now by moving the ThreadLocal variable one step up in
AbstractBehavior and making the cleanup method in AbstractBehavior set the
ThreadLocal to null. That fixed this problem apparently, but I'll let you
have the final say on this.

- Samyem

Matej Knopp wrote:

No matter what I do I just can't reproduce this. Can you please double
check that you're using branch wicket-1.x or trunk, and a clean build?

If the problem persists, can you please either check if it happens with
wicket-examples too or try to isolate the problem and provide a
quickstart example? I'll be more than happy to look at it.

Thanks,

-Matej

samyem wrote:
Upon further investigations, what is clear is that when the page first
loads,
it loads up all the java scripts in the header. When I do a page refresh
by
pressing F5, the ensuing page does not render the javascript references
at
all. Looks like there is some logic which prevents javascripts from
rendering after the initial page display. Here is what I am seeing in my
HEAD tag :

Initial page load:

?
head
meta http-equiv=Content-Type content=text/html;
charset=ISO-8859-1title?/title
script type=text/javascript
src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js/script
script type=text/javascript
id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/
wicketAjaxDebugEnable=true;
/*--]]*//script

script type=text/javascript
src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js/script
script type=text/javascript
src=/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js/script
script type=text/javascript
src=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js/script
link rel=stylesheet type=text/css
href=/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css
link rel=stylesheet type=text/css
href=/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css
script type=text/javascript!--/*--![CDATA[/*!--*/
if (window.name=='') {
window.location=/mm/app?wicket:bookmarkablePage=wicket-0:com.wsi.mm.ui.media.MediaPage;
}
/*--]]*//script
/head

Subsequent refreshes:

head
meta http-equiv=Content-Type content=text/html;
charset=ISO-8859-1title?/title

script type=text/javascript!--/*--![CDATA[/*!--*/
if (window.name=='') {
window.location=/mm/app?wicket:bookmarkablePage=wicket-1:com.wsi.mm.ui.media.MediaPage;
}
/*--]]*//script
/head

Now I think we should be able to pinpoint the problem at the moment.

samyem wrote:
I am also getting this new error after the update:

Error: wicketAjaxGet is not defined
Source File: http://localhost:8081/mm/app?wicket:interface=:11:1:
Line: 1

samyem wrote:
I updated wicket and wicket-extension and now my modal window is not
even
showing and the date picker does not show up in non modal window pages
as
well. I can only see the error through the ajax debugger as:

...
NFO: Response parsed. Now invoking steps...
INFO:
INFO: Initiating Ajax GET request on /mm/calendar.js
INFO: Invoking pre-call handler(s)...
ERROR: Received Ajax response with code: 404
INFO: Invoking post-call handler(s)...
INFO: Invoking failure handler(s)...
...

After this, further clicks gives this error:

INFO: Chanel busy - postponing...

On non-modal pages, I get things like:

Error: Calendar is not defined
Source File: http://localhost:8081/mm/app?wicket:interface=:13::
Line: 214

And even my auto-complete text box is broken now with the latest code.
I
get things like:

Error: Wicket.Ajax has no properties
Source File: http://localhost:8081/mm/javascript/wicket-autocomplete.js
Line: 7

And the auto-complete fails to work. Nontheless, other ajax behaviour
like ajax links and so forth are still working. When I revert the
wicket
library to the release version, it does not break like this. Before
this
fix, the only thing not working was the date picker not working on ajax
refresh. Looks like the fix actually broke far more things than fixing
the original problem. If you cannot identify the problem, I could
prepare
a quickstart to demonstrate these issues.

- Samyem

Re: [Wicket-user] ajax refresh on date picker