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

[Martijn Dashorst]

Revert your wicket-spring and wicket-spring-annot (if you use that) to 1.2.4

Martijn

On 4/2/07, sraj <[EMAIL PROTECTED]> wrote:
>
> Hello!
>
> I changed the Wicket version to 1.2.5. We are using tomcat. And now we are
> getting the following error on server startup on some mcahines -
>
> Can you please let me know, if you know anything about this issue?
> ---
>
>  [ar] INFO wicket.protocol.http.WicketServlet.init:278 | WicketServlet
> loaded application EsearchApplication via
> wicket.spring.SpringWebApplicationFac
> tory factory
>  [ar] ERROR
> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/web-1.0-SNAPSHOT].log:675
> | StandardWrapper.Throwable
>  java.lang.Error: Unresolved compilation problems:
> The import wicket.injection.IFieldValueFactory cannot be resolved
> IFieldValueFactory cannot be resolved to a type
> factory cannot be resolved
> IFieldValueFactory cannot be resolved to a type
> factory cannot be resolved
>
> at
> wicket.spring.injection.annot.AnnotSpringInjector.(AnnotSpringInjector.java:4)
> at
> wicket.spring.injection.annot.SpringComponentInjector.(SpringComponentInjector.java:96)
> at
> wicket.spring.injection.annot.SpringComponentInjector.(SpringComponentInjector.java:68)
> at
> com.sn.esearch.webapp.common.EsearchApplication.init(EsearchApplication.java:101)
> at wicket.protocol.http.WicketServlet.init(WicketServlet.java:299)
> at javax.servlet.GenericServlet.init(GenericServlet.java:211)
> at
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
> at
> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932)
> at
> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3951)
> at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4225)
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
> at
> org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
> at
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
> at
> org.apache.catalina.core.StandardService.start(StandardService.java:450)
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:709)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)
> [ar] ERROR
> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/web-1.0-SNAPSHOT].loadOnStartup:3953
> | Servlet /web-1.0-SNAPSHOT threw load
> () exception
>  java.lang.Error: Unresolved compilation problems:
> The import wicket.injection.IFieldValueFactory cannot be resolved
> IFieldValueFactory cannot be resolved to a type
> factory cannot be resolved
> IFieldValueFactory cannot be resolved to a type
> factory cannot be resolved
>
> at
> wicket.spring.injection.annot.AnnotSpringInjector.(AnnotSpringInjector.java:4)
> at
> wicket.spring.injection.annot.SpringComponentInjector.(SpringComponentInjector.java:96)
> at
> wicket.spring.injection.annot.SpringComponentInjector.(SpringComponentInjector.java:68)
> at
> com.sn.esearch.webapp.common.EsearchApplication.init(EsearchApplication.java:101)
> at wicket.protocol.http.WicketServlet.init(WicketServlet.java:299)
> at javax.servlet.GenericServlet.init(GenericServlet.java:211)
> at
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
> at
> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932)
> at
> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3951)
> at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4225)
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
> at
> org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
> at
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
> at
> org.apache.catalina.core.StandardService.start(StandardService.java:450)
> at
> org.apache.catalina.core.StandardServ

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

[sraj]

Hello!

I changed the Wicket version to 1.2.5. We are using tomcat. And now we are
getting the following error on server startup on some mcahines - 

Can you please let me know, if you know anything about this issue?
---

 [ar] INFO wicket.protocol.http.WicketServlet.init:278 | WicketServlet
loaded application EsearchApplication via
wicket.spring.SpringWebApplicationFac
tory factory
 [ar] ERROR
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/web-1.0-SNAPSHOT].log:675
| StandardWrapper.Throwable
 java.lang.Error: Unresolved compilation problems:
The import wicket.injection.IFieldValueFactory cannot be resolved
IFieldValueFactory cannot be resolved to a type
factory cannot be resolved
IFieldValueFactory cannot be resolved to a type
factory cannot be resolved
 
at
wicket.spring.injection.annot.AnnotSpringInjector.(AnnotSpringInjector.java:4)
at
wicket.spring.injection.annot.SpringComponentInjector.(SpringComponentInjector.java:96)
at
wicket.spring.injection.annot.SpringComponentInjector.(SpringComponentInjector.java:68)
at
com.sn.esearch.webapp.common.EsearchApplication.init(EsearchApplication.java:101)
at wicket.protocol.http.WicketServlet.init(WicketServlet.java:299)
at javax.servlet.GenericServlet.init(GenericServlet.java:211)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3951)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4225)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
at
org.apache.catalina.core.StandardService.start(StandardService.java:450)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:709)
at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)
[ar] ERROR
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/web-1.0-SNAPSHOT].loadOnStartup:3953
| Servlet /web-1.0-SNAPSHOT threw load
() exception
 java.lang.Error: Unresolved compilation problems:
The import wicket.injection.IFieldValueFactory cannot be resolved
IFieldValueFactory cannot be resolved to a type
factory cannot be resolved
IFieldValueFactory cannot be resolved to a type
factory cannot be resolved
 
