Re: Dynamic Session.style
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 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
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
Re: StalePageException handling issue
Excellent. Thanks! On Mon, Apr 23, 2012 at 2:22 AM, Martin Grigorov wrote: > 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 > 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
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
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 wrote: > Hi, > > On Wed, Feb 29, 2012 at 12:37 AM, Allen Gilbert > 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.Wick
Re: Component implementation - instance variables
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 wrote: > On Tue, Feb 28, 2012 at 2:49 PM, Allen Gilbert > 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 > >
onConfigure()
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
Component implementation - instance variables
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
JavaSerializer - java.util.ConcurrentModificationException during page serialization
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
Error detaching RequestHandler
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"
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 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.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Wicket.Ajax.registerPre/PostCallHandler filtering
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 >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
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 >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
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 wrote: > 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 > 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 > >
Wicket.Ajax.registerPre/PostCallHandler filtering
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
Hide page version query parameters
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
Re: IRequestMapper that ignores page version
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 wrote:
> 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
> 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
>
>
IRequestMapper that ignores page version
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: Hiding subclass components
Override MarkupContainer.add()? It's final, so I can't...
On Thu, Nov 3, 2011 at 4:46 PM, Igor Vaynberg wrote:
> override add() and funnel everything into a non-transparent
> webmarkupcontainer.
>
> -igor
>
> On Thu, Nov 3, 2011 at 2:40 PM, Allen Gilbert wrote:
>> 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
>> ...
>>
>>
>>
>> ...
>>
>> 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
>>
>>
>
> -
> 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
Hiding subclass components
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
...
...
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
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
