Re: AbstractAjaxTimerBehavior and getPreconditionScript
Thanks Igor, that is exactly what I wanted to know! -Nelson On Tue, Jan 11, 2011 at 4:37 PM, Igor Vaynberg wrote: > 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 4:32 PM, Nelson Segura wrote: > > 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 > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: AbstractAjaxTimerBehavior and getPreconditionScript
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 4:32 PM, Nelson Segura wrote: > 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 > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AbstractAjaxTimerBehavior and getPreconditionScript
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
ModalWindow and z-index
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 2 and the modal window itself has a z-index 20001 (I assume that by this the window stays on top of the mask). I tried to set a much larger z-index value to the tooltip, but it's still displayed behind the mask and the window. Also tried a simple tag with larger z-index value on a random place of the page (outside the window) but it's still hidden behind the mask. Is there a way to display something in front of the window and the mask while the window is opened? Thanks in advance. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/ModalWindow-and-z-index-tp3209922p3209922.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: RestartResponseAtInterceptPage
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 well, which schedules my RequestHandler. But then I don't know how to make Component.continueToOriginalDestination() work again. RestartRespAtInterceptPageEx uses a class "InterceptData" to save the original request url in the session. Component.continueToOringinalDestination() calls the same named static method of RestartResponseAtInterceptPageExc. So I just used the class InterceptData the same way, but its javadoc comment states, that it's not part of wickets public api and will be package private in near future. So I don't know where to plugin my code. Regards, Eike On [Tue, 11.01.2011 14:15], Martin Grigorov wrote: > 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 a ticket in Jira for > improvement. > > On Tue, Jan 11, 2011 at 1:09 PM, Eike Kettner wrote: > > > 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 target for an intercept > > request? I used the InterceptData class which is public for now and > > found it working ok. But I'm not sure if I miss something? I'm also > > remembering that it also did not work in wicket 1.4.x to set a custom > > RequestTarget to use for RestartResponseAtInterceptPageException. > > > > Thanks in advance for any help! > > Regards, > > Eike > > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > -- email: e...@eknet.org https://www.eknet.org pgp: 481161A0 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: check for component visibility on BehaviorRequestTarget introduced on 1.4.14
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 2:02 PM, Martin Grigorov wrote:
> I think for this particular case you may use zero size 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 wrote:
>
>> 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 to implement the
>> IIgnoreDisabledComponentBehavi
>> or interface in order work on disabled components, and in 1.5 return true
>> on
>> method: Behavior#canCallListenerInterface
>>
>> 1 - https://issues.apache.org/jira/browse/WICKET-3098
>>
>>
>> On Tue, Jan 11, 2011 at 10:05 AM, Ernesto Reinaldo Barreiro <
>> reier...@gmail.com> wrote:
>>
>> > 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 wicket 1.4.13 but on wicket 1.4.14 the following check was
>> > added to the processEvents method
>> >
>> > if (!component.isVisibleInHierarchy() ||
>> > (!(behaviorListener instanceof
>> > IIgnoreDisabledComponentBehavior) &&
>> > !component.isEnabledInHierarchy()))
>> > {
>> > // ignore this request
>> > logger.warn("component not enabled or visible;
>> > ignoring call.
>> > Component: {}", component);
>> > if (requestCycle.getRequest() instanceof
>> WebRequest
>> > &&
>> >
>> > ((WebRequest)requestCycle.getRequest()).isAjax())
>> > {
>> > throw new AbortException();
>> > }
>> > return;
>> > }
>> >
>> > So, the trick we used to stream data back is no longer working (as a
>> > user just discovered a few minutes ago, see [2]). Of course, I
>> > could/will try to find other ways to do it... But I would like to ask
>> > why this check was introduced? As this might break existing
>> > applications...
>> >
>> > Regards,
>> >
>> > Ernesto
>> >
>> > 1-http://code.google.com/p/wiquery-plugins/
>> > 2-http://code.google.com/p/wiquery-plugins/issues/detail?id=19
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >
>> >
>>
>>
>> --
>> Pedro Henrique Oliveira dos Santos
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: check for component visibility on BehaviorRequestTarget introduced on 1.4.14
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.
Regards,
Ernesto
On Tue, Jan 11, 2011 at 1:39 PM, Pedro Santos wrote:
> 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 to implement the
> IIgnoreDisabledComponentBehavi
> or interface in order work on disabled components, and in 1.5 return true on
> method: Behavior#canCallListenerInterface
>
> 1 - https://issues.apache.org/jira/browse/WICKET-3098
>
>
> On Tue, Jan 11, 2011 at 10:05 AM, Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
>> 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 wicket 1.4.13 but on wicket 1.4.14 the following check was
>> added to the processEvents method
>>
>> if (!component.isVisibleInHierarchy() ||
>> (!(behaviorListener instanceof
>> IIgnoreDisabledComponentBehavior) &&
>> !component.isEnabledInHierarchy()))
>> {
>> // ignore this request
>> logger.warn("component not enabled or visible;
>> ignoring call.
>> Component: {}", component);
>> if (requestCycle.getRequest() instanceof WebRequest
>> &&
>>
>> ((WebRequest)requestCycle.getRequest()).isAjax())
>> {
>> throw new AbortException();
>> }
>> return;
>> }
>>
>> So, the trick we used to stream data back is no longer working (as a
>> user just discovered a few minutes ago, see [2]). Of course, I
>> could/will try to find other ways to do it... But I would like to ask
>> why this check was introduced? As this might break existing
>> applications...
>>
>> Regards,
>>
>> Ernesto
>>
>> 1-http://code.google.com/p/wiquery-plugins/
>> 2-http://code.google.com/p/wiquery-plugins/issues/detail?id=19
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
> --
> Pedro Henrique Oliveira dos Santos
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: RestartResponseAtInterceptPage
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 a ticket in Jira for improvement. On Tue, Jan 11, 2011 at 1:09 PM, Eike Kettner wrote: > 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 target for an intercept > request? I used the InterceptData class which is public for now and > found it working ok. But I'm not sure if I miss something? I'm also > remembering that it also did not work in wicket 1.4.x to set a custom > RequestTarget to use for RestartResponseAtInterceptPageException. > > Thanks in advance for any help! > Regards, > Eike > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: check for component visibility on BehaviorRequestTarget introduced on 1.4.14
I think for this particular case you may use zero size 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 wrote:
> 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 to implement the
> IIgnoreDisabledComponentBehavi
> or interface in order work on disabled components, and in 1.5 return true
> on
> method: Behavior#canCallListenerInterface
>
> 1 - https://issues.apache.org/jira/browse/WICKET-3098
>
>
> On Tue, Jan 11, 2011 at 10:05 AM, Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
> > 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 wicket 1.4.13 but on wicket 1.4.14 the following check was
> > added to the processEvents method
> >
> > if (!component.isVisibleInHierarchy() ||
> >(!(behaviorListener instanceof
> > IIgnoreDisabledComponentBehavior) &&
> > !component.isEnabledInHierarchy()))
> >{
> >// ignore this request
> >logger.warn("component not enabled or visible;
> > ignoring call.
> > Component: {}", component);
> >if (requestCycle.getRequest() instanceof
> WebRequest
> > &&
> >
> > ((WebRequest)requestCycle.getRequest()).isAjax())
> >{
> >throw new AbortException();
> >}
> >return;
> >}
> >
> > So, the trick we used to stream data back is no longer working (as a
> > user just discovered a few minutes ago, see [2]). Of course, I
> > could/will try to find other ways to do it... But I would like to ask
> > why this check was introduced? As this might break existing
> > applications...
> >
> > Regards,
> >
> > Ernesto
> >
> > 1-http://code.google.com/p/wiquery-plugins/
> > 2-http://code.google.com/p/wiquery-plugins/issues/detail?id=19
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>
>
> --
> Pedro Henrique Oliveira dos Santos
>
Re: check for component visibility on BehaviorRequestTarget introduced on 1.4.14
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 to implement the
IIgnoreDisabledComponentBehavi
or interface in order work on disabled components, and in 1.5 return true on
method: Behavior#canCallListenerInterface
1 - https://issues.apache.org/jira/browse/WICKET-3098
On Tue, Jan 11, 2011 at 10:05 AM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:
> 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 wicket 1.4.13 but on wicket 1.4.14 the following check was
> added to the processEvents method
>
> if (!component.isVisibleInHierarchy() ||
>(!(behaviorListener instanceof
> IIgnoreDisabledComponentBehavior) &&
> !component.isEnabledInHierarchy()))
>{
>// ignore this request
>logger.warn("component not enabled or visible;
> ignoring call.
> Component: {}", component);
>if (requestCycle.getRequest() instanceof WebRequest
> &&
>
> ((WebRequest)requestCycle.getRequest()).isAjax())
>{
>throw new AbortException();
>}
>return;
>}
>
> So, the trick we used to stream data back is no longer working (as a
> user just discovered a few minutes ago, see [2]). Of course, I
> could/will try to find other ways to do it... But I would like to ask
> why this check was introduced? As this might break existing
> applications...
>
> Regards,
>
> Ernesto
>
> 1-http://code.google.com/p/wiquery-plugins/
> 2-http://code.google.com/p/wiquery-plugins/issues/detail?id=19
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
--
Pedro Henrique Oliveira dos Santos
RestartResponseAtInterceptPage
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 target for an intercept request? I used the InterceptData class which is public for now and found it working ok. But I'm not sure if I miss something? I'm also remembering that it also did not work in wicket 1.4.x to set a custom RequestTarget to use for RestartResponseAtInterceptPageException. Thanks in advance for any help! Regards, Eike - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
check for component visibility on BehaviorRequestTarget introduced on 1.4.14
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 wicket 1.4.13 but on wicket 1.4.14 the following check was
added to the processEvents method
if (!component.isVisibleInHierarchy() ||
(!(behaviorListener instanceof
IIgnoreDisabledComponentBehavior) &&
!component.isEnabledInHierarchy()))
{
// ignore this request
logger.warn("component not enabled or visible; ignoring
call.
Component: {}", component);
if (requestCycle.getRequest() instanceof WebRequest &&
((WebRequest)requestCycle.getRequest()).isAjax())
{
throw new AbortException();
}
return;
}
So, the trick we used to stream data back is no longer working (as a
user just discovered a few minutes ago, see [2]). Of course, I
could/will try to find other ways to do it... But I would like to ask
why this check was introduced? As this might break existing
applications...
Regards,
Ernesto
1-http://code.google.com/p/wiquery-plugins/
2-http://code.google.com/p/wiquery-plugins/issues/detail?id=19
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Page content sends twice in response to GET when redirecting after POST
works fine for me to 2011/1/10 Igor Vaynberg : > really strange because it doesnt happen to me: > > http://pastebin.com/fe1pjZjy > > -igor > > > > 2011/1/9 Marcin Zajączkowski : >> On 2011-01-09 22:00, Marcin Zajączkowski wrote: >>> Hi, >>> >>> >>> Following some problems with page rendering in my application after post >>> a form I've noticed that when redirect after post strategy is used (both >>> REDIRECT_TO_BUFFER and REDIRECT_TO_RENDER) page content is duplicated in >>> a response to GET (after 302 Moved Temporarily on POST). I thought it's >>> a problem with a configuration of my application (I'm playing with >>> AppFuse as a base), but in the first Wicket example with form submission >>> found on the web [1] it occurs as well. >>> >>> Tested it with Wicket 1.4.15. Response snipset bellow. Full response as >>> attachment. I can be easily reproduced using "forminput" example (just >> >> Full response: http://pastebin.com/jQTRExjh >> >> >> Marcin >> >> >>> submit form). >>> >>> [1] - http://www.wicketstuff.org/wicket14/forminput/ >>> >>> >>> I don't see a reason for that behavior, but I'm new to Wicket, so maybe >>> it's a feature? >>> >>> >>> >>> >>> Wicket Examples - forminput >>> >>> >> href="resources/org.apache.wicket.devutils.debugbar.DebugBar/wicket-debugbar.css;jsessionid=E218340AA4A63320747D134AA1985E7F" >>> /> >>> >> src="resources/org.apache.wicket.devutils.debugbar.DebugBar/wicket-debugbar.js;jsessionid=E218340AA4A63320747D134AA1985E7F"> >>> >>> >>> >>> >> target="_top">>> class="wicketDebugBar"> >>> >> onclick="wicketDebugBarCollapse();">>> src="resources/org.apache.wicket.devutils.debugbar.DebugBar/ >>> (...) >>> your favorite >>> sites >>> >> multiple="multiple" >>> size="3"> >>> The Server Side <--- seems to be cut off >>> <-- one again starting from head >>> Wicket Examples - forminput >>> >>> >> href="resources/org.apache.wicket.devutils.debugbar.DebugBar/wicket-debugbar.css;jsessionid=E218340AA4A63320747D134AA1985E7F" >>> /> >>> >> src="resources/org.apache.wicket.devutils.debugbar.DebugBar/wicket-debugbar.js;jsessionid=E218340AA4A63320747D134AA1985E7F"> >>> >>> >>> >>> >> target="_top">>> class="wicketDebugBar"> >>> >> onclick="wicketDebugBarCollapse();">>> src="resources/org.apache.wicket.devutils.debugbar.DebugBar/ >>> (...) >>> The Server Side <--- second time not cut off >>> Java Lobby >>> Java.Net >>> (...) >>> >>> >>> >>> >>> >>> Regards >>> Marcin >>> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: IndicatingAjaxButton (Doesn't display indicator in Internet Explorer)
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 problem still exists in Wicket 1.14.15. IndicatingAjaxButton does not show the busy indicator in IE, it does work in Firefox. IndicatingAjaxLink does show the indicator in IE. - Forwarded by Matthew Zemeck/ADM/NYSOSC on 01/07/2011 03:32 PM - From: mzem...@osc.state.ny.us To: users@wicket.apache.org Date: 11/30/2010 04:23 PM Subject:Re: IndicatingAjaxButton (Doesn't display indicator in Internet Explorer) +1 Yes I have seen this as well... From: "Corbin, James" To: "users@wicket.apache.org" Date: 11/30/2010 04:07 PM Subject:IndicatingAjaxButton (Doesn't display indicator in Internet Explorer) I recently noticed that the IndicatingAjaxButton no longer appears to render the asterix in Internet Explorer (all versions including 6,7 and 8). I noticed this after moving to Wicket Version 1.4.13. Has anybody seen this behavior with ajax indicators not displaying in IE? J.D. J.D. Corbin | IQNavigator | Senior Software Engineer Office: (303) 563-1503 * Mobile: (303) 912-0958 * jcor...@iqnavigator.com< mailto:y...@iqnavigator.com> 6465 Greenwood Plaza Blvd. * Suite 800 * Centennial, CO * 80111 * USA This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Notice: This communication, including any attachments, is intended solely for the use of the individual or entity to which it is addressed. This communication may contain information that is protected from disclosure under State and/or Federal law. Please notify the sender immediately if you have received this communication in error and delete this email from your system. If you are not the intended recipient, you are requested not to disclose, copy, distribute or take any action in reliance on the contents of this information. Notice: This communication, including any attachments, is intended solely for the use of the individual or entity to which it is addressed. This communication may contain information that is protected from disclosure under State and/or Federal law. Please notify the sender immediately if you have received this communication in error and delete this email from your system. If you are not the intended recipient, you are requested not to disclose, copy, distribute or take any action in reliance on the contents of this information. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