at
wicket.spring.injection.annot.AnnotSpringInjector.(AnnotSpringInjector.java:4)
at
wicket.spring.injection.annot.SpringComponentInjector.(SpringComponentInjector.java:96)
at
wicket.spring.injection.annot.SpringComponentInjector.(SpringComponentInjector.java:68)
at
com.sn.esearch.webapp.common.EsearchApplication.init(EsearchApplication.java:101)
at wicket.protocol.http.WicketServlet.init(WicketServlet.java:299)
at javax.servlet.GenericServlet.init(GenericServlet.java:211)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3951)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4225)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
at
org.apache.catalina.core.StandardService.start(StandardService.java:450)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:709)
at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(D

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

[sraj]

Thank you!  I will do that. Also, I changed my mode in web.xml to DEPLOYMENT. 

-Shyla


Eelco Hillenius wrote:
> 
> Yeah, please upgrade to a new version. You can download them here:
> http://sourceforge.net/project/showfiles.php?group_id=119783&package_id=130482
> or you can get the latest snapshot from here:
> http://wicketstuff.org/maven/repository/wicket/wicket/1.2-SNAPSHOT/
> 
> We want to do a 1.2.6 release soon if we can find some time.
> 
> Eelco
> 
> 
> On 3/30/07, sraj <[EMAIL PROTECTED]> wrote:
>>
>> 1.2.3.
>>
>> Thanks,
>> Shyla
>>
>>
>>
>> Eelco Hillenius wrote:
>> >
>> > What version of Wicket are you using? And if it is not the latest
>> > 1.2.x or 1.3, please upgrade.
>> >
>> > Eelco
>> >
>> >
>> >> Hello,
>> >>
>> >> I am getting 'Stack Overflow' error from the browser  while selecting
>> >> Date
>> >> from Date picker UI. Please help.
>> >>
>> >> Thanks,
>> >> sraj
>> >
>> >
>> -
>> > 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.php&p=sourceforge&CID=DEVDEV
>> > ___
>> > Wicket-user mailing list
>> > Wicket-user@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wicket-user
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/ajax-refresh-on-date-picker-tf2314518.html#a9756696
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> 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.php&p=sourceforge&CID=DEVDEV
>> ___
>> Wicket-user mailing list
>> Wicket-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wicket-user
>>
> 
> -
> 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.php&p=sourceforge&CID=DEVDEV
> ___
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> 
> 

-- 
View this message in context: 
http://www.nabble.com/ajax-refresh-on-date-picker-tf2314518.html#a9757054
Sent from the Wicket - User mailing list archive at Nabble.com.


-
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.php&p=sourceforge&CID=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

[Eelco Hillenius]

Yeah, please upgrade to a new version. You can download them here:
http://sourceforge.net/project/showfiles.php?group_id=119783&package_id=130482
or you can get the latest snapshot from here:
http://wicketstuff.org/maven/repository/wicket/wicket/1.2-SNAPSHOT/

We want to do a 1.2.6 release soon if we can find some time.

Eelco


On 3/30/07, sraj <[EMAIL PROTECTED]> wrote:
>
> 1.2.3.
>
> Thanks,
> Shyla
>
>
>
> Eelco Hillenius wrote:
> >
> > What version of Wicket are you using? And if it is not the latest
> > 1.2.x or 1.3, please upgrade.
> >
> > Eelco
> >
> >
> >> Hello,
> >>
> >> I am getting 'Stack Overflow' error from the browser  while selecting
> >> Date
> >> from Date picker UI. Please help.
> >>
> >> Thanks,
> >> sraj
> >
> > -
> > 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.php&p=sourceforge&CID=DEVDEV
> > ___
> > Wicket-user mailing list
> > Wicket-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
> >
>
> --
> View this message in context: 
> http://www.nabble.com/ajax-refresh-on-date-picker-tf2314518.html#a9756696
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> 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.php&p=sourceforge&CID=DEVDEV
> ___
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>

-
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.php&p=sourceforge&CID=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

[sraj]

1.2.3. 

Thanks,
Shyla



Eelco Hillenius wrote:
> 
> What version of Wicket are you using? And if it is not the latest
> 1.2.x or 1.3, please upgrade.
> 
> Eelco
> 
> 
>> Hello,
>>
>> I am getting 'Stack Overflow' error from the browser  while selecting
>> Date
>> from Date picker UI. Please help.
>>
>> Thanks,
>> sraj
> 
> -
> 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.php&p=sourceforge&CID=DEVDEV
> ___
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> 
> 

-- 
View this message in context: 
http://www.nabble.com/ajax-refresh-on-date-picker-tf2314518.html#a9756696
Sent from the Wicket - User mailing list archive at Nabble.com.


-
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.php&p=sourceforge&CID=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

[Eelco Hillenius]

What version of Wicket are you using? And if it is not the latest
1.2.x or 1.3, please upgrade.

Eelco


> Hello,
>
> I am getting 'Stack Overflow' error from the browser  while selecting Date
> from Date picker UI. Please help.
>
> Thanks,
> sraj

-
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.php&p=sourceforge&CID=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

[sraj]

Hello,

I am getting 'Stack Overflow' error from the browser  while selecting Date
from Date picker UI. Please help.

Thanks,
sraj


samyem wrote:
> 
> So far so good. It got rid of the issues with stack overflow and the other
> previous issues has not surfaced. 
> 
> Thanks,
> Samyem
> 
> 
> Matej Knopp wrote:
>> 
>> Hi,
>> 
>> it should be fixed in SVN, but I can't really test it. I've simulated 
>> updating of many elements so that I could reproduce the stack overflow, 
>> but I don't know if that is your case.
>> 
>> please try the current version and let me know.
>> 
>> -Matej
>> 
>> Matej Knopp wrote:
>>> Sorry for this, I've underestimated the stack size of browsers. Expect 
>>> it to be fixed withing couple of hours.
>>> 
>>> -Matej
>>> 
>>> Pierre-Yves Saumont wrote:
 Hi Samyem,

 Could you send me your script, so that I can see if it solves the 
 problem for me?

 Thanks,

 Pierre-Yves

 samyem a écrit :
> I could trace my problem to a recent change in wicket-ajax.js. In the
> defination of processNext, it used to be that the run was called on a
> timeout like window.setTimeout(run, 1);. Now this is only called for
> isKHTML, and there is a direct call to run() otherwise. This for some
> reason
> gave the recursion error for me. When I reverted this line and use the
> timeout version, the recursion error disappeared. I am not sure about
> the
> big picture of what's going on, but that gave me a dirty fix for now.
>
> - Samyem
>
>
>
> samyem wrote:
>> Same here. I am getting too much recursion in places I didn't have
>> problem
>> earlier as well. Looking at the generated source, it is clear that
>> the
>> java script gets included more than once, not just once in the
>> header.
>>
>> - Samyem
>>
>>
>> Pierre-Yves Saumont wrote:
>>> I am afraid there is still a problem. I tested the fix in the
>>> quickstart 
>>> I had made and it worked fine. However, in my application, selecting
>>> a 
>>> date in the datepicker cause a Javascript error. FF reports this
>>> error
>>> as:
>>>
>>> Erreur : too much recursion
>>> Fichier source : 
>>> http://localhost:8080/ceagrap/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
>>> Ligne : 1796
>>>
>>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>>> Date.prototype.setFullYear = function(y) {
>>>var d = new Date(this); <<< line 1796
>>>d.__msh_oldSetFullYear(y);
>>>if (d.getMonth() != this.getMonth())
>>>  this.setDate(28);
>>>this.__msh_oldSetFullYear(y);
>>> };
>>>
>>> In IE6, the error message is "not enough stack space". The same line 
>>> number is reported, but the next line is highlighted:
>>>
>>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>>> Date.prototype.setFullYear = function(y) {
>>>var d = new Date(this);
>>>d.__msh_oldSetFullYear(y); <<< line 1796
>>>if (d.getMonth() != this.getMonth())
>>>  this.setDate(28);
>>>this.__msh_oldSetFullYear(y);
>>> };
>>>
>>> If I reload the page, the error disapears.
>>>
>>> Pierre-Yves
>>>
>>>
>>> Matej Knopp a ?crit :
 Thanks for fixed files, I've already commited those.

 -Matej

 Pierre-Yves Saumont wrote:
> 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 = , 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 

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

[Martijn Dashorst]

and to add to the confusion, 1.x will first become 1.2.3 as soon as we
fix those damn bugs. 1.3 (or 1.2.4) will follow quickly.

Martijn

On 10/17/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
> Yeah, sorry, I meant 1.x.
>
> -Matej
>
> Pierre-Yves Saumont wrote:
> > Hi Matej,
> >
> > I suppose 1.3 is current branch 1.x ? I checked out this, and it works.
> > It still don't work with 1.2.2, but never mind. I hope it will continue
> > working as I add functionnalities to the application ;-)
> >
> > Thanks,
> >
> > Pierre-Yves
> >
> > Matej Knopp a écrit :
> >> Hi Pierre-Yvers,
> >>
> >> I've tested your example with IE, FF and Opera, in all browsers it
> >> worked well. I've tested it wicket current svn (branch 1.3). So if there
> >> really is a bug, I still can't reproduce it :(
> >>
> >> However, there is one bug your example helped me to find, and that is
> >> AjaxTabbedPanel being versioned (it throwed exceptions on page refresh).
> >>
> >> -Matej
> >>
> >> Pierre-Yves Saumont wrote:
> >>> Hi Matej,
> >>>
> >>> I eventually was able to make a stripped down  version of my app. It
> >>> still contains lot of unusefull stuff for the test case, but it is
> >>> only 270kb. I removed the jars in the lib directory to reduce the
> >>> size. You just have to copy the standard quickstart jars to make it
> >>> work (and rename the zip file since zip archive are not allowed in
> >>> this list). For user name and password, use wicket/wicket. There is a
> >>> datepicker on the first page. You can then click on any tab (inner or
> >>> outer) and go back to the first tab to experiment the problem. After
> >>> an Ajax call, the datePicker still opens, but it is not possible to
> >>> select a date.
> >>>
> >>> Pierre-Yves
> >>>
> >>>
> >>> Matej Knopp a écrit :
>  Well, the modification basically restored the behavior from before
>  the speed optimization was done. It shouldn't really change anything,
>  definitely not cause null instead of AjaxRequest (which probably
>  means that you're using fallback links and for some reason they are
>  not fired using Ajax).
> 
>  Anyway, are you able to provide a test case from any of this? All
>  these issues you are facing seem to be related to your application
>  quite closely, and I'm not able to reproduce any of it on my own.
> 
>  -Matej
> 
>  Pierre-Yves Saumont wrote:
> > Hi Matej,
> >
> > With this modification, some Ajax link are seeing there onClick
> > methods called with a null target.
> >
> > In the page I load, there is a top menu bar that loaded "Ajax
> > pages". In   this "pages" there is genrally a ajax tabbed panel. The
> > inner ajax links are working and the datepicker also works. When I
> > try to activate an outer link to display another " ajax page", I get
> > the null target exception. So I cannot test the datepicker on the
> > other pages.
> >
> > Pierre-Yves
> >
> >
> > Matej Knopp a écrit :
> >> This is very unfortunate. I'm not able to reproduce the stack
> >> overflow problem even with huge ajax responses.
> >>
> >> Can you plese replace the processNext method with this:
> >>
> >> processNext: function() {
> >> if (this.current < this.functions.length) {
> >> var f = this.functions[this.current];
> >> var run = function() {
> >> f(this.notify.bind(this));
> >> }.bind(this);
> >> this.current++;
> >>window.setTimeout(run, 1);
> >> }
> >>
> >> so that we can be sure that this is the problem.
> >>
> >> -Matej
> >>
> >>
> >> Pierre-Yves Saumont wrote:
> >>> I changed the value to 10. It does not change anything. I don't
> >>> know if it can be usefull, but I added the line:
> >>>
> >>> alert(this.depth);
> >>>
> >>> before line 120. When loading the Ajax response that contains the
> >>> datepicker, this alert is displayed 10 times with values 0 to 9.
> >>>
> >>> Pierre-Yves
> >>>
> >>> Matej Knopp a écrit :
>  That's not really the problem. The javascript _is_ included only
>  once. Problem is the performance improvement I did, calling the
>  run method from call stack instead of scheduling it on
>  window.setTimeout(). The latter is very slow, because it redraws
>  browser window.
> 
>  Anyway, it should no longer cause problem. Please make sure
>  you've cleaned browsers cache. If this is the case, please try to
>  change the number in wicket-ajax.js on line 120 (if (this.depth >
>  50 || Wicket.Browser.isKHTML
> 
>  try to set it to lower number, like 10 to see if it helps.
>  Perhaps I'm still overestimating the stack size? It's strange
>  because I've tested the code on large ajax upd

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

[Matej Knopp]

Yeah, sorry, I meant 1.x.

-Matej

Pierre-Yves Saumont wrote:
> Hi Matej,
> 
> I suppose 1.3 is current branch 1.x ? I checked out this, and it works. 
> It still don't work with 1.2.2, but never mind. I hope it will continue 
> working as I add functionnalities to the application ;-)
> 
> Thanks,
> 
> Pierre-Yves
> 
> Matej Knopp a écrit :
>> Hi Pierre-Yvers,
>>
>> I've tested your example with IE, FF and Opera, in all browsers it
>> worked well. I've tested it wicket current svn (branch 1.3). So if there 
>> really is a bug, I still can't reproduce it :(
>>
>> However, there is one bug your example helped me to find, and that is
>> AjaxTabbedPanel being versioned (it throwed exceptions on page refresh).
>>
>> -Matej
>>
>> Pierre-Yves Saumont wrote:
>>> Hi Matej,
>>>
>>> I eventually was able to make a stripped down  version of my app. It 
>>> still contains lot of unusefull stuff for the test case, but it is 
>>> only 270kb. I removed the jars in the lib directory to reduce the 
>>> size. You just have to copy the standard quickstart jars to make it 
>>> work (and rename the zip file since zip archive are not allowed in 
>>> this list). For user name and password, use wicket/wicket. There is a 
>>> datepicker on the first page. You can then click on any tab (inner or 
>>> outer) and go back to the first tab to experiment the problem. After 
>>> an Ajax call, the datePicker still opens, but it is not possible to 
>>> select a date.
>>>
>>> Pierre-Yves
>>>
>>>
>>> Matej Knopp a écrit :
 Well, the modification basically restored the behavior from before 
 the speed optimization was done. It shouldn't really change anything, 
 definitely not cause null instead of AjaxRequest (which probably 
 means that you're using fallback links and for some reason they are 
 not fired using Ajax).

 Anyway, are you able to provide a test case from any of this? All 
 these issues you are facing seem to be related to your application 
 quite closely, and I'm not able to reproduce any of it on my own.

 -Matej

 Pierre-Yves Saumont wrote:
> Hi Matej,
>
> With this modification, some Ajax link are seeing there onClick 
> methods called with a null target.
>
> In the page I load, there is a top menu bar that loaded "Ajax 
> pages". In   this "pages" there is genrally a ajax tabbed panel. The 
> inner ajax links are working and the datepicker also works. When I 
> try to activate an outer link to display another " ajax page", I get 
> the null target exception. So I cannot test the datepicker on the 
> other pages.
>
> Pierre-Yves
>
>
> Matej Knopp a écrit :
>> This is very unfortunate. I'm not able to reproduce the stack 
>> overflow problem even with huge ajax responses.
>>
>> Can you plese replace the processNext method with this:
>>
>> processNext: function() {
>> if (this.current < this.functions.length) {
>> var f = this.functions[this.current];
>> var run = function() {
>> f(this.notify.bind(this));
>> }.bind(this);
>> this.current++;
>>window.setTimeout(run, 1);
>> }
>>
>> so that we can be sure that this is the problem.
>>
>> -Matej
>>
>>
>> Pierre-Yves Saumont wrote:
>>> I changed the value to 10. It does not change anything. I don't 
>>> know if it can be usefull, but I added the line:
>>>
>>> alert(this.depth);
>>>
>>> before line 120. When loading the Ajax response that contains the 
>>> datepicker, this alert is displayed 10 times with values 0 to 9.
>>>
>>> Pierre-Yves
>>>
>>> Matej Knopp a écrit :
 That's not really the problem. The javascript _is_ included only 
 once. Problem is the performance improvement I did, calling the 
 run method from call stack instead of scheduling it on 
 window.setTimeout(). The latter is very slow, because it redraws 
 browser window.

 Anyway, it should no longer cause problem. Please make sure 
 you've cleaned browsers cache. If this is the case, please try to 
 change the number in wicket-ajax.js on line 120 (if (this.depth > 
 50 || Wicket.Browser.isKHTML

 try to set it to lower number, like 10 to see if it helps. 
 Perhaps I'm still overestimating the stack size? It's strange 
 because I've tested the code on large ajax updates and it worked 
 well.

 -Matej

 igor.vaynberg wrote:
> is it possible to change calendar.js and include an 
> include_only_once logic?
>
> -Igor
>
>
> Pierre-Yves Saumont wrote:
>> Hello Matej,
>>
>> I eventually found the updated file. (I was looking for the 
>

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

[Pierre-Yves Saumont]

Hi Matej,

I suppose 1.3 is current branch 1.x ? I checked out this, and it works. 
It still don't work with 1.2.2, but never mind. I hope it will continue 
working as I add functionnalities to the application ;-)

Thanks,

Pierre-Yves

Matej Knopp a écrit :
> Hi Pierre-Yvers,
> 
> I've tested your example with IE, FF and Opera, in all browsers it
> worked well. I've tested it wicket current svn (branch 1.3). So if there 
> really is a bug, I still can't reproduce it :(
> 
> However, there is one bug your example helped me to find, and that is
> AjaxTabbedPanel being versioned (it throwed exceptions on page refresh).
> 
> -Matej
> 
> Pierre-Yves Saumont wrote:
>> Hi Matej,
>>
>> I eventually was able to make a stripped down  version of my app. It 
>> still contains lot of unusefull stuff for the test case, but it is 
>> only 270kb. I removed the jars in the lib directory to reduce the 
>> size. You just have to copy the standard quickstart jars to make it 
>> work (and rename the zip file since zip archive are not allowed in 
>> this list). For user name and password, use wicket/wicket. There is a 
>> datepicker on the first page. You can then click on any tab (inner or 
>> outer) and go back to the first tab to experiment the problem. After 
>> an Ajax call, the datePicker still opens, but it is not possible to 
>> select a date.
>>
>> Pierre-Yves
>>
>>
>> Matej Knopp a écrit :
>>> Well, the modification basically restored the behavior from before 
>>> the speed optimization was done. It shouldn't really change anything, 
>>> definitely not cause null instead of AjaxRequest (which probably 
>>> means that you're using fallback links and for some reason they are 
>>> not fired using Ajax).
>>>
>>> Anyway, are you able to provide a test case from any of this? All 
>>> these issues you are facing seem to be related to your application 
>>> quite closely, and I'm not able to reproduce any of it on my own.
>>>
>>> -Matej
>>>
>>> Pierre-Yves Saumont wrote:
 Hi Matej,

 With this modification, some Ajax link are seeing there onClick 
 methods called with a null target.

 In the page I load, there is a top menu bar that loaded "Ajax 
 pages". In   this "pages" there is genrally a ajax tabbed panel. The 
 inner ajax links are working and the datepicker also works. When I 
 try to activate an outer link to display another " ajax page", I get 
 the null target exception. So I cannot test the datepicker on the 
 other pages.

 Pierre-Yves


 Matej Knopp a écrit :
> This is very unfortunate. I'm not able to reproduce the stack 
> overflow problem even with huge ajax responses.
>
> Can you plese replace the processNext method with this:
>
> processNext: function() {
> if (this.current < this.functions.length) {
> var f = this.functions[this.current];
> var run = function() {
> f(this.notify.bind(this));
> }.bind(this);
> this.current++;
>window.setTimeout(run, 1);
> }
>
> so that we can be sure that this is the problem.
>
> -Matej
>
>
> Pierre-Yves Saumont wrote:
>> I changed the value to 10. It does not change anything. I don't 
>> know if it can be usefull, but I added the line:
>>
>> alert(this.depth);
>>
>> before line 120. When loading the Ajax response that contains the 
>> datepicker, this alert is displayed 10 times with values 0 to 9.
>>
>> Pierre-Yves
>>
>> Matej Knopp a écrit :
>>> That's not really the problem. The javascript _is_ included only 
>>> once. Problem is the performance improvement I did, calling the 
>>> run method from call stack instead of scheduling it on 
>>> window.setTimeout(). The latter is very slow, because it redraws 
>>> browser window.
>>>
>>> Anyway, it should no longer cause problem. Please make sure 
>>> you've cleaned browsers cache. If this is the case, please try to 
>>> change the number in wicket-ajax.js on line 120 (if (this.depth > 
>>> 50 || Wicket.Browser.isKHTML
>>>
>>> try to set it to lower number, like 10 to see if it helps. 
>>> Perhaps I'm still overestimating the stack size? It's strange 
>>> because I've tested the code on large ajax updates and it worked 
>>> well.
>>>
>>> -Matej
>>>
>>> igor.vaynberg wrote:
 is it possible to change calendar.js and include an 
 include_only_once logic?

 -Igor


 Pierre-Yves Saumont wrote:
> Hello Matej,
>
> I eventually found the updated file. (I was looking for the 
> calendar.js file, and not for wicket-ajax.js). It doesn't 
> change anything. I still have a "too much recursion" error at 
> line 1796 of calendar.js
>
> Pie

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

[Matej Knopp]

Hi Pierre-Yvers,

I've tested your example with IE, FF and Opera, in all browsers it
worked well. I've tested it wicket current svn (branch 1.3). So if there 
really is a bug, I still can't reproduce it :(

However, there is one bug your example helped me to find, and that is
AjaxTabbedPanel being versioned (it throwed exceptions on page refresh).

-Matej

Pierre-Yves Saumont wrote:
> Hi Matej,
> 
> I eventually was able to make a stripped down  version of my app. It 
> still contains lot of unusefull stuff for the test case, but it is only 
> 270kb. I removed the jars in the lib directory to reduce the size. You 
> just have to copy the standard quickstart jars to make it work (and 
> rename the zip file since zip archive are not allowed in this list). For 
> user name and password, use wicket/wicket. There is a datepicker on the 
> first page. You can then click on any tab (inner or outer) and go back 
> to the first tab to experiment the problem. After an Ajax call, the 
> datePicker still opens, but it is not possible to select a date.
> 
> Pierre-Yves
> 
> 
> Matej Knopp a écrit :
>> Well, the modification basically restored the behavior from before the 
>> speed optimization was done. It shouldn't really change anything, 
>> definitely not cause null instead of AjaxRequest (which probably means 
>> that you're using fallback links and for some reason they are not 
>> fired using Ajax).
>>
>> Anyway, are you able to provide a test case from any of this? All 
>> these issues you are facing seem to be related to your application 
>> quite closely, and I'm not able to reproduce any of it on my own.
>>
>> -Matej
>>
>> Pierre-Yves Saumont wrote:
>>> Hi Matej,
>>>
>>> With this modification, some Ajax link are seeing there onClick 
>>> methods called with a null target.
>>>
>>> In the page I load, there is a top menu bar that loaded "Ajax pages". 
>>> In   this "pages" there is genrally a ajax tabbed panel. The inner 
>>> ajax links are working and the datepicker also works. When I try to 
>>> activate an outer link to display another " ajax page", I get the 
>>> null target exception. So I cannot test the datepicker on the other 
>>> pages.
>>>
>>> Pierre-Yves
>>>
>>>
>>> Matej Knopp a écrit :
 This is very unfortunate. I'm not able to reproduce the stack 
 overflow problem even with huge ajax responses.

 Can you plese replace the processNext method with this:

 processNext: function() {
 if (this.current < this.functions.length) {
 var f = this.functions[this.current];
 var run = function() {
 f(this.notify.bind(this));
 }.bind(this);
 this.current++;
window.setTimeout(run, 1);
 }

 so that we can be sure that this is the problem.

 -Matej


 Pierre-Yves Saumont wrote:
> I changed the value to 10. It does not change anything. I don't 
> know if it can be usefull, but I added the line:
>
> alert(this.depth);
>
> before line 120. When loading the Ajax response that contains the 
> datepicker, this alert is displayed 10 times with values 0 to 9.
>
> Pierre-Yves
>
> Matej Knopp a écrit :
>> That's not really the problem. The javascript _is_ included only 
>> once. Problem is the performance improvement I did, calling the 
>> run method from call stack instead of scheduling it on 
>> window.setTimeout(). The latter is very slow, because it redraws 
>> browser window.
>>
>> Anyway, it should no longer cause problem. Please make sure you've 
>> cleaned browsers cache. If this is the case, please try to change 
>> the number in wicket-ajax.js on line 120 (if (this.depth > 50 || 
>> Wicket.Browser.isKHTML
>>
>> try to set it to lower number, like 10 to see if it helps. Perhaps 
>> I'm still overestimating the stack size? It's strange because I've 
>> tested the code on large ajax updates and it worked well.
>>
>> -Matej
>>
>> igor.vaynberg wrote:
>>> is it possible to change calendar.js and include an 
>>> include_only_once logic?
>>>
>>> -Igor
>>>
>>>
>>> Pierre-Yves Saumont wrote:
 Hello Matej,

 I eventually found the updated file. (I was looking for the 
 calendar.js file, and not for wicket-ajax.js). It doesn't change 
 anything. I still have a "too much recursion" error at line 1796 
 of calendar.js

 Pierre-Yves

 Matej Knopp a ?crit :
> I assume there's something wrong with your svn setup. The 
> revision of wicket-ajax.js in svn is 7534, it's 3 days old
>
> http://svn.sourceforge.net/viewvc/*checkout*/wicket/branches/wicket-1.x/wicket/src/java/wicket/ajax/wicket-ajax.js?revision=7534
>  
>
>
> Maybe it would help to d

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

[Matej Knopp]

Well, the modification basically restored the behavior from before the 
speed optimization was done. It shouldn't really change anything, 
definitely not cause null instead of AjaxRequest (which probably means 
that you're using fallback links and for some reason they are not fired 
using Ajax).

Anyway, are you able to provide a test case from any of this? All these 
issues you are facing seem to be related to your application quite 
closely, and I'm not able to reproduce any of it on my own.

-Matej

Pierre-Yves Saumont wrote:
> Hi Matej,
> 
> With this modification, some Ajax link are seeing there onClick methods 
> called with a null target.
> 
> In the page I load, there is a top menu bar that loaded "Ajax pages". In 
>   this "pages" there is genrally a ajax tabbed panel. The inner ajax 
> links are working and the datepicker also works. When I try to activate 
> an outer link to display another " ajax page", I get the null target 
> exception. So I cannot test the datepicker on the other pages.
> 
> Pierre-Yves
> 
> 
> Matej Knopp a écrit :
>> This is very unfortunate. I'm not able to reproduce the stack overflow 
>> problem even with huge ajax responses.
>>
>> Can you plese replace the processNext method with this:
>>
>> processNext: function() {
>> if (this.current < this.functions.length) {
>> var f = this.functions[this.current];
>> var run = function() {
>> f(this.notify.bind(this));
>> }.bind(this);
>> this.current++;
>>
>> window.setTimeout(run, 1);
>> }
>>
>> so that we can be sure that this is the problem.
>>
>> -Matej
>>
>>
>> Pierre-Yves Saumont wrote:
>>> I changed the value to 10. It does not change anything. I don't know 
>>> if it can be usefull, but I added the line:
>>>
>>> alert(this.depth);
>>>
>>> before line 120. When loading the Ajax response that contains the 
>>> datepicker, this alert is displayed 10 times with values 0 to 9.
>>>
>>> Pierre-Yves
>>>
>>> Matej Knopp a écrit :
 That's not really the problem. The javascript _is_ included only 
 once. Problem is the performance improvement I did, calling the run 
 method from call stack instead of scheduling it on 
 window.setTimeout(). The latter is very slow, because it redraws 
 browser window.

 Anyway, it should no longer cause problem. Please make sure you've 
 cleaned browsers cache. If this is the case, please try to change the 
 number in wicket-ajax.js on line 120 (if (this.depth > 50 || 
 Wicket.Browser.isKHTML

 try to set it to lower number, like 10 to see if it helps. Perhaps 
 I'm still overestimating the stack size? It's strange because I've 
 tested the code on large ajax updates and it worked well.

 -Matej

 igor.vaynberg wrote:
> is it possible to change calendar.js and include an 
> include_only_once logic?
>
> -Igor
>
>
> Pierre-Yves Saumont wrote:
>> Hello Matej,
>>
>> I eventually found the updated file. (I was looking for the 
>> calendar.js file, and not for wicket-ajax.js). It doesn't change 
>> anything. I still have a "too much recursion" error at line 1796 of 
>> calendar.js
>>
>> Pierre-Yves
>>
>> Matej Knopp a ?crit :
>>> I assume there's something wrong with your svn setup. The revision 
>>> of wicket-ajax.js in svn is 7534, it's 3 days old
>>>
>>> http://svn.sourceforge.net/viewvc/*checkout*/wicket/branches/wicket-1.x/wicket/src/java/wicket/ajax/wicket-ajax.js?revision=7534
>>>  
>>>
>>>
>>> Maybe it would help to do a clean checkout of entire project.
>>>
>>> -Matej
>>>
>>> Pierre-Yves Saumont wrote:
 Hi Matej,

 I can't find anything newer than revision 7520 (udpate of the 
 french files) in branche 1.x and  revision 7519 in trunk.

 Where did you put the updated files?

 Thanks,

 Pierre-Yves

 Matej Knopp a ?crit :
> Hi,
>
> it should be fixed in SVN, but I can't really test it. I've 
> simulated updating of many elements so that I could reproduce 
> the stack overflow, but I don't know if that is your case.
>
> please try the current version and let me know.
>
> -Matej
>
> Matej Knopp wrote:
>> Sorry for this, I've underestimated the stack size of browsers. 
>> Expect it to be fixed withing couple of hours.
>>
>> -Matej
>>
>> Pierre-Yves Saumont wrote:
>>> Hi Samyem,
>>>
>>> Could you send me your script, so that I can see if it solves 
>>> the problem for me?
>>>
>>> Thanks,
>>>
>>> Pierre-Yves
>>>
>>> samyem a ?crit :
 I could trace my problem to a recent change in

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

[Pierre-Yves Saumont]

Hi Matej,

With this modification, some Ajax link are seeing there onClick methods 
called with a null target.

In the page I load, there is a top menu bar that loaded "Ajax pages". In 
  this "pages" there is genrally a ajax tabbed panel. The inner ajax 
links are working and the datepicker also works. When I try to activate 
an outer link to display another " ajax page", I get the null target 
exception. So I cannot test the datepicker on the other pages.

Pierre-Yves


Matej Knopp a écrit :
> This is very unfortunate. I'm not able to reproduce the stack overflow 
> problem even with huge ajax responses.
> 
> Can you plese replace the processNext method with this:
> 
> processNext: function() {
> if (this.current < this.functions.length) {
> var f = this.functions[this.current];
> var run = function() {
> f(this.notify.bind(this));
> }.bind(this);
> this.current++;
>
> window.setTimeout(run, 1);
> }
> 
> so that we can be sure that this is the problem.
> 
> -Matej
> 
> 
> Pierre-Yves Saumont wrote:
>> I changed the value to 10. It does not change anything. I don't know 
>> if it can be usefull, but I added the line:
>>
>> alert(this.depth);
>>
>> before line 120. When loading the Ajax response that contains the 
>> datepicker, this alert is displayed 10 times with values 0 to 9.
>>
>> Pierre-Yves
>>
>> Matej Knopp a écrit :
>>> That's not really the problem. The javascript _is_ included only 
>>> once. Problem is the performance improvement I did, calling the run 
>>> method from call stack instead of scheduling it on 
>>> window.setTimeout(). The latter is very slow, because it redraws 
>>> browser window.
>>>
>>> Anyway, it should no longer cause problem. Please make sure you've 
>>> cleaned browsers cache. If this is the case, please try to change the 
>>> number in wicket-ajax.js on line 120 (if (this.depth > 50 || 
>>> Wicket.Browser.isKHTML
>>>
>>> try to set it to lower number, like 10 to see if it helps. Perhaps 
>>> I'm still overestimating the stack size? It's strange because I've 
>>> tested the code on large ajax updates and it worked well.
>>>
>>> -Matej
>>>
>>> igor.vaynberg wrote:
 is it possible to change calendar.js and include an 
 include_only_once logic?

 -Igor


 Pierre-Yves Saumont wrote:
> Hello Matej,
>
> I eventually found the updated file. (I was looking for the 
> calendar.js file, and not for wicket-ajax.js). It doesn't change 
> anything. I still have a "too much recursion" error at line 1796 of 
> calendar.js
>
> Pierre-Yves
>
> Matej Knopp a ?crit :
>> I assume there's something wrong with your svn setup. The revision 
>> of wicket-ajax.js in svn is 7534, it's 3 days old
>>
>> http://svn.sourceforge.net/viewvc/*checkout*/wicket/branches/wicket-1.x/wicket/src/java/wicket/ajax/wicket-ajax.js?revision=7534
>>  
>>
>>
>> Maybe it would help to do a clean checkout of entire project.
>>
>> -Matej
>>
>> Pierre-Yves Saumont wrote:
>>> Hi Matej,
>>>
>>> I can't find anything newer than revision 7520 (udpate of the 
>>> french files) in branche 1.x and  revision 7519 in trunk.
>>>
>>> Where did you put the updated files?
>>>
>>> Thanks,
>>>
>>> Pierre-Yves
>>>
>>> Matej Knopp a ?crit :
 Hi,

 it should be fixed in SVN, but I can't really test it. I've 
 simulated updating of many elements so that I could reproduce 
 the stack overflow, but I don't know if that is your case.

 please try the current version and let me know.

 -Matej

 Matej Knopp wrote:
> Sorry for this, I've underestimated the stack size of browsers. 
> Expect it to be fixed withing couple of hours.
>
> -Matej
>
> Pierre-Yves Saumont wrote:
>> Hi Samyem,
>>
>> Could you send me your script, so that I can see if it solves 
>> the problem for me?
>>
>> Thanks,
>>
>> Pierre-Yves
>>
>> samyem a ?crit :
>>> I could trace my problem to a recent change in 
>>> wicket-ajax.js. In
>>> the
>>> defination of processNext, it used to be that the run was 
>>> called on
>>> a
>>> timeout like window.setTimeout(run, 1);. Now this is only 
>>> called for
>>> isKHTML, and there is a direct call to run() otherwise. This 
>>> for some reason
>>> gave the recursion error for me. When I reverted this line 
>>> and use the
>>> timeout version, the recursion error disappeared. I am not 
>>> sure about the
>>> big picture of what's going on, but that gave me a dirty fix for
>>> now.
>>>
>>> - Samyem
>

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

[Matej Knopp]

This is very unfortunate. I'm not able to reproduce the stack overflow 
problem even with huge ajax responses.

Can you plese replace the processNext method with this:

processNext: function() {
if (this.current < this.functions.length) {
var f = this.functions[this.current];
var run = function() {
f(this.notify.bind(this));
}.bind(this);
this.current++;

window.setTimeout(run, 1);
}

so that we can be sure that this is the problem.

-Matej


Pierre-Yves Saumont wrote:
> I changed the value to 10. It does not change anything. I don't know if 
> it can be usefull, but I added the line:
> 
> alert(this.depth);
> 
> before line 120. When loading the Ajax response that contains the 
> datepicker, this alert is displayed 10 times with values 0 to 9.
> 
> Pierre-Yves
> 
> Matej Knopp a écrit :
>> That's not really the problem. The javascript _is_ included only once. 
>> Problem is the performance improvement I did, calling the run method 
>> from call stack instead of scheduling it on window.setTimeout(). The 
>> latter is very slow, because it redraws browser window.
>>
>> Anyway, it should no longer cause problem. Please make sure you've 
>> cleaned browsers cache. If this is the case, please try to change the 
>> number in wicket-ajax.js on line 120 (if (this.depth > 50 || 
>> Wicket.Browser.isKHTML
>>
>> try to set it to lower number, like 10 to see if it helps. Perhaps I'm 
>> still overestimating the stack size? It's strange because I've tested 
>> the code on large ajax updates and it worked well.
>>
>> -Matej
>>
>> igor.vaynberg wrote:
>>> is it possible to change calendar.js and include an include_only_once logic?
>>>
>>> -Igor
>>>
>>>
>>> Pierre-Yves Saumont wrote:
 Hello Matej,

 I eventually found the updated file. (I was looking for the calendar.js 
 file, and not for wicket-ajax.js). It doesn't change anything. I still 
 have a "too much recursion" error at line 1796 of calendar.js

 Pierre-Yves

 Matej Knopp a ?crit :
> I assume there's something wrong with your svn setup. The revision of 
> wicket-ajax.js in svn is 7534, it's 3 days old
>
> http://svn.sourceforge.net/viewvc/*checkout*/wicket/branches/wicket-1.x/wicket/src/java/wicket/ajax/wicket-ajax.js?revision=7534
>  
>
>
> Maybe it would help to do a clean checkout of entire project.
>
> -Matej
>
> Pierre-Yves Saumont wrote:
>> Hi Matej,
>>
>> I can't find anything newer than revision 7520 (udpate of the french 
>> files) in branche 1.x and  revision 7519 in trunk.
>>
>> Where did you put the updated files?
>>
>> Thanks,
>>
>> Pierre-Yves
>>
>> Matej Knopp a ?crit :
>>> Hi,
>>>
>>> it should be fixed in SVN, but I can't really test it. I've simulated 
>>> updating of many elements so that I could reproduce the stack 
>>> overflow, but I don't know if that is your case.
>>>
>>> please try the current version and let me know.
>>>
>>> -Matej
>>>
>>> Matej Knopp wrote:
 Sorry for this, I've underestimated the stack size of browsers. 
 Expect it to be fixed withing couple of hours.

 -Matej

 Pierre-Yves Saumont wrote:
> Hi Samyem,
>
> Could you send me your script, so that I can see if it solves the 
> problem for me?
>
> Thanks,
>
> Pierre-Yves
>
> samyem a ?crit :
>> I could trace my problem to a recent change in wicket-ajax.js. In
>> the
>> defination of processNext, it used to be that the run was called on
>> a
>> timeout like window.setTimeout(run, 1);. Now this is only called for
>> isKHTML, and there is a direct call to run() otherwise. This for 
>> some reason
>> gave the recursion error for me. When I reverted this line and use 
>> the
>> timeout version, the recursion error disappeared. I am not sure 
>> about the
>> big picture of what's going on, but that gave me a dirty fix for
>> now.
>>
>> - Samyem
>>
>>
>>
>> samyem wrote:
>>> Same here. I am getting too much recursion in places I didn't 
>>> have problem
>>> earlier as well. Looking at the generated source, it is clear 
>>> that the
>>> java script gets included more than once, not just once in the 
>>> header.
>>>
>>> - Samyem
>>>
>>>
>>> Pierre-Yves Saumont wrote:
 I am afraid there is still a problem. I tested the fix in the 
 quickstart I had made and it worked fine. However, in 

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

[Pierre-Yves Saumont]

I changed the value to 10. It does not change anything. I don't know if 
it can be usefull, but I added the line:

alert(this.depth);

before line 120. When loading the Ajax response that contains the 
datepicker, this alert is displayed 10 times with values 0 to 9.

Pierre-Yves

Matej Knopp a écrit :
> That's not really the problem. The javascript _is_ included only once. 
> Problem is the performance improvement I did, calling the run method 
> from call stack instead of scheduling it on window.setTimeout(). The 
> latter is very slow, because it redraws browser window.
> 
> Anyway, it should no longer cause problem. Please make sure you've 
> cleaned browsers cache. If this is the case, please try to change the 
> number in wicket-ajax.js on line 120 (if (this.depth > 50 || 
> Wicket.Browser.isKHTML
> 
> try to set it to lower number, like 10 to see if it helps. Perhaps I'm 
> still overestimating the stack size? It's strange because I've tested 
> the code on large ajax updates and it worked well.
> 
> -Matej
> 
> igor.vaynberg wrote:
>> is it possible to change calendar.js and include an include_only_once logic?
>>
>> -Igor
>>
>>
>> Pierre-Yves Saumont wrote:
>>> Hello Matej,
>>>
>>> I eventually found the updated file. (I was looking for the calendar.js 
>>> file, and not for wicket-ajax.js). It doesn't change anything. I still 
>>> have a "too much recursion" error at line 1796 of calendar.js
>>>
>>> Pierre-Yves
>>>
>>> Matej Knopp a ?crit :
 I assume there's something wrong with your svn setup. The revision of 
 wicket-ajax.js in svn is 7534, it's 3 days old

 http://svn.sourceforge.net/viewvc/*checkout*/wicket/branches/wicket-1.x/wicket/src/java/wicket/ajax/wicket-ajax.js?revision=7534
  


 Maybe it would help to do a clean checkout of entire project.

 -Matej

 Pierre-Yves Saumont wrote:
> Hi Matej,
>
> I can't find anything newer than revision 7520 (udpate of the french 
> files) in branche 1.x and  revision 7519 in trunk.
>
> Where did you put the updated files?
>
> Thanks,
>
> Pierre-Yves
>
> Matej Knopp a ?crit :
>> Hi,
>>
>> it should be fixed in SVN, but I can't really test it. I've simulated 
>> updating of many elements so that I could reproduce the stack 
>> overflow, but I don't know if that is your case.
>>
>> please try the current version and let me know.
>>
>> -Matej
>>
>> Matej Knopp wrote:
>>> Sorry for this, I've underestimated the stack size of browsers. 
>>> Expect it to be fixed withing couple of hours.
>>>
>>> -Matej
>>>
>>> Pierre-Yves Saumont wrote:
 Hi Samyem,

 Could you send me your script, so that I can see if it solves the 
 problem for me?

 Thanks,

 Pierre-Yves

 samyem a ?crit :
> I could trace my problem to a recent change in wicket-ajax.js. In
> the
> defination of processNext, it used to be that the run was called on
> a
> timeout like window.setTimeout(run, 1);. Now this is only called for
> isKHTML, and there is a direct call to run() otherwise. This for 
> some reason
> gave the recursion error for me. When I reverted this line and use 
> the
> timeout version, the recursion error disappeared. I am not sure 
> about the
> big picture of what's going on, but that gave me a dirty fix for
> now.
>
> - Samyem
>
>
>
> samyem wrote:
>> Same here. I am getting too much recursion in places I didn't 
>> have problem
>> earlier as well. Looking at the generated source, it is clear 
>> that the
>> java script gets included more than once, not just once in the 
>> header.
>>
>> - Samyem
>>
>>
>> Pierre-Yves Saumont wrote:
>>> I am afraid there is still a problem. I tested the fix in the 
>>> quickstart I had made and it worked fine. However, in my 
>>> application, selecting a date in the datepicker cause a 
>>> Javascript error. FF reports this error
>>> as:
>>>
>>> Erreur : too much recursion
>>> Fichier source : 
>>> http://localhost:8080/ceagrap/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
>>>  
>>>
>>> Ligne : 1796
>>>
>>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>>> Date.prototype.setFullYear = function(y) {
>>>var d = new Date(this); <<< line 
>>> 1796
>>>d.__msh_oldSetFullYear(y);
>>>if (d.getMonth() != this.getMonth())
>>>  this.setDate(28);
>>>this.__msh_oldSetFullYear(y);
>>> };
>>>
>>> I

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

[Matej Knopp]

That's not really the problem. The javascript _is_ included only once. 
Problem is the performance improvement I did, calling the run method 
from call stack instead of scheduling it on window.setTimeout(). The 
latter is very slow, because it redraws browser window.

Anyway, it should no longer cause problem. Please make sure you've 
cleaned browsers cache. If this is the case, please try to change the 
number in wicket-ajax.js on line 120 (if (this.depth > 50 || 
Wicket.Browser.isKHTML

try to set it to lower number, like 10 to see if it helps. Perhaps I'm 
still overestimating the stack size? It's strange because I've tested 
the code on large ajax updates and it worked well.

-Matej

igor.vaynberg wrote:
> is it possible to change calendar.js and include an include_only_once logic?
> 
> -Igor
> 
> 
> Pierre-Yves Saumont wrote:
>> Hello Matej,
>>
>> I eventually found the updated file. (I was looking for the calendar.js 
>> file, and not for wicket-ajax.js). It doesn't change anything. I still 
>> have a "too much recursion" error at line 1796 of calendar.js
>>
>> Pierre-Yves
>>
>> Matej Knopp a ?crit :
>>> I assume there's something wrong with your svn setup. The revision of 
>>> wicket-ajax.js in svn is 7534, it's 3 days old
>>>
>>> http://svn.sourceforge.net/viewvc/*checkout*/wicket/branches/wicket-1.x/wicket/src/java/wicket/ajax/wicket-ajax.js?revision=7534
>>>  
>>>
>>>
>>> Maybe it would help to do a clean checkout of entire project.
>>>
>>> -Matej
>>>
>>> Pierre-Yves Saumont wrote:
 Hi Matej,

 I can't find anything newer than revision 7520 (udpate of the french 
 files) in branche 1.x and  revision 7519 in trunk.

 Where did you put the updated files?

 Thanks,

 Pierre-Yves

 Matej Knopp a ?crit :
> Hi,
>
> it should be fixed in SVN, but I can't really test it. I've simulated 
> updating of many elements so that I could reproduce the stack 
> overflow, but I don't know if that is your case.
>
> please try the current version and let me know.
>
> -Matej
>
> Matej Knopp wrote:
>> Sorry for this, I've underestimated the stack size of browsers. 
>> Expect it to be fixed withing couple of hours.
>>
>> -Matej
>>
>> Pierre-Yves Saumont wrote:
>>> Hi Samyem,
>>>
>>> Could you send me your script, so that I can see if it solves the 
>>> problem for me?
>>>
>>> Thanks,
>>>
>>> Pierre-Yves
>>>
>>> samyem a ?crit :
 I could trace my problem to a recent change in wicket-ajax.js. In
 the
 defination of processNext, it used to be that the run was called on
 a
 timeout like window.setTimeout(run, 1);. Now this is only called for
 isKHTML, and there is a direct call to run() otherwise. This for 
 some reason
 gave the recursion error for me. When I reverted this line and use 
 the
 timeout version, the recursion error disappeared. I am not sure 
 about the
 big picture of what's going on, but that gave me a dirty fix for
 now.

 - Samyem



 samyem wrote:
> Same here. I am getting too much recursion in places I didn't 
> have problem
> earlier as well. Looking at the generated source, it is clear 
> that the
> java script gets included more than once, not just once in the 
> header.
>
> - Samyem
>
>
> Pierre-Yves Saumont wrote:
>> I am afraid there is still a problem. I tested the fix in the 
>> quickstart I had made and it worked fine. However, in my 
>> application, selecting a date in the datepicker cause a 
>> Javascript error. FF reports this error
>> as:
>>
>> Erreur : too much recursion
>> Fichier source : 
>> http://localhost:8080/ceagrap/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
>>  
>>
>> Ligne : 1796
>>
>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>> Date.prototype.setFullYear = function(y) {
>>var d = new Date(this); <<< line 
>> 1796
>>d.__msh_oldSetFullYear(y);
>>if (d.getMonth() != this.getMonth())
>>  this.setDate(28);
>>this.__msh_oldSetFullYear(y);
>> };
>>
>> In IE6, the error message is "not enough stack space". The same 
>> line number is reported, but the next line is highlighted:
>>
>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>> Date.prototype.setFullYear = function(y) {
>>var d = new Date(this);
>>d.__msh_oldSetFullYear(y); <<< line
>> 1796
>>if (d.getMonth() != this.getMonth())

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

[igor.vaynberg]

is it possible to change calendar.js and include an include_only_once logic?

-Igor


Pierre-Yves Saumont wrote:
> 
> Hello Matej,
> 
> I eventually found the updated file. (I was looking for the calendar.js 
> file, and not for wicket-ajax.js). It doesn't change anything. I still 
> have a "too much recursion" error at line 1796 of calendar.js
> 
> Pierre-Yves
> 
> Matej Knopp a ?crit :
>> I assume there's something wrong with your svn setup. The revision of 
>> wicket-ajax.js in svn is 7534, it's 3 days old
>> 
>> http://svn.sourceforge.net/viewvc/*checkout*/wicket/branches/wicket-1.x/wicket/src/java/wicket/ajax/wicket-ajax.js?revision=7534
>>  
>> 
>> 
>> Maybe it would help to do a clean checkout of entire project.
>> 
>> -Matej
>> 
>> Pierre-Yves Saumont wrote:
>>> Hi Matej,
>>>
>>> I can't find anything newer than revision 7520 (udpate of the french 
>>> files) in branche 1.x and  revision 7519 in trunk.
>>>
>>> Where did you put the updated files?
>>>
>>> Thanks,
>>>
>>> Pierre-Yves
>>>
>>> Matej Knopp a ?crit :
 Hi,

 it should be fixed in SVN, but I can't really test it. I've simulated 
 updating of many elements so that I could reproduce the stack 
 overflow, but I don't know if that is your case.

 please try the current version and let me know.

 -Matej

 Matej Knopp wrote:
> Sorry for this, I've underestimated the stack size of browsers. 
> Expect it to be fixed withing couple of hours.
>
> -Matej
>
> Pierre-Yves Saumont wrote:
>> Hi Samyem,
>>
>> Could you send me your script, so that I can see if it solves the 
>> problem for me?
>>
>> Thanks,
>>
>> Pierre-Yves
>>
>> samyem a ?crit :
>>> I could trace my problem to a recent change in wicket-ajax.js. In
>>> the
>>> defination of processNext, it used to be that the run was called on
>>> a
>>> timeout like window.setTimeout(run, 1);. Now this is only called for
>>> isKHTML, and there is a direct call to run() otherwise. This for 
>>> some reason
>>> gave the recursion error for me. When I reverted this line and use 
>>> the
>>> timeout version, the recursion error disappeared. I am not sure 
>>> about the
>>> big picture of what's going on, but that gave me a dirty fix for
>>> now.
>>>
>>> - Samyem
>>>
>>>
>>>
>>> samyem wrote:
 Same here. I am getting too much recursion in places I didn't 
 have problem
 earlier as well. Looking at the generated source, it is clear 
 that the
 java script gets included more than once, not just once in the 
 header.

 - Samyem


 Pierre-Yves Saumont wrote:
> I am afraid there is still a problem. I tested the fix in the 
> quickstart I had made and it worked fine. However, in my 
> application, selecting a date in the datepicker cause a 
> Javascript error. FF reports this error
> as:
>
> Erreur : too much recursion
> Fichier source : 
> http://localhost:8080/ceagrap/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
>  
>
> Ligne : 1796
>
> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
> Date.prototype.setFullYear = function(y) {
>var d = new Date(this); <<< line 
> 1796
>d.__msh_oldSetFullYear(y);
>if (d.getMonth() != this.getMonth())
>  this.setDate(28);
>this.__msh_oldSetFullYear(y);
> };
>
> In IE6, the error message is "not enough stack space". The same 
> line number is reported, but the next line is highlighted:
>
> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
> Date.prototype.setFullYear = function(y) {
>var d = new Date(this);
>d.__msh_oldSetFullYear(y); <<< line
> 1796
>if (d.getMonth() != this.getMonth())
>  this.setDate(28);
>this.__msh_oldSetFullYear(y);
> };
>
> If I reload the page, the error disapears.
>
> Pierre-Yves
>
>
> Matej Knopp a ?crit :
>> Thanks for fixed files, I've already commited those.
>>
>> -Matej
>>
>> Pierre-Yves Saumont wrote:
>>> 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, 

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

[Pierre-Yves Saumont]

Hello Matej,

I eventually found the updated file. (I was looking for the calendar.js 
file, and not for wicket-ajax.js). It doesn't change anything. I still 
have a "too much recursion" error at line 1796 of calendar.js

Pierre-Yves

Matej Knopp a écrit :
> I assume there's something wrong with your svn setup. The revision of 
> wicket-ajax.js in svn is 7534, it's 3 days old
> 
> http://svn.sourceforge.net/viewvc/*checkout*/wicket/branches/wicket-1.x/wicket/src/java/wicket/ajax/wicket-ajax.js?revision=7534
>  
> 
> 
> Maybe it would help to do a clean checkout of entire project.
> 
> -Matej
> 
> Pierre-Yves Saumont wrote:
>> Hi Matej,
>>
>> I can't find anything newer than revision 7520 (udpate of the french 
>> files) in branche 1.x and  revision 7519 in trunk.
>>
>> Where did you put the updated files?
>>
>> Thanks,
>>
>> Pierre-Yves
>>
>> Matej Knopp a écrit :
>>> Hi,
>>>
>>> it should be fixed in SVN, but I can't really test it. I've simulated 
>>> updating of many elements so that I could reproduce the stack 
>>> overflow, but I don't know if that is your case.
>>>
>>> please try the current version and let me know.
>>>
>>> -Matej
>>>
>>> Matej Knopp wrote:
 Sorry for this, I've underestimated the stack size of browsers. 
 Expect it to be fixed withing couple of hours.

 -Matej

 Pierre-Yves Saumont wrote:
> Hi Samyem,
>
> Could you send me your script, so that I can see if it solves the 
> problem for me?
>
> Thanks,
>
> Pierre-Yves
>
> samyem a écrit :
>> I could trace my problem to a recent change in wicket-ajax.js. In the
>> defination of processNext, it used to be that the run was called on a
>> timeout like window.setTimeout(run, 1);. Now this is only called for
>> isKHTML, and there is a direct call to run() otherwise. This for 
>> some reason
>> gave the recursion error for me. When I reverted this line and use 
>> the
>> timeout version, the recursion error disappeared. I am not sure 
>> about the
>> big picture of what's going on, but that gave me a dirty fix for now.
>>
>> - Samyem
>>
>>
>>
>> samyem wrote:
>>> Same here. I am getting too much recursion in places I didn't 
>>> have problem
>>> earlier as well. Looking at the generated source, it is clear 
>>> that the
>>> java script gets included more than once, not just once in the 
>>> header.
>>>
>>> - Samyem
>>>
>>>
>>> Pierre-Yves Saumont wrote:
 I am afraid there is still a problem. I tested the fix in the 
 quickstart I had made and it worked fine. However, in my 
 application, selecting a date in the datepicker cause a 
 Javascript error. FF reports this error
 as:

 Erreur : too much recursion
 Fichier source : 
 http://localhost:8080/ceagrap/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
  

 Ligne : 1796

 Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
 Date.prototype.setFullYear = function(y) {
var d = new Date(this); <<< line 
 1796
d.__msh_oldSetFullYear(y);
if (d.getMonth() != this.getMonth())
  this.setDate(28);
this.__msh_oldSetFullYear(y);
 };

 In IE6, the error message is "not enough stack space". The same 
 line number is reported, but the next line is highlighted:

 Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
 Date.prototype.setFullYear = function(y) {
var d = new Date(this);
d.__msh_oldSetFullYear(y); <<< line 1796
if (d.getMonth() != this.getMonth())
  this.setDate(28);
this.__msh_oldSetFullYear(y);
 };

 If I reload the page, the error disapears.

 Pierre-Yves


 Matej Knopp a ?crit :
> Thanks for fixed files, I've already commited those.
>
> -Matej
>
> Pierre-Yves Saumont wrote:
>> 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:
>>>

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

[Matej Knopp]

I assume there's something wrong with your svn setup. The revision of 
wicket-ajax.js in svn is 7534, it's 3 days old

http://svn.sourceforge.net/viewvc/*checkout*/wicket/branches/wicket-1.x/wicket/src/java/wicket/ajax/wicket-ajax.js?revision=7534

Maybe it would help to do a clean checkout of entire project.

-Matej

Pierre-Yves Saumont wrote:
> Hi Matej,
> 
> I can't find anything newer than revision 7520 (udpate of the french 
> files) in branche 1.x and  revision 7519 in trunk.
> 
> Where did you put the updated files?
> 
> Thanks,
> 
> Pierre-Yves
> 
> Matej Knopp a écrit :
>> Hi,
>>
>> it should be fixed in SVN, but I can't really test it. I've simulated 
>> updating of many elements so that I could reproduce the stack overflow, 
>> but I don't know if that is your case.
>>
>> please try the current version and let me know.
>>
>> -Matej
>>
>> Matej Knopp wrote:
>>> Sorry for this, I've underestimated the stack size of browsers. Expect 
>>> it to be fixed withing couple of hours.
>>>
>>> -Matej
>>>
>>> Pierre-Yves Saumont wrote:
 Hi Samyem,

 Could you send me your script, so that I can see if it solves the 
 problem for me?

 Thanks,

 Pierre-Yves

 samyem a écrit :
> I could trace my problem to a recent change in wicket-ajax.js. In the
> defination of processNext, it used to be that the run was called on a
> timeout like window.setTimeout(run, 1);. Now this is only called for
> isKHTML, and there is a direct call to run() otherwise. This for some 
> reason
> gave the recursion error for me. When I reverted this line and use the
> timeout version, the recursion error disappeared. I am not sure about the
> big picture of what's going on, but that gave me a dirty fix for now.
>
> - Samyem
>
>
>
> samyem wrote:
>> Same here. I am getting too much recursion in places I didn't have 
>> problem
>> earlier as well. Looking at the generated source, it is clear that the
>> java script gets included more than once, not just once in the header.
>>
>> - Samyem
>>
>>
>> Pierre-Yves Saumont wrote:
>>> I am afraid there is still a problem. I tested the fix in the 
>>> quickstart 
>>> I had made and it worked fine. However, in my application, selecting a 
>>> date in the datepicker cause a Javascript error. FF reports this error
>>> as:
>>>
>>> Erreur : too much recursion
>>> Fichier source : 
>>> http://localhost:8080/ceagrap/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
>>> Ligne : 1796
>>>
>>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>>> Date.prototype.setFullYear = function(y) {
>>>var d = new Date(this); <<< line 1796
>>>d.__msh_oldSetFullYear(y);
>>>if (d.getMonth() != this.getMonth())
>>>  this.setDate(28);
>>>this.__msh_oldSetFullYear(y);
>>> };
>>>
>>> In IE6, the error message is "not enough stack space". The same line 
>>> number is reported, but the next line is highlighted:
>>>
>>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>>> Date.prototype.setFullYear = function(y) {
>>>var d = new Date(this);
>>>d.__msh_oldSetFullYear(y); <<< line 1796
>>>if (d.getMonth() != this.getMonth())
>>>  this.setDate(28);
>>>this.__msh_oldSetFullYear(y);
>>> };
>>>
>>> If I reload the page, the error disapears.
>>>
>>> Pierre-Yves
>>>
>>>
>>> Matej Knopp a ?crit :
 Thanks for fixed files, I've already commited those.

 -Matej

 Pierre-Yves Saumont wrote:
> 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 = , 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(UndoPageVersionMa

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

[Pierre-Yves Saumont]

Hi Matej,

I can't find anything newer than revision 7520 (udpate of the french 
files) in branche 1.x and  revision 7519 in trunk.

Where did you put the updated files?

Thanks,

Pierre-Yves

Matej Knopp a écrit :
> Hi,
> 
> it should be fixed in SVN, but I can't really test it. I've simulated 
> updating of many elements so that I could reproduce the stack overflow, 
> but I don't know if that is your case.
> 
> please try the current version and let me know.
> 
> -Matej
> 
> Matej Knopp wrote:
>> Sorry for this, I've underestimated the stack size of browsers. Expect 
>> it to be fixed withing couple of hours.
>>
>> -Matej
>>
>> Pierre-Yves Saumont wrote:
>>> Hi Samyem,
>>>
>>> Could you send me your script, so that I can see if it solves the 
>>> problem for me?
>>>
>>> Thanks,
>>>
>>> Pierre-Yves
>>>
>>> samyem a écrit :
 I could trace my problem to a recent change in wicket-ajax.js. In the
 defination of processNext, it used to be that the run was called on a
 timeout like window.setTimeout(run, 1);. Now this is only called for
 isKHTML, and there is a direct call to run() otherwise. This for some 
 reason
 gave the recursion error for me. When I reverted this line and use the
 timeout version, the recursion error disappeared. I am not sure about the
 big picture of what's going on, but that gave me a dirty fix for now.

 - Samyem



 samyem wrote:
> Same here. I am getting too much recursion in places I didn't have problem
> earlier as well. Looking at the generated source, it is clear that the
> java script gets included more than once, not just once in the header.
>
> - Samyem
>
>
> Pierre-Yves Saumont wrote:
>> I am afraid there is still a problem. I tested the fix in the quickstart 
>> I had made and it worked fine. However, in my application, selecting a 
>> date in the datepicker cause a Javascript error. FF reports this error
>> as:
>>
>> Erreur : too much recursion
>> Fichier source : 
>> http://localhost:8080/ceagrap/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
>> Ligne : 1796
>>
>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>> Date.prototype.setFullYear = function(y) {
>>var d = new Date(this); <<< line 1796
>>d.__msh_oldSetFullYear(y);
>>if (d.getMonth() != this.getMonth())
>>  this.setDate(28);
>>this.__msh_oldSetFullYear(y);
>> };
>>
>> In IE6, the error message is "not enough stack space". The same line 
>> number is reported, but the next line is highlighted:
>>
>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>> Date.prototype.setFullYear = function(y) {
>>var d = new Date(this);
>>d.__msh_oldSetFullYear(y); <<< line 1796
>>if (d.getMonth() != this.getMonth())
>>  this.setDate(28);
>>this.__msh_oldSetFullYear(y);
>> };
>>
>> If I reload the page, the error disapears.
>>
>> Pierre-Yves
>>
>>
>> Matej Knopp a ?crit :
>>> Thanks for fixed files, I've already commited those.
>>>
>>> -Matej
>>>
>>> Pierre-Yves Saumont wrote:
 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 = , 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

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

[samyem]

So far so good. It got rid of the issues with stack overflow and the other
previous issues has not surfaced. 

Thanks,
Samyem


Matej Knopp wrote:
> 
> Hi,
> 
> it should be fixed in SVN, but I can't really test it. I've simulated 
> updating of many elements so that I could reproduce the stack overflow, 
> but I don't know if that is your case.
> 
> please try the current version and let me know.
> 
> -Matej
> 
> Matej Knopp wrote:
>> Sorry for this, I've underestimated the stack size of browsers. Expect 
>> it to be fixed withing couple of hours.
>> 
>> -Matej
>> 
>> Pierre-Yves Saumont wrote:
>>> Hi Samyem,
>>>
>>> Could you send me your script, so that I can see if it solves the 
>>> problem for me?
>>>
>>> Thanks,
>>>
>>> Pierre-Yves
>>>
>>> samyem a ?crit :
 I could trace my problem to a recent change in wicket-ajax.js. In the
 defination of processNext, it used to be that the run was called on a
 timeout like window.setTimeout(run, 1);. Now this is only called for
 isKHTML, and there is a direct call to run() otherwise. This for some
 reason
 gave the recursion error for me. When I reverted this line and use the
 timeout version, the recursion error disappeared. I am not sure about
 the
 big picture of what's going on, but that gave me a dirty fix for now.

 - Samyem



 samyem wrote:
> Same here. I am getting too much recursion in places I didn't have
> problem
> earlier as well. Looking at the generated source, it is clear that the
> java script gets included more than once, not just once in the header.
>
> - Samyem
>
>
> Pierre-Yves Saumont wrote:
>> I am afraid there is still a problem. I tested the fix in the
>> quickstart 
>> I had made and it worked fine. However, in my application, selecting
>> a 
>> date in the datepicker cause a Javascript error. FF reports this
>> error
>> as:
>>
>> Erreur : too much recursion
>> Fichier source : 
>> http://localhost:8080/ceagrap/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
>> Ligne : 1796
>>
>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>> Date.prototype.setFullYear = function(y) {
>>var d = new Date(this); <<< line 1796
>>d.__msh_oldSetFullYear(y);
>>if (d.getMonth() != this.getMonth())
>>  this.setDate(28);
>>this.__msh_oldSetFullYear(y);
>> };
>>
>> In IE6, the error message is "not enough stack space". The same line 
>> number is reported, but the next line is highlighted:
>>
>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>> Date.prototype.setFullYear = function(y) {
>>var d = new Date(this);
>>d.__msh_oldSetFullYear(y); <<< line 1796
>>if (d.getMonth() != this.getMonth())
>>  this.setDate(28);
>>this.__msh_oldSetFullYear(y);
>> };
>>
>> If I reload the page, the error disapears.
>>
>> Pierre-Yves
>>
>>
>> Matej Knopp a ?crit :
>>> Thanks for fixed files, I've already commited those.
>>>
>>> -Matej
>>>
>>> Pierre-Yves Saumont wrote:
 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 = , 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

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

[Pierre-Yves Saumont]

I can't find it yet in SVN. Only the french files are new.

Pierre-Yves

Matej Knopp a écrit :
> Hi,
> 
> it should be fixed in SVN, but I can't really test it. I've simulated 
> updating of many elements so that I could reproduce the stack overflow, 
> but I don't know if that is your case.
> 
> please try the current version and let me know.
> 
> -Matej
> 
> Matej Knopp wrote:
>> Sorry for this, I've underestimated the stack size of browsers. Expect 
>> it to be fixed withing couple of hours.
>>
>> -Matej
>>
>> Pierre-Yves Saumont wrote:
>>> Hi Samyem,
>>>
>>> Could you send me your script, so that I can see if it solves the 
>>> problem for me?
>>>
>>> Thanks,
>>>
>>> Pierre-Yves
>>>
>>> samyem a écrit :
 I could trace my problem to a recent change in wicket-ajax.js. In the
 defination of processNext, it used to be that the run was called on a
 timeout like window.setTimeout(run, 1);. Now this is only called for
 isKHTML, and there is a direct call to run() otherwise. This for some 
 reason
 gave the recursion error for me. When I reverted this line and use the
 timeout version, the recursion error disappeared. I am not sure about the
 big picture of what's going on, but that gave me a dirty fix for now.

 - Samyem



 samyem wrote:
> Same here. I am getting too much recursion in places I didn't have problem
> earlier as well. Looking at the generated source, it is clear that the
> java script gets included more than once, not just once in the header.
>
> - Samyem
>
>
> Pierre-Yves Saumont wrote:
>> I am afraid there is still a problem. I tested the fix in the quickstart 
>> I had made and it worked fine. However, in my application, selecting a 
>> date in the datepicker cause a Javascript error. FF reports this error
>> as:
>>
>> Erreur : too much recursion
>> Fichier source : 
>> http://localhost:8080/ceagrap/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
>> Ligne : 1796
>>
>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>> Date.prototype.setFullYear = function(y) {
>>var d = new Date(this); <<< line 1796
>>d.__msh_oldSetFullYear(y);
>>if (d.getMonth() != this.getMonth())
>>  this.setDate(28);
>>this.__msh_oldSetFullYear(y);
>> };
>>
>> In IE6, the error message is "not enough stack space". The same line 
>> number is reported, but the next line is highlighted:
>>
>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>> Date.prototype.setFullYear = function(y) {
>>var d = new Date(this);
>>d.__msh_oldSetFullYear(y); <<< line 1796
>>if (d.getMonth() != this.getMonth())
>>  this.setDate(28);
>>this.__msh_oldSetFullYear(y);
>> };
>>
>> If I reload the page, the error disapears.
>>
>> Pierre-Yves
>>
>>
>> Matej Knopp a ?crit :
>>> Thanks for fixed files, I've already commited those.
>>>
>>> -Matej
>>>
>>> Pierre-Yves Saumont wrote:
 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 = , 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 poi

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

[Matej Knopp]

Hi,

it should be fixed in SVN, but I can't really test it. I've simulated 
updating of many elements so that I could reproduce the stack overflow, 
but I don't know if that is your case.

please try the current version and let me know.

-Matej

Matej Knopp wrote:
> Sorry for this, I've underestimated the stack size of browsers. Expect 
> it to be fixed withing couple of hours.
> 
> -Matej
> 
> Pierre-Yves Saumont wrote:
>> Hi Samyem,
>>
>> Could you send me your script, so that I can see if it solves the 
>> problem for me?
>>
>> Thanks,
>>
>> Pierre-Yves
>>
>> samyem a écrit :
>>> I could trace my problem to a recent change in wicket-ajax.js. In the
>>> defination of processNext, it used to be that the run was called on a
>>> timeout like window.setTimeout(run, 1);. Now this is only called for
>>> isKHTML, and there is a direct call to run() otherwise. This for some reason
>>> gave the recursion error for me. When I reverted this line and use the
>>> timeout version, the recursion error disappeared. I am not sure about the
>>> big picture of what's going on, but that gave me a dirty fix for now.
>>>
>>> - Samyem
>>>
>>>
>>>
>>> samyem wrote:
 Same here. I am getting too much recursion in places I didn't have problem
 earlier as well. Looking at the generated source, it is clear that the
 java script gets included more than once, not just once in the header.

 - Samyem


 Pierre-Yves Saumont wrote:
> I am afraid there is still a problem. I tested the fix in the quickstart 
> I had made and it worked fine. However, in my application, selecting a 
> date in the datepicker cause a Javascript error. FF reports this error
> as:
>
> Erreur : too much recursion
> Fichier source : 
> http://localhost:8080/ceagrap/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
> Ligne : 1796
>
> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
> Date.prototype.setFullYear = function(y) {
>var d = new Date(this); <<< line 1796
>d.__msh_oldSetFullYear(y);
>if (d.getMonth() != this.getMonth())
>  this.setDate(28);
>this.__msh_oldSetFullYear(y);
> };
>
> In IE6, the error message is "not enough stack space". The same line 
> number is reported, but the next line is highlighted:
>
> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
> Date.prototype.setFullYear = function(y) {
>var d = new Date(this);
>d.__msh_oldSetFullYear(y); <<< line 1796
>if (d.getMonth() != this.getMonth())
>  this.setDate(28);
>this.__msh_oldSetFullYear(y);
> };
>
> If I reload the page, the error disapears.
>
> Pierre-Yves
>
>
> Matej Knopp a ?crit :
>> Thanks for fixed files, I've already commited those.
>>
>> -Matej
>>
>> Pierre-Yves Saumont wrote:
>>> 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 = , 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 

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

[Matej Knopp]

Sorry for this, I've underestimated the stack size of browsers. Expect 
it to be fixed withing couple of hours.

-Matej

Pierre-Yves Saumont wrote:
> Hi Samyem,
> 
> Could you send me your script, so that I can see if it solves the 
> problem for me?
> 
> Thanks,
> 
> Pierre-Yves
> 
> samyem a écrit :
>> I could trace my problem to a recent change in wicket-ajax.js. In the
>> defination of processNext, it used to be that the run was called on a
>> timeout like window.setTimeout(run, 1);. Now this is only called for
>> isKHTML, and there is a direct call to run() otherwise. This for some reason
>> gave the recursion error for me. When I reverted this line and use the
>> timeout version, the recursion error disappeared. I am not sure about the
>> big picture of what's going on, but that gave me a dirty fix for now.
>>
>> - Samyem
>>
>>
>>
>> samyem wrote:
>>> Same here. I am getting too much recursion in places I didn't have problem
>>> earlier as well. Looking at the generated source, it is clear that the
>>> java script gets included more than once, not just once in the header.
>>>
>>> - Samyem
>>>
>>>
>>> Pierre-Yves Saumont wrote:
 I am afraid there is still a problem. I tested the fix in the quickstart 
 I had made and it worked fine. However, in my application, selecting a 
 date in the datepicker cause a Javascript error. FF reports this error
 as:

 Erreur : too much recursion
 Fichier source : 
 http://localhost:8080/ceagrap/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
 Ligne : 1796

 Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
 Date.prototype.setFullYear = function(y) {
var d = new Date(this); <<< line 1796
d.__msh_oldSetFullYear(y);
if (d.getMonth() != this.getMonth())
  this.setDate(28);
this.__msh_oldSetFullYear(y);
 };

 In IE6, the error message is "not enough stack space". The same line 
 number is reported, but the next line is highlighted:

 Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
 Date.prototype.setFullYear = function(y) {
var d = new Date(this);
d.__msh_oldSetFullYear(y); <<< line 1796
if (d.getMonth() != this.getMonth())
  this.setDate(28);
this.__msh_oldSetFullYear(y);
 };

 If I reload the page, the error disapears.

 Pierre-Yves


 Matej Knopp a ?crit :
> Thanks for fixed files, I've already commited those.
>
> -Matej
>
> Pierre-Yves Saumont wrote:
>> 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 = , 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

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

[Pierre-Yves Saumont]

Hi Samyem,

Could you send me your script, so that I can see if it solves the 
problem for me?

Thanks,

Pierre-Yves

samyem a écrit :
> I could trace my problem to a recent change in wicket-ajax.js. In the
> defination of processNext, it used to be that the run was called on a
> timeout like window.setTimeout(run, 1);. Now this is only called for
> isKHTML, and there is a direct call to run() otherwise. This for some reason
> gave the recursion error for me. When I reverted this line and use the
> timeout version, the recursion error disappeared. I am not sure about the
> big picture of what's going on, but that gave me a dirty fix for now.
> 
> - Samyem
> 
> 
> 
> samyem wrote:
>> Same here. I am getting too much recursion in places I didn't have problem
>> earlier as well. Looking at the generated source, it is clear that the
>> java script gets included more than once, not just once in the header.
>>
>> - Samyem
>>
>>
>> Pierre-Yves Saumont wrote:
>>> I am afraid there is still a problem. I tested the fix in the quickstart 
>>> I had made and it worked fine. However, in my application, selecting a 
>>> date in the datepicker cause a Javascript error. FF reports this error
>>> as:
>>>
>>> Erreur : too much recursion
>>> Fichier source : 
>>> http://localhost:8080/ceagrap/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
>>> Ligne : 1796
>>>
>>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>>> Date.prototype.setFullYear = function(y) {
>>>var d = new Date(this); <<< line 1796
>>>d.__msh_oldSetFullYear(y);
>>>if (d.getMonth() != this.getMonth())
>>>  this.setDate(28);
>>>this.__msh_oldSetFullYear(y);
>>> };
>>>
>>> In IE6, the error message is "not enough stack space". The same line 
>>> number is reported, but the next line is highlighted:
>>>
>>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>>> Date.prototype.setFullYear = function(y) {
>>>var d = new Date(this);
>>>d.__msh_oldSetFullYear(y); <<< line 1796
>>>if (d.getMonth() != this.getMonth())
>>>  this.setDate(28);
>>>this.__msh_oldSetFullYear(y);
>>> };
>>>
>>> If I reload the page, the error disapears.
>>>
>>> Pierre-Yves
>>>
>>>
>>> Matej Knopp a ?crit :
 Thanks for fixed files, I've already commited those.

 -Matej

 Pierre-Yves Saumont wrote:
> 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 = , 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 Knop

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

[samyem]

I could trace my problem to a recent change in wicket-ajax.js. In the
defination of processNext, it used to be that the run was called on a
timeout like window.setTimeout(run, 1);. Now this is only called for
isKHTML, and there is a direct call to run() otherwise. This for some reason
gave the recursion error for me. When I reverted this line and use the
timeout version, the recursion error disappeared. I am not sure about the
big picture of what's going on, but that gave me a dirty fix for now.

- Samyem



samyem wrote:
> 
> Same here. I am getting too much recursion in places I didn't have problem
> earlier as well. Looking at the generated source, it is clear that the
> java script gets included more than once, not just once in the header.
> 
> - Samyem
> 
> 
> Pierre-Yves Saumont wrote:
>> 
>> I am afraid there is still a problem. I tested the fix in the quickstart 
>> I had made and it worked fine. However, in my application, selecting a 
>> date in the datepicker cause a Javascript error. FF reports this error
>> as:
>> 
>> Erreur : too much recursion
>> Fichier source : 
>> http://localhost:8080/ceagrap/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
>> Ligne : 1796
>> 
>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>> Date.prototype.setFullYear = function(y) {
>>var d = new Date(this); <<< line 1796
>>d.__msh_oldSetFullYear(y);
>>if (d.getMonth() != this.getMonth())
>>  this.setDate(28);
>>this.__msh_oldSetFullYear(y);
>> };
>> 
>> In IE6, the error message is "not enough stack space". The same line 
>> number is reported, but the next line is highlighted:
>> 
>> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
>> Date.prototype.setFullYear = function(y) {
>>var d = new Date(this);
>>d.__msh_oldSetFullYear(y); <<< line 1796
>>if (d.getMonth() != this.getMonth())
>>  this.setDate(28);
>>this.__msh_oldSetFullYear(y);
>> };
>> 
>> If I reload the page, the error disapears.
>> 
>> Pierre-Yves
>> 
>> 
>> Matej Knopp a ?crit :
>>> Thanks for fixed files, I've already commited those.
>>> 
>>> -Matej
>>> 
>>> Pierre-Yves Saumont wrote:
 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 = , 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 

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

[samyem]

Same here. I am getting too much recursion in places I didn't have problem
earlier as well. Looking at the generated source, it is clear that the java
script gets included more than once, not just once in the header.

- Samyem


Pierre-Yves Saumont wrote:
> 
> I am afraid there is still a problem. I tested the fix in the quickstart 
> I had made and it worked fine. However, in my application, selecting a 
> date in the datepicker cause a Javascript error. FF reports this error as:
> 
> Erreur : too much recursion
> Fichier source : 
> http://localhost:8080/ceagrap/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
> Ligne : 1796
> 
> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
> Date.prototype.setFullYear = function(y) {
>var d = new Date(this); <<< line 1796
>d.__msh_oldSetFullYear(y);
>if (d.getMonth() != this.getMonth())
>  this.setDate(28);
>this.__msh_oldSetFullYear(y);
> };
> 
> In IE6, the error message is "not enough stack space". The same line 
> number is reported, but the next line is highlighted:
> 
> Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
> Date.prototype.setFullYear = function(y) {
>var d = new Date(this);
>d.__msh_oldSetFullYear(y); <<< line 1796
>if (d.getMonth() != this.getMonth())
>  this.setDate(28);
>this.__msh_oldSetFullYear(y);
> };
> 
> If I reload the page, the error disapears.
> 
> Pierre-Yves
> 
> 
> Matej Knopp a ?crit :
>> Thanks for fixed files, I've already commited those.
>> 
>> -Matej
>> 
>> Pierre-Yves Saumont wrote:
>>> 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 = , 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 
>> 

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

[Pierre-Yves Saumont]

I am afraid there is still a problem. I tested the fix in the quickstart 
I had made and it worked fine. However, in my application, selecting a 
date in the datepicker cause a Javascript error. FF reports this error as:

Erreur : too much recursion
Fichier source : 
http://localhost:8080/ceagrap/app/resources/wicket.extensions.markup.html.datepicker.DatePicker/calendar.js
Ligne : 1796

Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
Date.prototype.setFullYear = function(y) {
   var d = new Date(this); <<< line 1796
   d.__msh_oldSetFullYear(y);
   if (d.getMonth() != this.getMonth())
 this.setDate(28);
   this.__msh_oldSetFullYear(y);
};

In IE6, the error message is "not enough stack space". The same line 
number is reported, but the next line is highlighted:

Date.prototype.__msh_oldSetFullYear = Date.prototype.setFullYear;
Date.prototype.setFullYear = function(y) {
   var d = new Date(this);
   d.__msh_oldSetFullYear(y); <<< line 1796
   if (d.getMonth() != this.getMonth())
 this.setDate(28);
   this.__msh_oldSetFullYear(y);
};

If I reload the page, the error disapears.

Pierre-Yves


Matej Knopp a écrit :
> Thanks for fixed files, I've already commited those.
> 
> -Matej
> 
> Pierre-Yves Saumont wrote:
>> 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 = , 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 
> 

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

[Matej Knopp]

Thanks for fixed files, I've already commited those.

-Matej

Pierre-Yves Saumont wrote:
> 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 = , 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 
 

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

[Pierre-Yves Saumont]

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 = , 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 

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

[Matej Knopp]

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 

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

[Pierre-Yves Saumont]

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 

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

[Matej Knopp]

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 

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

[Pierre-Yves Saumont]

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 

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

[Matej Knopp]

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 

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

[Matej Knopp]

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 

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

[Pierre-Yves Saumont]

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.php&p=sourceforge&CID=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

[Pierre-Yves Saumont]

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 

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

[Matej Knopp]

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 

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

[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.php&p=sourceforge&CID=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

[Pierre-Yves Saumont]

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.php&p=sourceforge&CID=DEVDEV
___
Wicket-user mailing list

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

[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. W

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

[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.php&p=sourceforge&CID=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

[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.php&p=sourceforge&CID=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

[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.php&p=sourceforge&CID=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

[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:
>>
>> ?
>> 
>> ?
>> > src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js">
>>  
>>
>> > id="wicket-ajax-debug-enable">]]>*/
>>
>> > src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js">
>>  
>>
>> > src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js">
>>  
>>
>> > src="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js">
>>  
>>
>> > href="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.Modal

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

[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:
>
> ?
> 
>   ?
>  src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js">
>  id="wicket-ajax-debug-enable">]]>*/
>
>  src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js">
>  src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js">
>  src="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js">
>  href="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css">
>  href="/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css">
> ]]>*/
> 
>
> Subsequent refreshes:
>
> 
>   ?
>   
> ]]>*/
> 
>
> 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 

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

[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:

 ?
 
?
 >>> src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js">
 >>> id="wicket-ajax-debug-enable">]]>*/

 >>> src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js">
 >>> src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js">
 >>> src="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js">
 >>> href="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css">
 >>> href="/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css">
 ]]>*/
 

 Subsequent refreshes:

 
?

 ]]>*/
 

 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
>>

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

[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:

 ?
 
?
 >>> src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js">
 >>> id="wicket-ajax-debug-enable">]]>*/

 >>> src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js">
 >>> src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js">
 >>> src="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js">
 >>> href="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css">
 >>> href="/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css">
 ]]>*/
 

 Subsequent refreshes:

 
?

 ]]>*/
 

 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:
>>
>> Er

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

[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:
>>>
>>> ?
>>> 
>>> ?
>>> >> src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js">
>>> >> id="wicket-ajax-debug-enable">]]>*/
>>>
>>> >> src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js">
>>> >> src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js">
>>> >> src="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js">
>>> >> href="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css">
>>> >> href="/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css">
>>> ]]>*/
>>> 
>>>
>>> Subsequent refreshes:
>>>
>>> 
>>> ?
>>> 
>>> ]]>*/
>>> 
>>>
>>> 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 an

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

[Matej Knopp]

Great! I can reproduce the problem now. Will look at it today. Thanks!

-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:
>>>
>>> ?
>>> 
>>> ?
>>> >> src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js">
>>> >> id="wicket-ajax-debug-enable">]]>*/
>>>
>>> >> src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js">
>>> >> src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js">
>>> >> src="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js">
>>> >> href="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css">
>>> >> href="/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css">
>>> ]]>*/
>>> 
>>>
>>> Subsequent refreshes:
>>>
>>> 
>>> ?
>>> 
>>> ]]>*/
>>> 
>>>
>>> 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 probl

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

