Dynamic Session.style

2013-05-03 Thread Allen Gilbert
We are adding some new pages to our application that we'd like to
style differently from existing ones. We also want to reuse Panels
we've built, so we're employing the Style mechanism outlined in
https://cwiki.apache.org/confluence/display/WICKET/Localization+and+Skinning+of+Applications.

We have two different base pages for the separate styles, and in each
base page constructor, we set the proper Session.style. This works
fine, but doesn't seem like the best approach, and now we've
discovered a problem with it.

Say a user lands on page A with style A (the default style), then
opens page B with style B in a new tab. After looking at page B for a
bit, the user goes back to the tab with page A. The user clicks an
AjaxLink that should display an InfoPanel. InfoPanel can be used with
both styles, so it has two markup files: InfoPanel.html, and
InfoPanel_B.html. Unfortunately, because page B was the last page to
set Session.style, InfoPanel_B.html is loaded, even though the user is
on page A.

Any suggestions on how to solve this problem? The first thing that
came to my mind was to create an AbstractRequestCycleListener subclass
that could properly set Session.style for each request, but I'm not
sure if that's a good idea.

Thanks for your help!

-Allen

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Dynamic Session.style

2013-05-03 Thread Allen Gilbert
If locale and/or style are determined by a user-configurable setting,
then yes, I agree that all pages should be affected by it. However,
we're trying to differentiate styles between pages viewed within the
same session. I'm guessing that Session.style was designed to be set
once, not dynamically...

On Fri, May 3, 2013 at 11:55 AM, Paul Bors p...@bors.ws wrote:
 But isn't that normal behavior?

 Consider localization alone and setting the user's language in a session.
 If the user logs in and uses English and then opens a new tab (same session)
 and choose Spanish, going back to the first tab and refreshing the page
 should be in Spanish.

 Same for you. What you need to do is create a new session for the second tab
 in order to treat them separate.

 ~ Thank you,
   Paul Bors

 -Original Message-
 From: Allen Gilbert [mailto:allen.gilb...@doane.edu]
 Sent: Friday, May 03, 2013 12:48 PM
 To: users
 Subject: Dynamic Session.style

 We are adding some new pages to our application that we'd like to style
 differently from existing ones. We also want to reuse Panels we've built, so
 we're employing the Style mechanism outlined in
 https://cwiki.apache.org/confluence/display/WICKET/Localization+and+Skinning
 +of+Applications.

 We have two different base pages for the separate styles, and in each base
 page constructor, we set the proper Session.style. This works fine, but
 doesn't seem like the best approach, and now we've discovered a problem with
 it.

 Say a user lands on page A with style A (the default style), then opens page
 B with style B in a new tab. After looking at page B for a bit, the user
 goes back to the tab with page A. The user clicks an AjaxLink that should
 display an InfoPanel. InfoPanel can be used with both styles, so it has two
 markup files: InfoPanel.html, and InfoPanel_B.html. Unfortunately, because
 page B was the last page to set Session.style, InfoPanel_B.html is loaded,
 even though the user is on page A.

 Any suggestions on how to solve this problem? The first thing that came to
 my mind was to create an AbstractRequestCycleListener subclass that could
 properly set Session.style for each request, but I'm not sure if that's a
 good idea.

 Thanks for your help!

 -Allen

 -
 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: StalePageException handling issue

2012-04-23 Thread Allen Gilbert
Excellent. Thanks!

