Re: IndicatorAware and BookmarkablePageLink
Hi,
BookmarkablePageLink unloads the current page and loads a new page.
As soon as the current page is unloaded the busy indicator stops working.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Oct 23, 2014 at 8:46 PM, msalman mohammad_sal...@yahoo.com wrote:
Hi,
We use SuckerfishMenuPanel for our menus and in it the links use
BookmarkablePageLinks. I need to make make some of the links (menu items)
IndicatorAware, i.e., show the whirling wheel, when clicked.
I tried some thing like following:
private class LinkIndicatingAwareBehaviour extends AjaxEventBehavior
implements IAjaxIndicatorAware
{
AjaxIndicatorAppender indicator;
public LinkIndicatingAwareBehaviour(
String event,
Link link)
{
super(event);
this.indicator = new AjaxIndicatorAppender();
link.add(indicator);
}
@Override
public String getAjaxIndicatorMarkupId()
{
return indicator.getMarkupId();
}
@Override
protected void onEvent(AjaxRequestTarget target)
{
// please see BookmarkablePageLink.onClick()
}
}
This shows the busy indicator for a very short while and does not cover the
time when the page is getting ready to be shown. So basically of no use.
can some one please suggest something?
Thanks.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/IndicatorAware-and-BookmarkablePageLink-tp4668056.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: Page Parameters logging
Hi, Maybe you want to encrypt the value of this special parameter ?! It will be a never ending story to patch all places where this parameter may leak. See CryptoMapper for inspiration how to encrypt and decrypt strings. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Oct 23, 2014 at 7:25 PM, shareski samshare...@gmail.com wrote: We have a secret parameter that we don't want to be logged in a stack trace or anything. Right now we're using a custom IRequestHandler to intercept the exception but I'm wondering if there's a more elegant way to do this. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Page-Parameters-logging-tp4668053.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: Lock timeout per page class
Hi Guillaume,
Sorry for not thinking more carefully about this the first time!
I'm afraid it is not possible to do it the way I suggested.
PageAccessSynchronizer is the entry point to start using a page and it
works only with pageId!
Here is a new hackish approach:
Store pageId - pageClassName map in the Session. Then when
PageAccessSynchronizer is requested to lock a page by id use that id to
resolve the class name and to decide what timeout to use.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet guillaume.s...@gmail.com
wrote:
Hi Martin,
On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov mgrigo...@apache.org
wrote:
I'd like to avoid moving the logic that gets the timeout from
Session.PageAccessSynchronizerProvider to PageAccessSynchronizer because
this way it will use Application.get() everytime and most apps don't need
to pay for this.
A way to make it possible for you is to remove the 'final'
from org.apache.wicket.Session#getPageManager and introduce overridable
PageAccessSynchronizer#getTimeout(). This way you can use your own
PageAccessSynchronizer.
http://pastie.org/9667070
After a few experiments, here I am!
So, it mostly works: I thought it would be better to add something like:
protected IProviderPageAccessSynchronizer
newPageAccessSynchronizerProvider()
{
return new PageAccessSynchronizerProvider();
}
in Session and call it from the constructor instead of removing the
final so I did that in my code.
It works pretty well BUT I haven't found a way to get the page class
in getTimeout without having the risk to trigger a resolvePageInstance
which will try to lock and then call getTimeout leading to a wonderful
stack overflow exception when dealing with
ListenerInterfaceRequestHandler.
Obviously (...) what interests me the most is the getTimeout in
ListenerInterfaceRequestHandler as it's often actions on buttons which
are long to run.
Here is what I have in mind for my Session class:
https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
I must admit that an advice would be welcome as I wouldn't like to
have stack overflow errors popping out in weird edge cases.
Thanks!
--
Guillaume
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Lock timeout per page class
Hi Martin,
Yeah, I thought about that too but I'm not sure of the best place to
build the pageId - pageClassName map. Any advice about this?
Once I'll get this working, I'll build a PR for the few changes I made
in Wicket (based on what you proposed earlier). Would be nice to have
them in 6.18.
On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov mgrigo...@apache.org wrote:
Hi Guillaume,
Sorry for not thinking more carefully about this the first time!
I'm afraid it is not possible to do it the way I suggested.
PageAccessSynchronizer is the entry point to start using a page and it
works only with pageId!
Here is a new hackish approach:
Store pageId - pageClassName map in the Session. Then when
PageAccessSynchronizer is requested to lock a page by id use that id to
resolve the class name and to decide what timeout to use.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet guillaume.s...@gmail.com
wrote:
Hi Martin,
On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov mgrigo...@apache.org
wrote:
I'd like to avoid moving the logic that gets the timeout from
Session.PageAccessSynchronizerProvider to PageAccessSynchronizer because
this way it will use Application.get() everytime and most apps don't need
to pay for this.
A way to make it possible for you is to remove the 'final'
from org.apache.wicket.Session#getPageManager and introduce overridable
PageAccessSynchronizer#getTimeout(). This way you can use your own
PageAccessSynchronizer.
http://pastie.org/9667070
After a few experiments, here I am!
So, it mostly works: I thought it would be better to add something like:
protected IProviderPageAccessSynchronizer
newPageAccessSynchronizerProvider()
{
return new PageAccessSynchronizerProvider();
}
in Session and call it from the constructor instead of removing the
final so I did that in my code.
It works pretty well BUT I haven't found a way to get the page class
in getTimeout without having the risk to trigger a resolvePageInstance
which will try to lock and then call getTimeout leading to a wonderful
stack overflow exception when dealing with
ListenerInterfaceRequestHandler.
Obviously (...) what interests me the most is the getTimeout in
ListenerInterfaceRequestHandler as it's often actions on buttons which
are long to run.
Here is what I have in mind for my Session class:
https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
I must admit that an advice would be welcome as I wouldn't like to
have stack overflow errors popping out in weird edge cases.
Thanks!
--
Guillaume
-
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: Lock timeout per page class
If you have a base page then BasePage#onInitialize() should be a good place.
Or you could add the pageIds of the special/slow pages only in the map.
Otherwise you may use PageRequestHandlerTracker#getLastHandler in a custom
IRequestCycleListener#onDetach().
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Oct 24, 2014 at 10:11 AM, Guillaume Smet guillaume.s...@gmail.com
wrote:
Hi Martin,
Yeah, I thought about that too but I'm not sure of the best place to
build the pageId - pageClassName map. Any advice about this?
Once I'll get this working, I'll build a PR for the few changes I made
in Wicket (based on what you proposed earlier). Would be nice to have
them in 6.18.
On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi Guillaume,
Sorry for not thinking more carefully about this the first time!
I'm afraid it is not possible to do it the way I suggested.
PageAccessSynchronizer is the entry point to start using a page and it
works only with pageId!
Here is a new hackish approach:
Store pageId - pageClassName map in the Session. Then when
PageAccessSynchronizer is requested to lock a page by id use that id to
resolve the class name and to decide what timeout to use.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet
guillaume.s...@gmail.com
wrote:
Hi Martin,
On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov mgrigo...@apache.org
wrote:
I'd like to avoid moving the logic that gets the timeout from
Session.PageAccessSynchronizerProvider to PageAccessSynchronizer
because
this way it will use Application.get() everytime and most apps don't
need
to pay for this.
A way to make it possible for you is to remove the 'final'
from org.apache.wicket.Session#getPageManager and introduce
overridable
PageAccessSynchronizer#getTimeout(). This way you can use your own
PageAccessSynchronizer.
http://pastie.org/9667070
After a few experiments, here I am!
So, it mostly works: I thought it would be better to add something like:
protected IProviderPageAccessSynchronizer
newPageAccessSynchronizerProvider()
{
return new PageAccessSynchronizerProvider();
}
in Session and call it from the constructor instead of removing the
final so I did that in my code.
It works pretty well BUT I haven't found a way to get the page class
in getTimeout without having the risk to trigger a resolvePageInstance
which will try to lock and then call getTimeout leading to a wonderful
stack overflow exception when dealing with
ListenerInterfaceRequestHandler.
Obviously (...) what interests me the most is the getTimeout in
ListenerInterfaceRequestHandler as it's often actions on buttons which
are long to run.
Here is what I have in mind for my Session class:
https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
I must admit that an advice would be welcome as I wouldn't like to
have stack overflow errors popping out in weird edge cases.
Thanks!
--
Guillaume
-
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
KeyInSessionSunJceCryptFactory doesn't work in Wicket 6.0
Hi guys, in order to protect our portal before CSRF attacks we were using KeyInSessionSunJceCryptFactory as following: Application class: . . Where PostUrlCryptMapper was just simple filter class ensuring that just POST URLs will be encrypted: This was working perfectly in Wicket 1.5! But now we're migrating to Wicket 6.0 and this stopped working and I don't see any note in migration guide about this. I was debugging it and ListenerInterfaceRequestHandler doesn't even come into CryptoMapper which is why POST action URL still remains uncrypted I even tried the following code in Application class: Guys, the only URLs which wicket 6.0 is able to encrypt natively are the Resource URLs, which is pointless in my case Yes, I can tweak POST URL's in onUrlMapped in RequestCycle Listener for example, but I would rather prefer to stick with my previous solution Guys please, what is the prefered way of crypting URLs in Wicket 6.0 In order to prevent CSFR attacks... thanks in advance Tomas -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/KeyInSessionSunJceCryptFactory-doesn-t-work-in-Wicket-6-0-tp4668070.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: KeyInSessionSunJceCryptFactory doesn't work in Wicket 6.0
Hi, It has been fixed with https://issues.apache.org/jira/browse/WICKET-5326. Will be released with 6.18.0. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Oct 24, 2014 at 2:37 PM, tomask79 tomas.klou...@embedit.cz wrote: Hi guys, in order to protect our portal before CSRF attacks we were using KeyInSessionSunJceCryptFactory as following: Application class: . . Where PostUrlCryptMapper was just simple filter class ensuring that just POST URLs will be encrypted: This was working perfectly in Wicket 1.5! But now we're migrating to Wicket 6.0 and this stopped working and I don't see any note in migration guide about this. I was debugging it and ListenerInterfaceRequestHandler doesn't even come into CryptoMapper which is why POST action URL still remains uncrypted I even tried the following code in Application class: Guys, the only URLs which wicket 6.0 is able to encrypt natively are the Resource URLs, which is pointless in my case Yes, I can tweak POST URL's in onUrlMapped in RequestCycle Listener for example, but I would rather prefer to stick with my previous solution Guys please, what is the prefered way of crypting URLs in Wicket 6.0 In order to prevent CSFR attacks... thanks in advance Tomas -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/KeyInSessionSunJceCryptFactory-doesn-t-work-in-Wicket-6-0-tp4668070.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: KeyInSessionSunJceCryptFactory doesn't work in Wicket 6.0
Thanks a lot Martin for quick reply. Please when is the release date of 6.18? thanks and have a nice weekend T. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/KeyInSessionSunJceCryptFactory-doesn-t-work-in-Wicket-6-0-tp4668070p4668072.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: KeyInSessionSunJceCryptFactory doesn't work in Wicket 6.0
I'll ask our release manager to cut 6.18 next Friday. If the testing passes then it will be released around Nov 5. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Oct 24, 2014 at 3:21 PM, tomask79 tomas.klou...@embedit.cz wrote: Thanks a lot Martin for quick reply. Please when is the release date of 6.18? thanks and have a nice weekend T. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/KeyInSessionSunJceCryptFactory-doesn-t-work-in-Wicket-6-0-tp4668070p4668072.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: Page Parameters logging
Thanks, this is what I'm doing now, just wanted to make sure it was an ok idea. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Page-Parameters-logging-tp4668053p4668074.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: Page Parameters logging
Ya, this is definitely a band-aid fix, but the application is a bit of a Frankenstein's monster so encrypting the parameter everywhere it's used is a colossal task, though it's definitely the proper solution. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Page-Parameters-logging-tp4668053p4668075.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: IndicatorAware and BookmarkablePageLink
Hi Martin Thanks for your response. And yes this explains the behavior I have seen. Any way the busy indicator can be shown during the entire page unloading and unloading process? Thanks. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/IndicatorAware-and-BookmarkablePageLink-tp4668056p4668082.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
jquery DataTable + wicket Cannot bind a listener
Hi,
I'm using latest jquery DataTable with a ListView and in wicket:head of
the page, I initiate the DataTable:
$(function () {
$('.datatable_executed').dataTable({
'lengthChange': false,
'dom': 'topdoc-filterholdeript',
language: {info: _START_-_END_ of _TOTAL_},
aaSorting: [],
'iDisplayLength': 12
});
});
It all looks good, however because one of my columns contains AjaxLinks,
I get an error from my wicket debug window with the following:
Wicket.Ajax: Cannot bind a listener for event click on element
elementId because the element is not in the DOM
The thing is the links seem to actually work on the first page, but when
I click - to go to the next page the links don't work. Has anyone
experienced this before or have any idea how I can debug this?
Thanks, Jason
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: jquery DataTable + wicket Cannot bind a listener
I should add I'm using Wicket 6.17.
Thanks, Jason
On 10/24/14, 10:47 AM, Jason Novotny wrote:
Hi,
I'm using latest jquery DataTable with a ListView and in wicket:head
of the page, I initiate the DataTable:
$(function () {
$('.datatable_executed').dataTable({
'lengthChange': false,
'dom': 'topdoc-filterholdeript',
language: {info: _START_-_END_ of _TOTAL_},
aaSorting: [],
'iDisplayLength': 12
});
});
It all looks good, however because one of my columns contains
AjaxLinks, I get an error from my wicket debug window with the
following: Wicket.Ajax: Cannot bind a listener for event click on
element elementId because the element is not in the DOM
The thing is the links seem to actually work on the first page, but
when I click - to go to the next page the links don't work. Has
anyone experienced this before or have any idea how I can debug this?
Thanks, Jason
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Wicket error page runs twice
I have a requirement that when certain kinds of exceptions are thrown, I want to customize my exception error page. I stuffed the exception into the requestcycle and retrieve it in the page like so: Exception exception = getRequestCycle().getMetaData(ESPApplication.EXCEPTION_KEY); I watch through breakpoints or log statements and the exception is provided the first time through, but after it processes it, the error page runs a second time, this time with a null in that value. the result is that my error page is not getting what it needs, and renders without the needed info. Why would the error page run twice? I don't see any additional exceptions in the log, and the error page does render...it just renders as if the exception object were null. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-error-page-runs-twice-tp4668093.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: Wicket error page runs twice
Hi, It seems like the error page is being rendered after a redirect. That's why the request cycle is empty, because it is a new one. On Oct 25, 2014 1:42 AM, Entropy blmulholl...@gmail.com wrote: I have a requirement that when certain kinds of exceptions are thrown, I want to customize my exception error page. I stuffed the exception into the requestcycle and retrieve it in the page like so: Exception exception = getRequestCycle().getMetaData(ESPApplication.EXCEPTION_KEY); I watch through breakpoints or log statements and the exception is provided the first time through, but after it processes it, the error page runs a second time, this time with a null in that value. the result is that my error page is not getting what it needs, and renders without the needed info. Why would the error page run twice? I don't see any additional exceptions in the log, and the error page does render...it just renders as if the exception object were null. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-error-page-runs-twice-tp4668093.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