[samyem]

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:
>> 
>> ?
>> 
>>  ?
>> > src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js">
>> > id="wicket-ajax-debug-enable">]]>*/
>> 
>> > src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js">
>> > src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js">
>> > src="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js">
>> > href="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css">
>> > href="/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css">
>> ]]>*/
>> 
>> 
>> Subsequent refreshes:
>> 
>> 
>>  ?
>>  
>> ]]>*/
>> 
>> 
>> 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 pan

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

[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 = , 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
 < 
 ---
  > 

 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 scr

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

[samyem]

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:
>> 
>> ?
>> 
>>  ?
>> > src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js">
>> > id="wicket-ajax-debug-enable">]]>*/
>> 
>> > src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js">
>> > src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js">
>> > src="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js">
>> > href="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css">
>> > href="/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css">
>> ]]>*/
>> 
>> 
>> Subsequent refreshes:
>> 
>> 
>>  ?
>>  
>> ]]>*/
>> 
>> 
>> 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 origina

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

[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
> >>> < 
> >>> ---
> >>>  > 
> >>>
> >>> 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]   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  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]
>  
>  > > 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 

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

[Matej Knopp]

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
>>> < 
>>> ---
>>>  > 
>>>
>>> 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] >
 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  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] 
 
 > > 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() {
>

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

[Matej Knopp]

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:
> 
> ?
> 
>   ?
>  src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js">
>  id="wicket-ajax-debug-enable">]]>*/
> 
>  src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug-drag.js">
>  src="/mm/app/resources/wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js">
>  src="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.js">
>  href="/mm/app/resources/wicket.extensions.ajax.markup.html.modal.ModalWindow/res/modal.css">
>  href="/mm/app/resources/com.wsi.mm.ui.commons.modaldialog.WsiModalWindow/modal.css">
> ]]>*/
> 
> 
> Subsequent refreshes:
> 
> 
>   ?
>   
> ]]>*/
> 
> 
> 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 
>

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