On Mon, Apr 23, 2012 at 2:22 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 Hi Allen,

 This is improved in 1.5-SNAPSHOT and will be part of 1.5.6.
 See https://issues.apache.org/jira/browse/WICKET-4488 and
 https://issues.apache.org/jira/browse/WICKET-4441

 On Mon, Apr 23, 2012 at 4:59 AM, Allen Gilbert allen.gilb...@doane.edu
 wrote:
  While trying to understand what causes StalePageExceptions (using Wicket
  1.5.4), I discovered a strange situation that can occur
  when DefaultExceptionMapper handles a StalePageException. I decided to
 ping
  the mailing list before creating a JIRA issue in case I'm
 misunderstanding
  intended behavior.
 
  Consider this scenario:
 
  1) A user logs in and loads a few different pages, eventually landing on
  Page A.  At this point, Page A's version is 5, e.g. /some/path/pageA?5
  2) The user opens a new tab and loads Page B
  3) The user logs out (or their session times out) while on Page B
  4) The user logs back in and interacts with Page B, performing page-level
  actions that increase the render count of the page, until Page B's
 version
  is 5.  At this point, a link listener url on Page B looks something
 like
  /some/path/pageB?5-3.ILinkListener-someLink
  5) The user switches back to their old Page A tab
  6) The user clicks an action link (with a listener url
  like /some/path/pageA?5-1.ILinkListener-someLink) on Page A
  7) Wicket throws a StalePageException because the page with version 5
 has
  a render count of 3, not 1
  8) At this point, the strange thing occurs: instead of rendering a new
  version of Page A, Wicket renders Page B.  Thus, even though the user
  attempted to do something on Page A, they are now looking at Page B.
 
  Digging into the code, it seems this is due to the implementation of
  PageProvider.getStoredPage(int pageId).  Notably, the javadoc for the
  method states, If pageClass is specified then compares it against the
  stored instance class and returns the found instance only if they match.
   In the example, pageClass would be PageA.class,
  but storedPageInstance.getClass() would return PageB.class (the page with
  id=5 in the newest session).  However, even though pageClass
  and storedPageInstance.getClass() aren't equal, the method still
  returns storedPageInstance.
 
  In this case, shouldn't getStoredPage() should return null, prompting a
  fresh instantiation of PageA.class?  That way, when the user clicks the
  stale link on Page A, they'll get a fresh rendering of Page A.
 
  Thanks for your help!
 
  -Allen



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




StalePageException handling issue

2012-04-22 Thread Allen Gilbert
While trying to understand what causes StalePageExceptions (using Wicket
1.5.4), I discovered a strange situation that can occur
when DefaultExceptionMapper handles a StalePageException. I decided to ping
the mailing list before creating a JIRA issue in case I'm misunderstanding
intended behavior.

Consider this scenario:

1) A user logs in and loads a few different pages, eventually landing on
Page A.  At this point, Page A's version is 5, e.g. /some/path/pageA?5
2) The user opens a new tab and loads Page B
3) The user logs out (or their session times out) while on Page B
4) The user logs back in and interacts with Page B, performing page-level
actions that increase the render count of the page, until Page B's version
is 5.  At this point, a link listener url on Page B looks something like
/some/path/pageB?5-3.ILinkListener-someLink
5) The user switches back to their old Page A tab
6) The user clicks an action link (with a listener url
like /some/path/pageA?5-1.ILinkListener-someLink) on Page A
7) Wicket throws a StalePageException because the page with version 5 has
a render count of 3, not 1
8) At this point, the strange thing occurs: instead of rendering a new
version of Page A, Wicket renders Page B.  Thus, even though the user
attempted to do something on Page A, they are now looking at Page B.

Digging into the code, it seems this is due to the implementation of
PageProvider.getStoredPage(int pageId).  Notably, the javadoc for the
method states, If pageClass is specified then compares it against the
stored instance class and returns the found instance only if they match.
 In the example, pageClass would be PageA.class,
but storedPageInstance.getClass() would return PageB.class (the page with
id=5 in the newest session).  However, even though pageClass
and storedPageInstance.getClass() aren't equal, the method still
returns storedPageInstance.

In this case, shouldn't getStoredPage() should return null, prompting a
fresh instantiation of PageA.class?  That way, when the user clicks the
stale link on Page A, they'll get a fresh rendering of Page A.

Thanks for your help!

-Allen


Re: JavaSerializer - java.util.ConcurrentModificationException during page serialization

2012-03-01 Thread Allen Gilbert
Martin,

I definitely did a bunch of googling before pinging the mailing list, and
also attempted to pinpoint the List throwing the CME.  Unfortunately, it
was not very easy, as a lot of Lists were being serialized with our pages.
 Anyway, I think I've finally tracked down the bug.  Its cause is related
to two issues:

1) A custom, widely-used behavior was holding on to a reference to our
custom Session object, causing the Session to be serialized every time a
page was serialized.
2) Our Session was not thread-safe, as we incorrectly assumed that the
framework took care of that for us.  One of the Lists it contains was the
one throwing the CME (probably due to a user opening multiple tabs for the
same session?)

We've fixed both issues, so we'll see how things go.  Obviously, this bug
was our own doing, but I do think it'd be helpful if the Javadoc for
Session and Application mentioned that their thread-safety is up to users.
 I found out in my copy of Wicket in Action :-).

