Re: IndicatorAware and BookmarkablePageLink

2014-10-25 Thread Ernesto Reinaldo Barreiro
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=87917

?

On Fri, Oct 24, 2014 at 6:39 PM, msalman mohammad_sal...@yahoo.com wrote:

 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




-- 
Regards - Ernesto Reinaldo Barreiro


Re: Lock timeout per page class

2014-10-25 Thread Guillaume Smet
Hi Martin,

I got something working with the following changes in Wicket:
https://github.com/openwide-java/wicket/commit/6374a4a7c6fb66841143a88933523f97305cf1a4

Do you consider this commitable? If so, I can create a JIRA issue and push a PR.

Having the pageId in the getTimeout call is quite nice as I don't have
to get it again from the PageRequestHandlerTracker.

Thanks for your feedback.

On Fri, Oct 24, 2014 at 9:16 AM, Martin Grigorov mgrigo...@apache.org wrote:
 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



-
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

2014-10-25 Thread Sebastien
Hi Guillaume,

Generally speaking, you cannot call a non final method from a constructor...

Best regards,
Sebastien
On Oct 25, 2014 1:32 PM, Guillaume Smet guillaume.s...@gmail.com wrote:

 Hi Martin,

 I got something working with the following changes in Wicket:

 https://github.com/openwide-java/wicket/commit/6374a4a7c6fb66841143a88933523f97305cf1a4

 Do you consider this commitable? If so, I can create a JIRA issue and push
 a PR.

 Having the pageId in the getTimeout call is quite nice as I don't have
 to get it again from the PageRequestHandlerTracker.

 Thanks for your feedback.

 On Fri, Oct 24, 2014 at 9:16 AM, Martin Grigorov mgrigo...@apache.org
 wrote:
  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
 
 

 -
 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

2014-10-25 Thread Jason Novotny


I've managed to figure out the cause of the problem but no solution.

jquery datatables removes DOM elements when configured for pagination. 
This means the AjaxLinks in my listview generate wicket javascript like:


Wicket.Ajax.ajax({u:./executed?7-1.IBehaviorListener.0-container-executedTransactionPanel-executedListView-0-detailsLink,e:click,c:detailsLinkff});;
Wicket.Ajax.ajax({u:./executed?7-1.IBehaviorListener.0-container-executedTransactionPanel-executedListView-1-detailsLink,e:click,c:detailsLink100});;
Wicket.Ajax.ajax({u:./executed?7-1.IBehaviorListener.0-container-executedTransactionPanel-executedListView-2-detailsLink,e:click,c:detailsLink101});;
Wicket.Ajax.ajax({u:./executed?7-1.IBehaviorListener.0-container-executedTransactionPanel-executedListView-3-detailsLink,e:click,c:detailsLink102});;
...


If the table has 2 pages, it removes the DOM elements from the 2nd page 
so I get the wicket debug error  Wicket.Ajax: Cannot bind a listener 
for event click on element elementId because the element is not in 
the DOM


Now when I hit the link for next page of the table, the DOM has been 
updated to reflect the rows, but the javascript events need to be added 
again and so the links are broken.


Is there any good way to do this?

Thanks, Jason

On 10/24/14, 1:24 PM, Jason Novotny wrote:


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