[samyem]

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:

?

?

]]>*/






]]>*/


Subsequent refreshes:


?

]]>*/


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 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 che

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

[samyem]

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, a

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

[samyem]

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 contribu

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

[samyem]

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 PROTECT

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

[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
>> < 
>> ---
>>  > 
>>
>> 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] >> 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  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] 
>>> 
>>> > > 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 

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

[Matej Knopp]

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
> < 
> ---
>  > 
> 
> 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] >
>> 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  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] 
>> 
>> > > 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,
>>  
>>
>>  > isVis

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

[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
< 
---
 > 

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] >
> 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  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] 
> 
> > > 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]]
>

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

[Matej Knopp]

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]  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).
>
> 

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

[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 an

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

[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]  >>> 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  section of DataPicker.
> >>>
> >>> Anyway, what can temporary help is to disable component render
> >>> check
> >>

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

[samyem]

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] >> 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  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]
>>> 
>>> > > wrote:
>>>  >
>>>  >
>>>  > I took the latest SVN code today and suddenly, I am
>>> getting
>>> the
>>>  >

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

[Matej Knopp]

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] >
 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  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] 
 > > 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:sid

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

[Matej Knopp]

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] >
>> 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  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] 
>> > > 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 =
>>  > sidePan

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

[Matej Knopp]

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] >
> 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  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] 
> > > 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() {
>  >  

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

[Pierre-Yves Saumont]

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] >
>>> 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  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] 
>>> > > 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,
>>>  > isVisible = true, isVersioned = false]]
>>>  >
>>>  > at wicket.Page.checkRendering (Page.java:1105)
>>>  > at wicket.Page.endComponentRender(Page.java:431)
>>>  > at
>>>  >
>>>
>>> wicket.aj

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