Thanks!

On Wed, Feb 29, 2012 at 1:54 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 Hi,

 On Wed, Feb 29, 2012 at 12:37 AM, Allen Gilbert allen.gilb...@doane.edu
 wrote:
  Hello,
 
  I'm trying to crack a strange, intermittent bug that's cropped up on our
  production site.  We're using Wicket 1.5.4, and receive the following
 stack
  trace a couple times a day under nominal load:
 
  2012-02-23 14:24:57,051 ERROR [ajp-0.0.0.0-8009-2]
  [org.apache.wicket.serialize.java.JavaSerializer] error writing object
  [Page class = com.company.web.pages.account.MyAccount, id = 8, render
 count
  = 2]: null
  java.util.ConcurrentModificationException
 at java.util.ArrayList.writeObject(ArrayList.java:573)
 at sun.reflect.GeneratedMethodAccessor252.invoke(Unknown Source)
 at
 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at
  java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
 at
  java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
 ...
 at
  java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
 at
 
 org.apache.wicket.serialize.java.JavaSerializer$CheckerObjectOutputStream.writeObjectOverride(JavaSerializer.java:250)
 at
  java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
 at
 
 org.apache.wicket.serialize.java.JavaSerializer.serialize(JavaSerializer.java:77)
 at
 
 org.apache.wicket.pageStore.DefaultPageStore.serializePage(DefaultPageStore.java:368)
 at
 
 org.apache.wicket.pageStore.DefaultPageStore.storePage(DefaultPageStore.java:146)
 at
 
 org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.storeTouchedPages(PageStoreManager.java:383)
 at
 
 org.apache.wicket.page.RequestAdapter.commitRequest(RequestAdapter.java:171)
 at
 
 org.apache.wicket.page.AbstractPageManager.commitRequest(AbstractPageManager.java:94)
 at
 
 org.apache.wicket.page.PageManagerDecorator.commitRequest(PageManagerDecorator.java:68)
 at
 
 org.apache.wicket.page.PageAccessSynchronizer$2.commitRequest(PageAccessSynchronizer.java:281)
 at org.apache.wicket.Application$2.onDetach(Application.java:1598)
 at
 
 org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:99)
 at
 
 org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:97)
 at
 
 org.apache.wicket.util.listener.ListenerCollection$1.notify(ListenerCollection.java:119)
 at
 
 org.apache.wicket.util.listener.ListenerCollection.reversedNotify(ListenerCollection.java:143)
 at
 
 org.apache.wicket.util.listener.ListenerCollection.reversedNotifyIgnoringExceptions(ListenerCollection.java:113)
 at
 
 org.apache.wicket.request.cycle.RequestCycleListenerCollection.onDetach(RequestCycleListenerCollection.java:95)
 at
 
 org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:600)
 at
 
 org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:539)
 at
 
 org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:287)
 at
 
 org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
 at
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
 at
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 ...
 
  Looking at our logs, there doesn't seem to be anything interesting going
 on
  around the time of these exceptions.  We're not spawning any threads on
 our
  own, and we haven't overridden any serialization-related mechanisms (or
  defined custom writeObject methods), so I'm at a loss as to where I
 should
  look for the cause

JavaSerializer - java.util.ConcurrentModificationException during page serialization

2012-02-28 Thread Allen Gilbert
Hello,

I'm trying to crack a strange, intermittent bug that's cropped up on our
production site.  We're using Wicket 1.5.4, and receive the following stack
trace a couple times a day under nominal load:

