Re: IndicatingAjaxButton (Doesn't display indicator in Internet Explorer)

2011-01-11 Thread Wojciech Roczniak
Hi I had the same problem. There is workaround that work for me. I just moved submit link outside the form. Beside I create jira ticket for it: https://issues.apache.org/jira/browse/WICKET-3321 best regards, Wojciech Roczniak W dniu 07.01.2011 21:35, mzem...@osc.state.ny.us pisze: This

Re: Page content sends twice in response to GET when redirecting after POST

2011-01-11 Thread Johan Compagner
works fine for me to 2011/1/10 Igor Vaynberg igor.vaynb...@gmail.com: really strange because it doesnt happen to me: http://pastebin.com/fe1pjZjy -igor 2011/1/9 Marcin Zajączkowski msz...@wp.pl: On 2011-01-09 22:00, Marcin Zajączkowski wrote: Hi, Following some problems with page

check for component visibility on BehaviorRequestTarget introduced on 1.4.14

2011-01-11 Thread Ernesto Reinaldo Barreiro
Hi All, On [1] we are providing an integration with jqgrid that uses the trick of having and invisible panel that is used to stream back data to the data grid. We needed this to be a panel in order to allow wicket components to be used for grid cells. This little trick was working fine till

RestartResponseAtInterceptPage

2011-01-11 Thread Eike Kettner
Hi For wicket 1.5.x I created a custom RequestHandler that also renders pages. Now I like to use this handler in RestartResponseAtInterceptPageException. But the class only accepts a Page, and then schedules a RenderingPageRequestHandler. Is there any reason why not having a custom handler be the

Re: check for component visibility on BehaviorRequestTarget introduced on 1.4.14

2011-01-11 Thread Pedro Santos
Hi Ernesto, the main concern is security, it is natural to expect that actions coded in behaviours will not get invoked when its components are disabled. Actually we treated this unexpected disabled behavior call as a bug since we discovered it[1]. On a side note, in Wicket 1.4 the Behavior needs

Re: check for component visibility on BehaviorRequestTarget introduced on 1.4.14

2011-01-11 Thread Martin Grigorov
I think for this particular case you may use zero size div which is positioned out of the visible viewport. So it is still visible in Wicket world but not visible for the user. On Tue, Jan 11, 2011 at 1:39 PM, Pedro Santos pedros...@gmail.com wrote: Hi Ernesto, the main concern is security, it

Re: RestartResponseAtInterceptPage

2011-01-11 Thread Martin Grigorov
Hi, I guess it accepts a Page because this is what the class name states: RestartResponseAtIntercept*Page*Exception But looking at the source it should be quite easy to create your own Exception which accepts IRequestHandler and does the same. If you think it should be in the framework then file

Re: check for component visibility on BehaviorRequestTarget introduced on 1.4.14

2011-01-11 Thread Ernesto Reinaldo Barreiro
Pedro, Thanks for you answer! Yes I saw IIgnoreDisabledComponentBehavior but using it introduces a dependency on version 1.4.14 which might force users to up-grade wicket version if they want to use trunk. Maybe, I will go for attaching the behavior to a visible component... Thanks again.

Re: check for component visibility on BehaviorRequestTarget introduced on 1.4.14

2011-01-11 Thread Ernesto Reinaldo Barreiro
Martin, I was trying to avoid rendering the same data twice: that's why I was making the panel that generates grid's contents invisible. One easy solution could be make it server side visible but client side invisible (e.g. display: none). Thank for your answer. Ernesto On Tue, Jan 11, 2011 at

Re: RestartResponseAtInterceptPage

2011-01-11 Thread Eike Kettner
Hi Martin, thank you for your response. Of course I was expecting RestartResponseAtIntercept*Page*Exception to accept a Page, while looking for something like RestartResponseAtInterceptHandlerException ;-) I created my own Exception that accepts a request handler. I subclassed ResetResponseEx as

ModalWindow and z-index

2011-01-11 Thread hok
Hello, I'm trying to create a dijit tooltip (http://docs.dojocampus.org/dijit/Tooltip) on a Modal window. However the tooltip is displayed behind it (and behind the mask also). I checked modal.css and modal.js and noticed the following: the mask that disables everything on the page has a z-index

Re: AbstractAjaxTimerBehavior and getPreconditionScript

2011-01-11 Thread Nelson Segura
Can anyone provide an answer whether returning false in the getPreconditionScript() method is supposed to stop the AJAX timer behaviour, or should I be looking for a bug? -Nelson

Re: AbstractAjaxTimerBehavior and getPreconditionScript

2011-01-11 Thread Igor Vaynberg
this is not a bug. if precondition check fails the server call is not made. it is the server calls that schedules the next firing of the timer, so no server call no timer so to speak. you can write your own version of the timer behavior that works the way you want. -igor On Tue, Jan 11, 2011 at

Re: AbstractAjaxTimerBehavior and getPreconditionScript

2011-01-11 Thread Nelson Segura
Thanks Igor, that is exactly what I wanted to know! -Nelson On Tue, Jan 11, 2011 at 4:37 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: this is not a bug. if precondition check fails the server call is not made. it is the server calls that schedules the next firing of the timer, so no server