[samyem]

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] >
 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  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] 
 > > 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:

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

[Matej Knopp]

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] >
>>> 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  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] 
>>> > > 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 =

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

[Eelco Hillenius]

Dynamic addition of javascript and css through header contributions
does work for most cases. I'm using it on a daily basis, and never
have problems with it. I'm afraid we ran into a corner case here.

Eelco


On 9/23/06, samyem <[EMAIL PROTECTED]> 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] >
> >> 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  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] 
> >> > > 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,
> >>  > isVisible = true, isVersioned = false]]
> >>  >
> >>  

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

[samyem]

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] >
>> 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  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] 
>> > > 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,
>>  > isVisible = true, isVersioned = false]]
>>  >
>>  > at wicket.Page.checkRendering (Page.java:1105)
>>  > at wicket.Page.endComponentRender(Page.java:431)
>>  > at
>>  >
>>
>> wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:467)
>>  > at wicket.ajax.AjaxRequestTarget.respond
>>  > (AjaxRequestTarget.java:353)
>>  > at
>>  >
>>
>> wicket.request.compound.DefaultRespons

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

[Matej Knopp]

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] > 
> 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  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] 
> > > 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,
>  > isVisible = true, isVersioned = false]]
>  >
>  > at wicket.Page.checkRendering (Page.java:1105)
>  > at wicket.Page.endComponentRender(Page.java:431)
>  > at
>  >
> wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:467)
>  > at wicket.ajax.AjaxRequestTarget.respond
>  > (AjaxRequestTarget.java:353)
>  > at
>  >
> 
> wicket.request.compound.DefaultResponseStrategy.respond(DefaultResponseStrategy.java:49)
>  > at
>  >
> wicket.request.compound.AbstractCompoundRequestCycleProcessor.respond
>  > (AbstractCompoundRequestCycleProcessor.java:66)
>  > at
>  >
> wicket.RequestCycle.doProcessEventsAndRespond(RequestCycle.java:868)
>  > at
>  > wicket.RequestCycle.processEventsAndRespond
> (RequestCycle.java:900)
>  >   

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