2012-02-23 14:24:57,051 ERROR [ajp-0.0.0.0-8009-2]
[org.apache.wicket.serialize.java.JavaSerializer] error writing object
[Page class = com.company.web.pages.account.MyAccount, id = 8, render count
= 2]: null
java.util.ConcurrentModificationException
at java.util.ArrayList.writeObject(ArrayList.java:573)
at sun.reflect.GeneratedMethodAccessor252.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
...
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at
org.apache.wicket.serialize.java.JavaSerializer$CheckerObjectOutputStream.writeObjectOverride(JavaSerializer.java:250)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at
org.apache.wicket.serialize.java.JavaSerializer.serialize(JavaSerializer.java:77)
at
org.apache.wicket.pageStore.DefaultPageStore.serializePage(DefaultPageStore.java:368)
at
org.apache.wicket.pageStore.DefaultPageStore.storePage(DefaultPageStore.java:146)
at
org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.storeTouchedPages(PageStoreManager.java:383)
at
org.apache.wicket.page.RequestAdapter.commitRequest(RequestAdapter.java:171)
at
org.apache.wicket.page.AbstractPageManager.commitRequest(AbstractPageManager.java:94)
at
org.apache.wicket.page.PageManagerDecorator.commitRequest(PageManagerDecorator.java:68)
at
org.apache.wicket.page.PageAccessSynchronizer$2.commitRequest(PageAccessSynchronizer.java:281)
at org.apache.wicket.Application$2.onDetach(Application.java:1598)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:99)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:97)
at
org.apache.wicket.util.listener.ListenerCollection$1.notify(ListenerCollection.java:119)
at
org.apache.wicket.util.listener.ListenerCollection.reversedNotify(ListenerCollection.java:143)
at
org.apache.wicket.util.listener.ListenerCollection.reversedNotifyIgnoringExceptions(ListenerCollection.java:113)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection.onDetach(RequestCycleListenerCollection.java:95)
at
org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:600)
at
org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:539)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:287)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
...

Looking at our logs, there doesn't seem to be anything interesting going on
around the time of these exceptions.  We're not spawning any threads on our
own, and we haven't overridden any serialization-related mechanisms (or
defined custom writeObject methods), so I'm at a loss as to where I should
look for the cause of this error.  Any ideas?

Thanks!

-Allen


Component implementation - instance variables

2012-02-28 Thread Allen Gilbert
I understand that it's not a good idea to store model bean objects as
instance variables in a Component, but I'm not clear on this: is it OK to
store references to child Components as private fields in a parent
Component (e.g. a Panel)?  It often seems convenient to do so, especially
when the child components need to be added to an AjaxRequestTarget.
 However, when that Panel is serialized, will its child Components be
serialized twice, once in the component hierarchy, and again as instance
variables?

-Allen


onConfigure()

2012-02-28 Thread Allen Gilbert
OK, one more question, then I'll stop pestering everyone...at least for now
: ).

Is it problematic to make changes to a Component's model in its
onConfigure() method?

-Allen


Re: Component implementation - instance variables

2012-02-28 Thread Allen Gilbert
Thanks, Igor.  Java maintaining references when serializing makes sense...I
should have realized that.  Otherwise, deserialization would constantly
introduce new instances in place of proper references.

On Tue, Feb 28, 2012 at 4:52 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 On Tue, Feb 28, 2012 at 2:49 PM, Allen Gilbert allen.gilb...@doane.edu
 wrote:
  I understand that it's not a good idea to store model bean objects as
  instance variables in a Component, but I'm not clear on this: is it OK to
  store references to child Components as private fields in a parent
  Component (e.g. a Panel)?

 yes, its perfectly fine.

  It often seems convenient to do so, especially
  when the child components need to be added to an AjaxRequestTarget.
   However, when that Panel is serialized, will its child Components be
  serialized twice, once in the component hierarchy, and again as instance
  variables?

 no, serialization supports references.

 -igor

 
  -Allen

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Error detaching RequestHandler

2012-01-19 Thread Allen Gilbert
Running 1.5.2, we occasionally see this error message in our logs,
usually many times in a row:

2012-01-19 10:03:09,284 ERROR
[org.apache.wicket.request.RequestHandlerStack] Error detaching
RequestHandler
org.apache.wicket.RestartResponseAtInterceptPageException

No other details are provided.  Any idea what this means?

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: What is the cause for log entry ModificationWatcher - Cannot track modifications to resource

2012-01-02 Thread Allen Gilbert
Per,

I ran into this problem recently and solved it by removing spaces from
directory names in my project path.  I plan to file a Jira issue at some
point, as it seems that ModificationWatcher should be able to handle file
paths with spaces...

-Allen