[Igor Vaynberg]

i thought you _were_ working on the component use check and ajax target stuff?-IgorOn 9/22/06, Matej Knopp <
[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 elementsfrom DOM).This is something completely different, it's related to the componentrendered check. That's not my domain. I believe the problem are
components in  section of DataPicker.Anyway, what can temporary help is to disable component render check inappication settings. Juergen?-MatejIgor Vaynberg wrote:> matej was working to fix this, i thought he did matej?
>> -Igor>>> On 9/21/06, *samyem* <[EMAIL PROTECTED] [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._javascript_Reference,> 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._javascript_Reference
,> 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._javascript_Reference,> 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,> isVisible = true, isVersioned = false]]>> at wicket.Page.checkRendering
(Page.java:1105)> at wicket.Page.endComponentRender(Page.java:431)> at> wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:467)> at wicket.ajax.AjaxRequestTarget.respond
> (AjaxRequestTarget.java:353)> at> wicket.request.compound.DefaultResponseStrategy.respond(DefaultResponseStrategy.java:49)> at> wicket.request.compound.AbstractCompoundRequestCycleProcessor.respond
> (AbstractCompoundRequestCycleProcessor.java:66)> at> wicket.RequestCycle.doProcessEventsAndRespond(RequestCycle.java:868)> at> wicket.RequestCycle.processEventsAndRespond
(RequestCycle.java:900)> at wicket.RequestCycle.step(RequestCycle.java:976)> at wicket.RequestCycle.steps(RequestCycle.java:1050)> at wicket.RequestCycle.request(RequestCycle.java
:454)> at wicket.protocol.http.WicketServlet.doGet> (WicketServlet.java:217)> at> wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:260)> at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:760)> at javax.servlet.http.HttpServlet.service (HttpServlet.java:853)> at> org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:358)> at> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)> at> org.mortbay.jetty.servlet.ServletHandler.handle
(ServletHandler.java:567)> at org.mortbay.http.HttpContext.handle(HttpContext.java:1807)> at> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java
> :525)> at org.mortbay.http.HttpContext.handle(HttpContext.java:1757)> at org.mortbay.http.HttpServer.service(HttpServer.java:879)> at> org.mortbay.http.HttpConnection.service
(HttpConnection.java :790)> 

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

[Matej Knopp]

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  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]  > 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,
> isVisible = true, isVersioned = false]]
> 
> at wicket.Page.checkRendering(Page.java:1105)
> at wicket.Page.endComponentRender(Page.java:431)
> at
> wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:467)
> at wicket.ajax.AjaxRequestTarget.respond
> (AjaxRequestTarget.java:353)
> at
> 
> wicket.request.compound.DefaultResponseStrategy.respond(DefaultResponseStrategy.java:49)
> at
> wicket.request.compound.AbstractCompoundRequestCycleProcessor.respond
> (AbstractCompoundRequestCycleProcessor.java:66)
> at
> wicket.RequestCycle.doProcessEventsAndRespond(RequestCycle.java:868)
> at
> wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:900)
> at wicket.RequestCycle.step(RequestCycle.java:976)
> at wicket.RequestCycle.steps(RequestCycle.java:1050)
> at wicket.RequestCycle.request(RequestCycle.java:454)
> at wicket.protocol.http.WicketServlet.doGet
> (WicketServlet.java:217)
> at
> wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:260)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
> at javax.servlet.http.HttpServlet.service (HttpServlet.java:853)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358)
> at
> 
> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1807)
> at
> 
> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java
> :525)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1757)
> at org.mortbay.http.HttpServer.service(HttpServer.java:879)
> at
> org.mortbay.http.HttpConnection.service(HttpConnection.java :790)
> at
> 

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