On Mon, Jan 2, 2012 at 4:42 AM, Per Newgro per.new...@gmx.ch wrote:

 Hi,

 If i test my app by using Start.java i get the log entry
 INFO  - ModificationWatcher- Cannot track modifications to
 resource file:/D:/Dokumente%20und%**20Einstellungen/per.n/Eigene%**
 20Dateien/workspaces/work/**whataschranz/target/classes/**
 ch/newgro/shop/whataschranz/**welcome/HomePage.html
 If i change the HP Markup it's not reloaded.

 Google only pops up an answer by igor
 not sure you can do anything about the message...just disable the logger
 for that class/package...

 But disabling the log message is not solving the problem, that my markup
 modifications are not re-loaded :-).
 As far as i investigated this issue is a problem with the encoded path
 string (%20) used to load the resource by
 org.apache.wicket.util.**resource.locator.**ResourceStreamLocator#**locateByResourceFinder.

 I'm not an expert but i think i've read a message that something changed
 here (URI class or servlet-api)
 but maybe someone else already solved this.

 My question is - Is this a bug or can i configure something to make
 resource modification watcher working?

 Thanks
 Per

 --**--**-
 To unsubscribe, e-mail: 
 users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Wicket.Ajax.registerPre/PostCallHandler filtering

2011-12-29 Thread Allen Gilbert
After a bit more digging, I'm not sure I'll be able to use
IAjaxIndicatorAware at this time:
https://issues.apache.org/jira/browse/WICKET-4257.  I have a few components
that currently use it, and we've noticed this issue as well.  For them,
it's simply an annoyance (the indicator graphic doesn't go away), but with
this Panel, it will be very problematic if the blocking div is not removed
properly.

On Thu, Dec 29, 2011 at 10:56 AM, Ernesto Reinaldo Barreiro 
reier...@gmail.com wrote:

 That's perfectly doable: put the loading indicator on top of the blocking
 div.

 On Thu, Dec 29, 2011 at 5:28 PM, Allen Gilbert allen.gilb...@doane.edu
 wrote:

  Ernesto,
 
  Interesting...I've only used IAjaxIndicatorAware to display a loading
 gif,
  but it might solve this problem if I can get it to nicely show and hide a
  div that a) blocks the user from interacting with my panel and b) shows a
  loading indicator.  I'll try it out.  Thanks!
 
  -Allen
 
  On Thu, Dec 29, 2011 at 3:40 AM, Ernesto Reinaldo Barreiro 
  reier...@gmail.com wrote:
 
   Allen,
  
   Isn't it possible to make the panel implement IAjaxIndicatorAware?
  
   Regards,
  
   Ernesto
  
   On Wed, Dec 28, 2011 at 11:41 PM, Allen Gilbert 
 allen.gilb...@doane.edu
   wrote:
  
Hello,
   
I have a Panel containing many child components that perform various
  ajax
actions.  Whenever an ajax request is initiated from the panel or any
  of
its children, I'd like to show an indicator on the panel and block
 user
interaction with it.  However, I don't want the indicator to be shown
  for
ajax requests initiated by other components on the page.  Is there a
  way
   to
access the context of an ajax request in a javascript pre- or
 post-ajax
call handler in order to determine what component is initiating the
request?  Looking at wicket-ajax.js, there doesn't seem to be.
   
Alternatively, is there a way to decorate all ajax request javascript
   for a
panel's child components?  I'd like to avoid having to modify every
  ajax
behavior of the Panel's child components in order to show the
 activity
indicator on the panel.
   
-Allen
   
  
 



Re: Wicket.Ajax.registerPre/PostCallHandler filtering

2011-12-29 Thread Allen Gilbert
Ernesto,

Interesting...I've only used IAjaxIndicatorAware to display a loading gif,
but it might solve this problem if I can get it to nicely show and hide a
div that a) blocks the user from interacting with my panel and b) shows a
loading indicator.  I'll try it out.  Thanks!

-Allen

On Thu, Dec 29, 2011 at 3:40 AM, Ernesto Reinaldo Barreiro 
reier...@gmail.com wrote:

 Allen,

 Isn't it possible to make the panel implement IAjaxIndicatorAware?

 Regards,

 Ernesto

 On Wed, Dec 28, 2011 at 11:41 PM, Allen Gilbert allen.gilb...@doane.edu
 wrote:

  Hello,
 
  I have a Panel containing many child components that perform various ajax
  actions.  Whenever an ajax request is initiated from the panel or any of
  its children, I'd like to show an indicator on the panel and block user
  interaction with it.  However, I don't want the indicator to be shown for
  ajax requests initiated by other components on the page.  Is there a way
 to
  access the context of an ajax request in a javascript pre- or post-ajax
  call handler in order to determine what component is initiating the
  request?  Looking at wicket-ajax.js, there doesn't seem to be.
 
  Alternatively, is there a way to decorate all ajax request javascript
 for a
  panel's child components?  I'd like to avoid having to modify every ajax
  behavior of the Panel's child components in order to show the activity
  indicator on the panel.
 
  -Allen
 



Wicket.Ajax.registerPre/PostCallHandler filtering

2011-12-28 Thread Allen Gilbert
Hello,

I have a Panel containing many child components that perform various ajax
actions.  Whenever an ajax request is initiated from the panel or any of
its children, I'd like to show an indicator on the panel and block user
interaction with it.  However, I don't want the indicator to be shown for
ajax requests initiated by other components on the page.  Is there a way to
access the context of an ajax request in a javascript pre- or post-ajax
call handler in order to determine what component is initiating the
request?  Looking at wicket-ajax.js, there doesn't seem to be.

Alternatively, is there a way to decorate all ajax request javascript for a
panel's child components?  I'd like to avoid having to modify every ajax
behavior of the Panel's child components in order to show the activity
indicator on the panel.

-Allen


Re: Wicket.Ajax.registerPre/PostCallHandler filtering

2011-12-28 Thread Allen Gilbert
Martin,

I am familiar with IAjaxCallDecorator, and am using it extensively.
 However, in this case, I'm trying to avoid having to
override getAjaxCallDecorator() in every Ajax-enabled component under my
Panel.  Instead, I'm trying to find a single place where I can decorate or
pre- and post-process calls for the various ajax components in my Panel.

-Allen

On Thu, Dec 29, 2011 at 12:25 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 See IAjaxCallDecorator.
 Each Ajax component can decorate its ajax call with pre- and post-
 conditions. To remove the indicator use onSuccess and onFailure
 callbacks

 On Thu, Dec 29, 2011 at 12:41 AM, Allen Gilbert allen.gilb...@doane.edu
 wrote:
  Hello,
 
  I have a Panel containing many child components that perform various ajax
  actions.  Whenever an ajax request is initiated from the panel or any of
  its children, I'd like to show an indicator on the panel and block user
  interaction with it.  However, I don't want the indicator to be shown for
  ajax requests initiated by other components on the page.  Is there a way
 to
  access the context of an ajax request in a javascript pre- or post-ajax
  call handler in order to determine what component is initiating the
  request?  Looking at wicket-ajax.js, there doesn't seem to be.
 
  Alternatively, is there a way to decorate all ajax request javascript
 for a
  panel's child components?  I'd like to avoid having to modify every ajax
  behavior of the Panel's child components in order to show the activity
  indicator on the panel.
 
  -Allen



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




IRequestMapper that ignores page version

2011-12-05 Thread Allen Gilbert
Hello,

I have a problem similar to the one outlined here:
http://apache-wicket.1842946.n4.nabble.com/Migrating-from-1-4-16-to-1-5-RC3-problem-when-trying-to-avoid-pages-caching-not-calling-the-construc-td3463183.html.
I have a page that uses a lot of Ajax (and is thus stateful/versioned), but
I need its constructor to be called any time the page is requested.
 Otherwise, if the user lands on the page via the back button, it will not
be rendered correctly.  Anyway, I'm looking into creating a custom
IRequestMapper, per Martin's suggestion in the Nabble thread.  However, I
don't know where to start. Should I extend one of the existing mappers
(e.g. MountedMapper), or should I create an entirely new implementation of
IRequestMapper?  In either case, how do I make sure that I don't screw up
handling of listener links for ajax actions on the page?  In other words,
how do I create a reliable IRequestMapper for a page that, when requested,
always re-renders itself?

If there's a different way to accomplish this (i.e. without creating a
custom IRequestMapper or making the page stateless), I'd love to know.

Thanks for your help!

-Allen


Re: IRequestMapper that ignores page version

2011-12-05 Thread Allen Gilbert
Martin,

I had to modify your example to get it to work, as request.getUrl()
actually returns a new Url instance when it's called.  Here's what I
settled on:

@Override
public IRequestHandler mapRequest(Request request) {
Request requestToMap = request;
if ((request instanceof WebRequest)  !((WebRequest) request).isAjax()) {
PageComponentInfo info = getPageComponentInfo(request.getUrl());
if (info != null) {
Url url = request.getUrl();
url.removeQueryParameters(info.toString());
requestToMap = request.cloneWithUrl(url);
}
}
return super.mapRequest(requestToMap);
}

Does anyone see any issues with this approach?

Thanks!

-Allen

On Mon, Dec 5, 2011 at 2:28 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 Hi,

 Here is an idea (again from me:-) ):

 Override MountedMapper and in #mapRequest(Request) do:

 if (((WebRequest) request).isAjax()) return super.mapRequest(request);

 // else
 url = request.getUrl();
 info = getPageComponentInfo(url);
 if (info != null) url.removeQueryParam(info.toString());

 return super.mapRequest(request)

 This will cut the special parameter that brings the page info

 On Mon, Dec 5, 2011 at 8:08 PM, Allen Gilbert allen.gilb...@doane.edu
 wrote:
  Hello,
 
  I have a problem similar to the one outlined here:
 
 http://apache-wicket.1842946.n4.nabble.com/Migrating-from-1-4-16-to-1-5-RC3-problem-when-trying-to-avoid-pages-caching-not-calling-the-construc-td3463183.html
 .
  I have a page that uses a lot of Ajax (and is thus stateful/versioned),
 but
  I need its constructor to be called any time the page is requested.
   Otherwise, if the user lands on the page via the back button, it will
 not
  be rendered correctly.  Anyway, I'm looking into creating a custom
  IRequestMapper, per Martin's suggestion in the Nabble thread.  However, I
  don't know where to start. Should I extend one of the existing mappers
  (e.g. MountedMapper), or should I create an entirely new implementation
 of
  IRequestMapper?  In either case, how do I make sure that I don't screw up
  handling of listener links for ajax actions on the page?  In other words,
  how do I create a reliable IRequestMapper for a page that, when
 requested,
  always re-renders itself?
 
  If there's a different way to accomplish this (i.e. without creating a
  custom IRequestMapper or making the page stateless), I'd love to know.
 
  Thanks for your help!
 
  -Allen



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Hide page version query parameters

2011-12-05 Thread Allen Gilbert
Is there a built-in way to hide page version parameters (e.g. ?12) in
Wicket 1.5?  If not, is it possible to write a custom IRequestMapper that
does so without screwing up proper request handling?

-Allen


Hiding subclass components

2011-11-03 Thread Allen Gilbert
Hello,

I've defined an abstract subclass of WebPage (BasePage) that knows
whether or not a user can access the content of any concrete page.  If
a user does not have access, I don't want to block them from landing
on the page; instead, I'd like to show some page-specific content
instructing them how they can gain access to it.  The structure of
that content is the same across all of my pages, so I'd like BasePage
to a) define the markup necessary to display it, and b) hide its
subclass's content when necessary.  I came up with the following
approach, defining childContent as a transparent resolver:

BasePage.html
...
div wicket:id=childContent
   wicket:child /
/div
...

BasePage.java
...
WebMarkupContainer childContent = new WebMarkupContainer(childContent) {
   @Override
   public boolean isTransparentResolver() {
  return true;
   }
};
childContent.setVisible(isAccessible);
add(childContent);
...

Although this works, I have run into problems related to the
transparent resolver (e.g.
http://wicket-users.markmail.org/search/?q=#query:+page:1+mid:3gmjcjrggaxdrek2+state:results).
 The only other approach I can think of is to add code to each
BasePage subclass that will hide its components when isAccessible is
false, but that seems fairly redundant.  Any other ideas?  Aside from
defining a transparent resolver (not recommended, and apparently
removed in 1.5), is there a design flaw to this approach?

I'm using Wicket 1.4.18.

Thanks for your help!

-Allen

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Updating a child of a transparent resolver via ajax

2011-11-02 Thread Allen Gilbert
Hello,

Following Igor's example at
http://wicketinaction.com/2008/10/repainting-only-newly-created-repeater-items-via-ajax/,
I am trying to paint only the latest item added to a repeater.
Although the sample project from the article worked, I could not get
the approach to work on my page in my environment, as it failed with
the following error:

org.apache.wicket.WicketRuntimeException: Unable to find the markup
for the component. That may be due to transparent containers or
components implementing IComponentResolver: [MarkupContainer
[Component id = 3]]

After a bit of investigation, I realized that this error is related to
the fact that my repeating view's [eventual] parent is a transparent
resolver. To illustrate the problem, I modified the code in the sample
project from the article mentioned above and posted it here:
http://methodicapps.com/ajax-issue-src.zip

Is there any way I can get around this issue short of ensuring that
the repeater's parent is not a transparent resolver?

Thanks for your help!

-Allen

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org