[Igor Vaynberg]

matej was working to fix this, i thought he did matej?-IgorOn 9/21/06, samyem <[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 whileresponding 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 toreference 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._javascript_Reference,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._javascript_Reference,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._javascript_Reference,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,isVisible = true, isVersioned = false]]at 
wicket.Page.checkRendering(Page.java:1105)at wicket.Page.endComponentRender(Page.java:431)atwicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:467)at wicket.ajax.AjaxRequestTarget.respond
(AjaxRequestTarget.java:353)atwicket.request.compound.DefaultResponseStrategy.respond(DefaultResponseStrategy.java:49)atwicket.request.compound.AbstractCompoundRequestCycleProcessor.respond
(AbstractCompoundRequestCycleProcessor.java:66)at wicket.RequestCycle.doProcessEventsAndRespond(RequestCycle.java:868)at wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:900)at 
wicket.RequestCycle.step(RequestCycle.java:976)at wicket.RequestCycle.steps(RequestCycle.java:1050)at wicket.RequestCycle.request(RequestCycle.java:454)at wicket.protocol.http.WicketServlet.doGet
(WicketServlet.java:217)at wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:260)at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358)atorg.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)at org.mortbay.http.HttpContext.handle(HttpContext.java:1807)atorg.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java
:525)at org.mortbay.http.HttpContext.handle(HttpContext.java:1757)at org.mortbay.http.HttpServer.service(HttpServer.java:879)at org.mortbay.http.HttpConnection.service(HttpConnection.java
:790)at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:961)at org.mortbay.http.HttpConnection.handle(HttpConnection.java:807)atorg.mortbay.http.SocketListener.handleConnection
(SocketListener.java:218)at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:300)at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:511)Is there anything I can do to get rid of this error? Or is it a wicket bug?
--View this message in context: http://www.nabble.com/ajax-refresh-on-date-picker-tf2314518.html#a6436806Sent from the Wicket - User mailing list archive at 
Nabble.com.-Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cashhttp://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sou

[Wicket-user] ajax refresh on date picker

[samyem]

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,
isVisible = true, isVersioned = false]]

at wicket.Page.checkRendering(Page.java:1105)
at wicket.Page.endComponentRender(Page.java:431)
at
wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:467)
at wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:353)
at
wicket.request.compound.DefaultResponseStrategy.respond(DefaultResponseStrategy.java:49)
at
wicket.request.compound.AbstractCompoundRequestCycleProcessor.respond(AbstractCompoundRequestCycleProcessor.java:66)
at wicket.RequestCycle.doProcessEventsAndRespond(RequestCycle.java:868)
at wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:900)
at wicket.RequestCycle.step(RequestCycle.java:976)
at wicket.RequestCycle.steps(RequestCycle.java:1050)
at wicket.RequestCycle.request(RequestCycle.java:454)
at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:217)
at wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:260)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1807)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1757)
at org.mortbay.http.HttpServer.service(HttpServer.java:879)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:790)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:961)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:807)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:300)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:511)

Is there anything I can do to get rid of this error? Or is it a wicket bug?
-- 
View this message in context: 
http://www.nabble.com/ajax-refresh-on-date-picker-tf2314518.html#a6436806
Sent from the Wicket - User mailing list archive at Nabble.com.


-
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.php&p=sourceforge&CID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user