Re: FilenameWithVersionResourceCachingStrategy accepts (almost) any string as a version
I know that and for me this is not an issue either ;).
But this "issue" is reported by some security scanners which checks
for obsolete and backup files by adding "_old", "_bak", "_backup"
suffix to filename of selected resource (css, js). And our Wicket
application is serving such files as if indeed such old copies were
available.
So I'm only loudly thinking is it really no problem that we serve
files with any text attached on the end of file name.
--
Daniel
pon., 25 maj 2020 o 21:14 Carl-Eric Menzel napisał(a):
>
> Sorry, didn't mean to sound dismissive. It's a valid point, just I'm
> not seeing that anybody could get to anything otherwise unavailable.
>
> On Mon, 25 May 2020 21:02:08 +0200
> Carl-Eric Menzel wrote:
>
> > I think the point of this version decoration is not to ensure a
> > particular version is requested, because typically only one version of
> > a file is available in the application.
> >
> > The point is instead to defeat any caching, both in the browser and by
> > proxies, which might serve the user an outdated version. So I don't
> > think there needs to be any checking of that string.
> >
> > Or is there an actual security impact that I'm missing?
> >
> > Carl-Eric
> >
> > On Mon, 25 May 2020 20:47:36 +0200
> > Daniel Stoch wrote:
> >
> > > Hi,
> > >
> > > Each resource in Wicket is decorated using a version string in a
> > > file name by default. It is implemented in
> > > FilenameWithVersionResourceCachingStrategy. Depending on DEVELOPMENT
> > > or DEPLOYMENT mode it looks like:
> > > jquery-ver-1590158412000.css
> > > jquery-ver-F334A4E46CB37347CAB42E2B1A45897C.css
> > >
> > > There is a small security issue, that this strategy does not check
> > > if this version is correctly calculated for specific resource and
> > > accepts any string as a version identifier, eg.:
> > > jquery-ver-F334A4E46CB37347CAB42E2B1A45897C_old.css
> > > jquery-ver-F334A4E46CB37347CAB42E2B1A45897C_bakup.css
> > > jquery-ver-XYZABCDEF.css
> > > etc.
> > >
> > > Maybe we should add a check if version passed in request is correct?
> > > There is partially such check done in decorateResponse() method. So
> > > maybe it is enough to add else block here and raise some exception?
> > >
> > > @Override
> > > public void decorateResponse(AbstractResource.ResourceResponse
> > > response, IStaticCacheableResource resource) {
> > > String requestedVersion =
> > > RequestCycle.get().getMetaData(URL_VERSION); String
> > > calculatedVersion = this.resourceVersion.getVersion(resource); if
> > > (calculatedVersion != null &&
> > > calculatedVersion.equals(requestedVersion))
> > > { response.setCacheDurationToMaximum();
> > > response.setCacheScope(WebResponse.CacheScope.PUBLIC); } }
> > >
> > > --
> > > Best regards,
> > > Daniel Stoch
> > >
> > > -
> > > 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
> >
>
> 000
>
> -
> 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
FilenameWithVersionResourceCachingStrategy accepts (almost) any string as a version
Hi,
Each resource in Wicket is decorated using a version string in a file
name by default. It is implemented in
FilenameWithVersionResourceCachingStrategy. Depending on DEVELOPMENT
or DEPLOYMENT mode it looks like:
jquery-ver-1590158412000.css
jquery-ver-F334A4E46CB37347CAB42E2B1A45897C.css
There is a small security issue, that this strategy does not check if
this version is correctly calculated for specific resource and accepts
any string as a version identifier, eg.:
jquery-ver-F334A4E46CB37347CAB42E2B1A45897C_old.css
jquery-ver-F334A4E46CB37347CAB42E2B1A45897C_bakup.css
jquery-ver-XYZABCDEF.css
etc.
Maybe we should add a check if version passed in request is correct?
There is partially such check done in decorateResponse() method. So
maybe it is enough to add else block here and raise some exception?
@Override
public void decorateResponse(AbstractResource.ResourceResponse
response, IStaticCacheableResource resource) {
String requestedVersion = RequestCycle.get().getMetaData(URL_VERSION);
String calculatedVersion = this.resourceVersion.getVersion(resource);
if (calculatedVersion != null && calculatedVersion.equals(requestedVersion)) {
response.setCacheDurationToMaximum();
response.setCacheScope(WebResponse.CacheScope.PUBLIC);
}
}
--
Best regards,
Daniel Stoch
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Users can be redirected based on unvalidated input (CWE-601: URL Redirection to Untrusted Site)
Hi, Do you have a knowledge how to protect a Wicket application against such a problem: http://cwe.mitre.org/data/definitions/601.html In short: redirect request can be intercepted and the attacker can change Host header to another value. Can it be done on application (Wicket, Java Servlet) level (such Host header checking) or should it be done outside an app, on the reverse-proxy level, ...? More details: Description: The application redirects users based on the value of the Host header. As this value is not properly validated, redirects to third party domains can occur. Impact: It is possible to redirect application users to a URL outside the customer control. Such a website might be used in phishing attacks to harvest user credentials or try to exploit vulnerabilities on a user’s machine. This vulnerability might also lead to web-cache poisoning and poisoning of links that are send to an user via an e-mail functionality. Proposal: Validate all input parameters used for redirection and deny any request if the supplied value does not belong to the application’s domain. -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: WebSockets: page deserialisation on close (performance issue?)
Hi, Thanks for your answer. I have created a JIRA issue with Quickstart: https://issues.apache.org/jira/browse/WICKET-6692 -- Daniel On Sat, Aug 3, 2019 at 10:05 PM Sven Meier wrote: > > Hi Daniel, > > can you create a quickstart and attach it to a Jura issue please? > > Thanks > Sven > > On 01.08.19 10:57, Daniel Stoch wrote: > > Correction to my previous message (I have debugged this more precisely): > > > > AbstractWebSocketProcessor.onClose method is called in both Jetty > > versions (not only in a newer one). > > The difference is in connection: > > - in Jetty 9.4.12.v20180830 connection is closed > > - in Jetty 9.4.18.v20190429 connection is still open > > > > So message is broadcasted only in a newer version. > > > > -- > > Daniel > > > > On Thu, Aug 1, 2019 at 10:25 AM Daniel Stoch wrote: > >> Hi, > >> > >> We are using web sockets (with wicket-native-core) on many pages in > >> our application. After upgrade a Jetty from 9.4.12.v20180830 to a > >> newer version 9.4.18.v20190429, I have found a different behaviour in > >> application: > >> > >> When user navigates to another page, a websocket connection is closed > >> and AbstractWebSocketProcessor.onClose method is called. This causes > >> broadcasting a message to connected page: > >> > >>broadcastMessage(new ClosedMessage(getApplication(), getSessionId(), > >> key)); > >> > >> and leads to page deserialisation (from PageStore). > >> I think something was changed in a new version of Jetty, because in > >> the previous used version this was not called. Maybe because of this: > >> https://github.com/eclipse/jetty.project/issues/3835 > >> https://github.com/eclipse/jetty.project/commit/2383bf4974ba7d82109cedfc4a8e7693d106abf0 > >> > >> I believe that now it works correctly (as was designed) and onClose > >> should be called. But I wonder how it can affect performance: almost > >> every page navigation causes page deserialization (when it should > >> occur only for back button or when some web socket message comes and > >> application need to process it). > >> > >> Maybe this message should be send only when needed or maybe I should > >> not care and current behaviour does not affect performance? > >> > >> -- > >> Best regards, > >> Daniel Stoch > > - > > 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: WebSockets: page deserialisation on close (performance issue?)
Correction to my previous message (I have debugged this more precisely): AbstractWebSocketProcessor.onClose method is called in both Jetty versions (not only in a newer one). The difference is in connection: - in Jetty 9.4.12.v20180830 connection is closed - in Jetty 9.4.18.v20190429 connection is still open So message is broadcasted only in a newer version. -- Daniel On Thu, Aug 1, 2019 at 10:25 AM Daniel Stoch wrote: > > Hi, > > We are using web sockets (with wicket-native-core) on many pages in > our application. After upgrade a Jetty from 9.4.12.v20180830 to a > newer version 9.4.18.v20190429, I have found a different behaviour in > application: > > When user navigates to another page, a websocket connection is closed > and AbstractWebSocketProcessor.onClose method is called. This causes > broadcasting a message to connected page: > > broadcastMessage(new ClosedMessage(getApplication(), getSessionId(), key)); > > and leads to page deserialisation (from PageStore). > I think something was changed in a new version of Jetty, because in > the previous used version this was not called. Maybe because of this: > https://github.com/eclipse/jetty.project/issues/3835 > https://github.com/eclipse/jetty.project/commit/2383bf4974ba7d82109cedfc4a8e7693d106abf0 > > I believe that now it works correctly (as was designed) and onClose > should be called. But I wonder how it can affect performance: almost > every page navigation causes page deserialization (when it should > occur only for back button or when some web socket message comes and > application need to process it). > > Maybe this message should be send only when needed or maybe I should > not care and current behaviour does not affect performance? > > -- > Best regards, > Daniel Stoch - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
WebSockets: page deserialisation on close (performance issue?)
Hi, We are using web sockets (with wicket-native-core) on many pages in our application. After upgrade a Jetty from 9.4.12.v20180830 to a newer version 9.4.18.v20190429, I have found a different behaviour in application: When user navigates to another page, a websocket connection is closed and AbstractWebSocketProcessor.onClose method is called. This causes broadcasting a message to connected page: broadcastMessage(new ClosedMessage(getApplication(), getSessionId(), key)); and leads to page deserialisation (from PageStore). I think something was changed in a new version of Jetty, because in the previous used version this was not called. Maybe because of this: https://github.com/eclipse/jetty.project/issues/3835 https://github.com/eclipse/jetty.project/commit/2383bf4974ba7d82109cedfc4a8e7693d106abf0 I believe that now it works correctly (as was designed) and onClose should be called. But I wonder how it can affect performance: almost every page navigation causes page deserialization (when it should occur only for back button or when some web socket message comes and application need to process it). Maybe this message should be send only when needed or maybe I should not care and current behaviour does not affect performance? -- Best regards, Daniel Stoch - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
ResponseIOException logged as error in DefaultExceptionMapper
Hi,
DefaultExceptionMapper handles by default some "internal" exceptions.
You can look at the thread "Marker interface for "internal"
exceptions" on this list (Jun 02, 2014). ResponseIOException is one of
them, but when this kind of exception occurs then an error is logged
in DefaultExceptionMapper.mapExpectedExceptions(...):
logger.error("Connection lost, give up responding.", e);
Why it is logged as an error, which means something is wrong in our
application? If it is handled transparently by a framework then it
should not be logged as error (maybe as debug?).
Or maybe I should add some special handling to this
ResponseIOException in my app?
--
Best regards,
Daniel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
How to add some data to ajax and websocket response?
Hi, I am trying to solve WICKET-5588. I want to add some ordering information (key-value) to responses for ajax and websocket. This information then will be read on client side (JS) to handle proper processing order of responses. But I cannot find a good entry point to add such generic information (order information should be calculated in context of page/component). How to add such information to response in Wicket 6.x? -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Resource caching - validation of user entered version
Thanks for fast answer :)
--
Daniel
On Tue, May 31, 2016 at 4:54 PM, Martin Grigorov <mgrigo...@apache.org> wrote:
> Hi,
>
> The version is intended to be used by the browser for client side caching,
> not by Wicket. That's why it is just stripped off by Wicket without any
> validation.
> Actually if Wicket rejects it then you won't be able to update your
> resources in new application versions.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, May 31, 2016 at 4:51 PM, Daniel Stoch <daniel.st...@gmail.com>
> wrote:
>
>> Hi,
>>
>> By default Wicket (6.x) uses IResourceCachingStrategy which generates
>> resource urls like this one:
>>
>> http://host/myapp/wicket/resource/com.mycompany.BootstrapBehavior/js/timepicker/bootstrap-timepicker-ver-1E0DAFB24FE33C93370DE13BF6FFE77F.js
>>
>> But as a user I can generate almost any version number in this url and
>> it will be handled correctly by Wicket. For example these urls still
>> work ok:
>>
>> http://host/myapp/wicket/resource/com.mycompany.BootstrapBehavior/js/timepicker/bootstrap-timepicker-ver-123.js
>>
>> http://host/myapp/wicket/resource/com.mycompany.BootstrapBehavior/js/timepicker/bootstrap-timepicker-ver--alert('1');return
>> false;.js
>>
>> Is it a desired behavior or maybe Wicket should reject such
>> "incorrect" versions? Could it be some security issue?
>>
>> --
>> Best regards,
>> Daniel
>>
>> -
>> 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
Resource caching - validation of user entered version
Hi,
By default Wicket (6.x) uses IResourceCachingStrategy which generates
resource urls like this one:
http://host/myapp/wicket/resource/com.mycompany.BootstrapBehavior/js/timepicker/bootstrap-timepicker-ver-1E0DAFB24FE33C93370DE13BF6FFE77F.js
But as a user I can generate almost any version number in this url and
it will be handled correctly by Wicket. For example these urls still
work ok:
http://host/myapp/wicket/resource/com.mycompany.BootstrapBehavior/js/timepicker/bootstrap-timepicker-ver-123.js
http://host/myapp/wicket/resource/com.mycompany.BootstrapBehavior/js/timepicker/bootstrap-timepicker-ver--alert('1');return
false;.js
Is it a desired behavior or maybe Wicket should reject such
"incorrect" versions? Could it be some security issue?
--
Best regards,
Daniel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Invalid JS src url for ajax behaviors - degradation after 6.17.0
Hi, Thanks for your answer. I have tried to reproduce this problem in quickstart app and it seems that it is a problem in my application. Problem is related to Wicket-Ajax-BaseURL encoding, when parameter values contains "#" (eg. abx#xyz). In 6.17.0 there were some problems with these encodings and I have internal patch in overridden MultipartServletWebRequestImpl.getHeader() method - I forgot to make JIRA for that. It seems that in 6.21.0 these problems do not exist, so my internal patch is not necessary, moreover generates an error which I described in a previous email. So when I remove it, it seems that everything works ok. -- Best regards, Daniel On Fri, Jan 8, 2016 at 10:47 PM, Sven Meier <s...@meiers.net> wrote: > Hi, > > please create a quickstart and/or test case and attach it to a new Jira > issue. > > This way we can dissect the problem. > > Best regards > Sven > > > > On 08.01.2016 18:19, Daniel Stoch wrote: >> >> Hi, >> >> I have upgraded Wicket from 6.17.0 to 6.21.0. And there is some >> problem after this upgrade. I am using UrlPathPageParametersEncoder so >> my page parameters are encoded like: >> /param1Name/param1Value/param2Name/param2Value >> >> Sample scenario to reproduce this problem: >> 1. User enters a bookmarkable page with four parameters, so url looks >> like: >> http://localhost:8080/app/somepage/p1/v1/p2/v2/p3/v3/p4/v4 >> 2. User clicks checkbox with AjaxFormChoiceComponentUpdatingBehavior >> and the generated ajax response contains invalid (in 6.21.0) url to >> JavaScript resources, eg.: >> >> 6.21.0 >> > >> src="../../../../wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-event-jquery-ver-1446158378000.js"> >> >> but it shoud be: >> >> 6.17.0 >> > >> src="../../../../../../../../wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-event-jquery-ver-140930656.js"> >> >> >> So there are only 4 "../" url parts in new Wicket version, instead of >> 8 in older one (6.17.0). This leads to invalid requests that come to >> server (request contains invalid parameters in a path). >> >> Are there any changes in 6.x branch after 6.17.0 version which can >> cause such problems? >> >> -- >> Best regards, >> Daniel >> >> - >> 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
Invalid JS src url for ajax behaviors - degradation after 6.17.0
Hi, I have upgraded Wicket from 6.17.0 to 6.21.0. And there is some problem after this upgrade. I am using UrlPathPageParametersEncoder so my page parameters are encoded like: /param1Name/param1Value/param2Name/param2Value Sample scenario to reproduce this problem: 1. User enters a bookmarkable page with four parameters, so url looks like: http://localhost:8080/app/somepage/p1/v1/p2/v2/p3/v3/p4/v4 2. User clicks checkbox with AjaxFormChoiceComponentUpdatingBehavior and the generated ajax response contains invalid (in 6.21.0) url to JavaScript resources, eg.: 6.21.0 but it shoud be: 6.17.0 So there are only 4 "../" url parts in new Wicket version, instead of 8 in older one (6.17.0). This leads to invalid requests that come to server (request contains invalid parameters in a path). Are there any changes in 6.x branch after 6.17.0 version which can cause such problems? -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Native WebSockets - exceptions and sendRedirect inside WebSocketResponse
On Fri, Jan 1, 2016 at 10:25 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > Hi, > > > On Mon, Dec 28, 2015 at 4:49 PM, Daniel Stoch <daniel.st...@gmail.com> > wrote: > >> Hi, >> >> As I wrote in my previous post "Native WebSockets - cookies and last >> handler question": In WebSocketResponse many methods throws >> UnsupportedOperationException. Some of them can be customized now >> thanks to WICKET-6054. >> >> But I have found another problem with WebSocketResponse.sendRedirect() >> method. When you send a message using >> IWebSocketConnection.sendMessage() and an exeption is raised somewhere >> during processing of this message you can get the following exception >> (the orignal exception is lost): >> >> Error during processing error message >> java.lang.UnsupportedOperationException >> at >> org.apache.wicket.protocol.ws.api.WebSocketResponse.sendRedirect(WebSocketResponse.java:205) >> at >> org.apache.wicket.request.handler.render.WebPageRenderer.redirectTo(WebPageRenderer.java:176) >> at >> org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:327) >> at >> org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175) >> at >> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:890) >> at >> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:310) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) >> at >> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:233) >> at >> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) >> at >> org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor.broadcastMessage(AbstractWebSocketProcessor.java:251) >> at >> org.apache.wicket.protocol.ws.api.AbstractWebSocketConnection.sendMessage(AbstractWebSocketConnection.java:43) >> >> >> This is because WebPageRenderer by default calls redirectTo method. So >> it looks like WebSocketResponse.sendRedirect() should not throw >> exception in the default implementation? >> > > The default is to throw an exception so that you know that you are trying > to do something that is really not supported. > But now I think we can actually add support for it - as Ajax does with > ... > Please file a ticket with a quickstart app! > Thank you! > WICKET-6064 BTW: The quickstart app is not compatible with websockets when you are trying to use Start.main(): java.lang.IllegalStateException: Websockets not supported on blocking connectors at org.eclipse.jetty.websocket.WebSocketFactory.upgrade(WebSocketFactory.java:237) at org.eclipse.jetty.websocket.WebSocketFactory.acceptWebSocket(WebSocketFactory.java:396) at org.apache.wicket.protocol.ws.jetty.Jetty7WebSocketFilter.acceptWebSocket(Jetty7WebSocketFilter.java:74) at org.apache.wicket.protocol.ws.AbstractUpgradeFilter.processRequestCycle(AbstractUpgradeFilter.java:55) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1291) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandle
Re: Native WebSockets - exceptions and sendRedirect inside WebSocketResponse
On Fri, Jan 1, 2016 at 10:26 PM, Martin Grigorov <mgrigo...@apache.org> wrote:
> Hi,
>
> On Tue, Dec 29, 2015 at 2:14 PM, Daniel Stoch <daniel.st...@gmail.com>
> wrote:
>
>> Another problem with WebSocketRequest:
>>
>> @Override
>> public Url getUrl()
>> {
>> return null;
>> }
>>
>> @Override
>> public Url getClientUrl()
>> {
>> return null;
>> }
>>
>> null result in getUrl() method can leed to execptions in
>> UrlRequestParametersAdapter:
>>
>> java.lang.IllegalArgumentException: Argument 'url' may not be null.
>> at org.apache.wicket.util.lang.Args.notNull(Args.java:41)
>> at
>> org.apache.wicket.request.parameter.UrlRequestParametersAdapter.(UrlRequestParametersAdapter.java:48)
>> at
>> org.apache.wicket.request.Request.getQueryParameters(Request.java:128)
>> at
>> org.apache.wicket.request.Request.getRequestParameters(Request.java:136)
>>
>> Maybe these methods should better return empty Url instead of null (
>> return new Url(); )?
>>
>
> Please file a separate ticket with a quickstart app!
> Thank you!
WICKET-6063
--
Daniel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Native WebSockets - exceptions and sendRedirect inside WebSocketResponse
Another problem with WebSocketRequest:
@Override
public Url getUrl()
{
return null;
}
@Override
public Url getClientUrl()
{
return null;
}
null result in getUrl() method can leed to execptions in
UrlRequestParametersAdapter:
java.lang.IllegalArgumentException: Argument 'url' may not be null.
at org.apache.wicket.util.lang.Args.notNull(Args.java:41)
at
org.apache.wicket.request.parameter.UrlRequestParametersAdapter.(UrlRequestParametersAdapter.java:48)
at org.apache.wicket.request.Request.getQueryParameters(Request.java:128)
at org.apache.wicket.request.Request.getRequestParameters(Request.java:136)
Maybe these methods should better return empty Url instead of null (
return new Url(); )?
--
Daniel
On Mon, Dec 28, 2015 at 4:49 PM, Daniel Stoch <daniel.st...@gmail.com> wrote:
> Hi,
>
> As I wrote in my previous post "Native WebSockets - cookies and last
> handler question": In WebSocketResponse many methods throws
> UnsupportedOperationException. Some of them can be customized now
> thanks to WICKET-6054.
>
> But I have found another problem with WebSocketResponse.sendRedirect()
> method. When you send a message using
> IWebSocketConnection.sendMessage() and an exeption is raised somewhere
> during processing of this message you can get the following exception
> (the orignal exception is lost):
>
> Error during processing error message
> java.lang.UnsupportedOperationException
> at
> org.apache.wicket.protocol.ws.api.WebSocketResponse.sendRedirect(WebSocketResponse.java:205)
> at
> org.apache.wicket.request.handler.render.WebPageRenderer.redirectTo(WebPageRenderer.java:176)
> at
> org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:327)
> at
> org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175)
> at
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:890)
> at
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:310)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:233)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289)
> at
> org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor.broadcastMessage(AbstractWebSocketProcessor.java:251)
> at
> org.apache.wicket.protocol.ws.api.AbstractWebSocketConnection.sendMessage(AbstractWebSocketConnection.java:43)
>
>
> This is because WebPageRenderer by default calls redirectTo method. So
> it looks like WebSocketResponse.sendRedirect() should not throw
> exception in the default implementation?
>
> --
> Best regards,
> Daniel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Native WebSockets - exceptions and sendRedirect inside WebSocketResponse
Hi, As I wrote in my previous post "Native WebSockets - cookies and last handler question": In WebSocketResponse many methods throws UnsupportedOperationException. Some of them can be customized now thanks to WICKET-6054. But I have found another problem with WebSocketResponse.sendRedirect() method. When you send a message using IWebSocketConnection.sendMessage() and an exeption is raised somewhere during processing of this message you can get the following exception (the orignal exception is lost): Error during processing error message java.lang.UnsupportedOperationException at org.apache.wicket.protocol.ws.api.WebSocketResponse.sendRedirect(WebSocketResponse.java:205) at org.apache.wicket.request.handler.render.WebPageRenderer.redirectTo(WebPageRenderer.java:176) at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:327) at org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:890) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:310) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:233) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) at org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor.broadcastMessage(AbstractWebSocketProcessor.java:251) at org.apache.wicket.protocol.ws.api.AbstractWebSocketConnection.sendMessage(AbstractWebSocketConnection.java:43) This is because WebPageRenderer by default calls redirectTo method. So it looks like WebSocketResponse.sendRedirect() should not throw exception in the default implementation? -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Native WebSockets - cookies and last handler question
Hi, I am during replacement Atmosphere push implementation to Wicket Native WebSockets. I have an abstraction layer over it, so I can replace only implementation and easily switch between these two solutions and compare them. I have a couple of questions about Native WebSockets: 1. In WebSocketResponse many methods throws UnsupportedOperationException. I have a situation when component sets cookie during its lifecycle, so this exeption is raised when it is refreshed during push response. Is it any chance to implement these methods or do they necessary throw exceptions? In Atmosphere implementation this works. 2. I have a code which checks PageRequestHandlerTracker.getLastHandler(requestCycle) to get actual page for current request (is it a best method?). During processing push request this method returns null. Is it a correct behavior? In Atmosphere implementation this works too ;). More questions to come later ;) PS. I am using Wicket 6.x. -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Native WebSockets - cookies and last handler question
On Wed, Dec 23, 2015 at 2:34 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > Hi, > > > On Wed, Dec 23, 2015 at 2:21 PM, Daniel Stoch <daniel.st...@gmail.com> > wrote: > >> Hi, >> >> I am during replacement Atmosphere push implementation to Wicket >> Native WebSockets. I have an abstraction layer over it, so I can >> replace only implementation and easily switch between these two >> solutions and compare them. I have a couple of questions about Native >> WebSockets: >> >> 1. In WebSocketResponse many methods throws >> UnsupportedOperationException. I have a situation when component sets >> cookie during its lifecycle, so this exeption is raised when it is >> refreshed during push response. Is it any chance to implement these >> methods or do they necessary throw exceptions? In Atmosphere >> implementation this works. >> > > Although an HTTP request is being *upgraded* to WebSocket, the websocket > response is not an HTTP response. > You can only write String and binary data that is processed by the > application client code. The browser doesn't read/intercept the data > transfered on the websocket connection so any headers (like cookies) could > not be processed. > > We could change the impl to log a warning whenever one of those methods is > used instead of throwing exception. > Just like > https://github.com/apache/wicket/commit/8a5508e117991faf43f53d770b64568842d8d557 > Please file a ticket if you think this is a better implementation. Logging a warning is not a good solution in my case, because when I call addCookie() I don't know if current response implementation supports it or not (to avoid logging warns). So there will be many unnecessary WARN logs in my application. So a better solution for me is simply do nothing (empty mehod). I think it is probably not a good solution for you, but as I can see in WICKET-5737 there is a factory method for the WebSocketResponse so I will be able to use my own implementation of WebSocketResponse where addCookie() will not throws exception. Can this patch be backported to 6.x? > >> >> 2. I have a code which checks >> PageRequestHandlerTracker.getLastHandler(requestCycle) to get actual >> page for current request (is it a best method?). During processing >> push request this method returns null. Is it a correct behavior? In >> Atmosphere implementation this works too ;). >> > > I think this should work. > There must be a bug somewhere. What should I check, how to investigate it? > > >> >> More questions to come later ;) >> PS. I am using Wicket 6.x. >> >> -- >> Best regards, >> Daniel >> >> - >> 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: Native WebSockets - cookies and last handler question
On Wed, Dec 23, 2015 at 3:41 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > On Wed, Dec 23, 2015 at 2:52 PM, Daniel Stoch <daniel.st...@gmail.com> > wrote: > >> On Wed, Dec 23, 2015 at 2:34 PM, Martin Grigorov <mgrigo...@apache.org> >> wrote: >> > Hi, >> > >> > >> > On Wed, Dec 23, 2015 at 2:21 PM, Daniel Stoch <daniel.st...@gmail.com> >> > wrote: >> > >> >> Hi, >> >> >> >> I am during replacement Atmosphere push implementation to Wicket >> >> Native WebSockets. I have an abstraction layer over it, so I can >> >> replace only implementation and easily switch between these two >> >> solutions and compare them. I have a couple of questions about Native >> >> WebSockets: >> >> >> >> 1. In WebSocketResponse many methods throws >> >> UnsupportedOperationException. I have a situation when component sets >> >> cookie during its lifecycle, so this exeption is raised when it is >> >> refreshed during push response. Is it any chance to implement these >> >> methods or do they necessary throw exceptions? In Atmosphere >> >> implementation this works. >> >> >> > >> > Although an HTTP request is being *upgraded* to WebSocket, the websocket >> > response is not an HTTP response. >> > You can only write String and binary data that is processed by the >> > application client code. The browser doesn't read/intercept the data >> > transfered on the websocket connection so any headers (like cookies) >> could >> > not be processed. >> > >> > We could change the impl to log a warning whenever one of those methods >> is >> > used instead of throwing exception. >> > Just like >> > >> https://github.com/apache/wicket/commit/8a5508e117991faf43f53d770b64568842d8d557 >> > Please file a ticket if you think this is a better implementation. >> >> Logging a warning is not a good solution in my case, because when I >> call addCookie() I don't know if current response implementation >> supports it or not (to avoid logging warns). So there will be many >> unnecessary WARN logs in my application. So a better solution for me >> is simply do nothing (empty mehod). I think it is probably not a good >> solution for you, but as I can see in WICKET-5737 there is a factory >> method for the WebSocketResponse so I will be able to use my own >> implementation of WebSocketResponse where addCookie() will not throws >> exception. >> Can this patch be backported to 6.x? >> > > Sure. Please file a ticket. WICKET-6054 >> >> 2. I have a code which checks >> >> PageRequestHandlerTracker.getLastHandler(requestCycle) to get actual >> >> page for current request (is it a best method?). During processing >> >> push request this method returns null. Is it a correct behavior? In >> >> Atmosphere implementation this works too ;). >> >> >> > >> > I think this should work. >> > There must be a bug somewhere. >> >> What should I check, how to investigate it? >> > > Put a breakpoint at > https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L237 > and see why the request cycle listeners are not notified. This probably has been fixed in WICKET-5701 (in 6.18.0). I am using 6.17.0 and there is not scheduleRequestHandlerAfterCurrent() call. So I have to upgrade and then check if it works ok. Thanks for your help! -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: FormComponent.getConvertedInput() for multiple choice components
> this required check will always be true. Will always be FALSE of course :) -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
FormComponent.getConvertedInput() for multiple choice components
Hi,
What contract should be for FormComponent.getConvertedInput() method,
for components like ListMultipleChoice, which operates on Collection
of objects? When there are no selected values this method (exactly:
convertedInput field) should be set on empty Collection (0 sized) or
null object?
For ListMultipleChoice it is set to empty list but such behavior leads
to a problem in FormComponents.validate() method:
if (isRequired() && getConvertedInput() == null && isInputNullable())
{
reportRequiredError();
}
else
{
validateValidators();
}
where there is a condition to check if getConvertedInput() is null. So
for required field when its value is selected but not available in
list anymore, this required check will always be true. So even such
field has no value, required message will not be displayed and form
will be submitted.
--
Daniel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: AtmosphereBehavior - hard reference to page object
Hi, AtmosphereBehavior extends AbstractAjaxBehavior which has a component field - so this holds a reference to a component, so also to its page (using parent relationships). AtmosphereBehavior in onRequest() method registers itself as a listener to Meteor object: ... Meteor meteor = Meteor.build(request.getContainerRequest()); // Add us to the listener list. meteor.addListener(this); ... So until atmosphere resource hold in meteor expires, it keeps a hard reference to our behavior so also to a page. It can be a problem in heavy load applications (with many users), where many atmosphere resources are created. -- Daniel On Mon, Aug 10, 2015 at 1:38 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, Can you point in the code where this happens? Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Aug 10, 2015 at 11:34 AM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, Ok, EventBus stores only pageId. But Atmosphere framework keeps all AtmosphereResourceEventListeners which are implemented by AtmosphereBehavior - so I think this is a place when Atmosphere keeps references to all registered pages. -- Daniel On Tue, Jul 28, 2015 at 9:33 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, I see no problem here. Wicket-Atmosphere keeps the pageId, not the page: https://github.com/apache/wicket/blob/3eba671c0770b0167f2d83ebf8924b28917316c9/wicket-experimental/wicket-atmosphere/src/main/java/org/apache/wicket/atmosphere/EventBus.java#L253 Later uses it at https://github.com/apache/wicket/blob/3eba671c0770b0167f2d83ebf8924b28917316c9/wicket-experimental/wicket-atmosphere/src/main/java/org/apache/wicket/atmosphere/AtmosphereRequestHandler.java#L76 Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Jul 20, 2015 at 1:54 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, In Wicket (AFAIK) we keeps only actual page reference in a web session, all other pages as serialized to a page store. AtmosphereBehavior registers itself as a listener to AtmosphereResource object. Because of this Atmosphere keeps references to all registered pages (until such resource expires). I think it could be a problem in high load applications: theses hard references could eat all memory. What do you think: is it a problem or not (and I am wrong in this case)? -- Best regards, Daniel - 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: AtmosphereBehavior - hard reference to page object
Ok, I will try to prepare a fix for this. Then I will create a JIRA issue for this with this fix. -- Daniel On Tue, Aug 11, 2015 at 12:55 PM, Martin Grigorov mgrigo...@apache.org wrote: Thanks! Do you want to contribute an improvement? For example we can extract a class that will be listener. In its onXyz() callbacks it will use the pageId to lookup the page, then it will search for an AtmosphereBehavior in the page to do its job (if this is required). Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Aug 11, 2015 at 1:20 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, AtmosphereBehavior extends AbstractAjaxBehavior which has a component field - so this holds a reference to a component, so also to its page (using parent relationships). AtmosphereBehavior in onRequest() method registers itself as a listener to Meteor object: ... Meteor meteor = Meteor.build(request.getContainerRequest()); // Add us to the listener list. meteor.addListener(this); ... So until atmosphere resource hold in meteor expires, it keeps a hard reference to our behavior so also to a page. It can be a problem in heavy load applications (with many users), where many atmosphere resources are created. -- Daniel On Mon, Aug 10, 2015 at 1:38 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, Can you point in the code where this happens? Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Aug 10, 2015 at 11:34 AM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, Ok, EventBus stores only pageId. But Atmosphere framework keeps all AtmosphereResourceEventListeners which are implemented by AtmosphereBehavior - so I think this is a place when Atmosphere keeps references to all registered pages. -- Daniel On Tue, Jul 28, 2015 at 9:33 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, I see no problem here. Wicket-Atmosphere keeps the pageId, not the page: https://github.com/apache/wicket/blob/3eba671c0770b0167f2d83ebf8924b28917316c9/wicket-experimental/wicket-atmosphere/src/main/java/org/apache/wicket/atmosphere/EventBus.java#L253 Later uses it at https://github.com/apache/wicket/blob/3eba671c0770b0167f2d83ebf8924b28917316c9/wicket-experimental/wicket-atmosphere/src/main/java/org/apache/wicket/atmosphere/AtmosphereRequestHandler.java#L76 Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Jul 20, 2015 at 1:54 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, In Wicket (AFAIK) we keeps only actual page reference in a web session, all other pages as serialized to a page store. AtmosphereBehavior registers itself as a listener to AtmosphereResource object. Because of this Atmosphere keeps references to all registered pages (until such resource expires). I think it could be a problem in high load applications: theses hard references could eat all memory. What do you think: is it a problem or not (and I am wrong in this case)? -- Best regards, Daniel - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AtmosphereBehavior - hard reference to page object
Hi, Ok, EventBus stores only pageId. But Atmosphere framework keeps all AtmosphereResourceEventListeners which are implemented by AtmosphereBehavior - so I think this is a place when Atmosphere keeps references to all registered pages. -- Daniel On Tue, Jul 28, 2015 at 9:33 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, I see no problem here. Wicket-Atmosphere keeps the pageId, not the page: https://github.com/apache/wicket/blob/3eba671c0770b0167f2d83ebf8924b28917316c9/wicket-experimental/wicket-atmosphere/src/main/java/org/apache/wicket/atmosphere/EventBus.java#L253 Later uses it at https://github.com/apache/wicket/blob/3eba671c0770b0167f2d83ebf8924b28917316c9/wicket-experimental/wicket-atmosphere/src/main/java/org/apache/wicket/atmosphere/AtmosphereRequestHandler.java#L76 Martin Grigorov Freelancer. Available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Jul 20, 2015 at 1:54 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, In Wicket (AFAIK) we keeps only actual page reference in a web session, all other pages as serialized to a page store. AtmosphereBehavior registers itself as a listener to AtmosphereResource object. Because of this Atmosphere keeps references to all registered pages (until such resource expires). I think it could be a problem in high load applications: theses hard references could eat all memory. What do you think: is it a problem or not (and I am wrong in this case)? -- Best regards, Daniel - 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
AtmosphereBehavior - hard reference to page object
Hi, In Wicket (AFAIK) we keeps only actual page reference in a web session, all other pages as serialized to a page store. AtmosphereBehavior registers itself as a listener to AtmosphereResource object. Because of this Atmosphere keeps references to all registered pages (until such resource expires). I think it could be a problem in high load applications: theses hard references could eat all memory. What do you think: is it a problem or not (and I am wrong in this case)? -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
How to get request/page parameters from RequestCycle?
Hi, In Wicket 1.4 I can get a page parameter value using this code: PageParameters pageParameters = requestCycle.getPageParameters(); String value = pageParameters.getString(paramName); The problem is that in Wicket 6 there is no equivalent. I have tried with this solution: IRequestParameters requestParameters = requestCycle.getRequest().getRequestParameters(); String value = requestParameters.getParameterValue(paramName).toString(); but this does not work. These requestParameters does not contain parameters. I think the problem is related to url encoding strategy which is used. My urls are encoded like: somepath/param1/value1/param2/value2 Is there another way to do this? -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to get request/page parameters from RequestCycle?
Well this workaround from my previous post does not work, because this
page does not exists yet when I need to get this parameter value.
--
Daniel
On Mon, Jan 19, 2015 at 4:16 PM, Daniel Stoch daniel.st...@gmail.com wrote:
Maybe such workaround (not very elegant though):
app.init():
getRequestCycleListeners().add(new PageRequestHandlerTracker());
private Page getCurrentPage(RequestCycle requestCycle) {
IPageRequestHandler pageRequestHandler =
PageRequestHandlerTracker.getLastHandler(requestCycle);
if ((pageRequestHandler != null) (pageRequestHandler.getPage()
instanceof Page)) {
Page page = (Page)pageRequestHandler.getPage();
return page;
}
return null;
}
Page page = getCurrentPage(requestCycle.getPageParameters());
if (page != null) {
PageParameters pageParameters =
getCurrentPage(requestCycle.getPageParameters());
String value = pageParameters.getString(paramName);
} ...
?
--
Daniel
On Mon, Jan 19, 2015 at 3:38 PM, Daniel Stoch daniel.st...@gmail.com wrote:
Hi,
In Wicket 1.4 I can get a page parameter value using this code:
PageParameters pageParameters = requestCycle.getPageParameters();
String value = pageParameters.getString(paramName);
The problem is that in Wicket 6 there is no equivalent. I have tried
with this solution:
IRequestParameters requestParameters =
requestCycle.getRequest().getRequestParameters();
String value = requestParameters.getParameterValue(paramName).toString();
but this does not work. These requestParameters does not contain
parameters. I think the problem is related to url encoding strategy
which is used. My urls are encoded like:
somepath/param1/value1/param2/value2
Is there another way to do this?
--
Best regards,
Daniel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to get request/page parameters from RequestCycle?
On Mon, Jan 19, 2015 at 4:54 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, On Mon, Jan 19, 2015 at 4:38 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, In Wicket 1.4 I can get a page parameter value using this code: PageParameters pageParameters = requestCycle.getPageParameters(); String value = pageParameters.getString(paramName); The problem is that in Wicket 6 there is no equivalent. I have tried with this solution: IRequestParameters requestParameters = requestCycle.getRequest().getRequestParameters(); String value = requestParameters.getParameterValue(paramName).toString(); request.getQueryParameters() is the equivalent, but #getRequestParameters() would work too because it is a mix of GET and POST parameters But I think it does not work with UrlPathPageParametersEncoder. but this does not work. These requestParameters does not contain parameters. I think the problem is related to url encoding strategy which is used. My urls are encoded like: somepath/param1/value1/param2/value2 Check org.apache.wicket.request.mapper.parameter.UrlPathPageParametersEncoder Ok, but how should I get url argument? requestCycle.getRequest().getUrl() return null for me. Another, minor, problem is that with this solution I have a hard coded page parameters encoder here. In previous version the code can be universal: it does not matter which encoding strategies page is using. For now if there will be pages with different encoding strategies this code stops working. -- Daniel Is there another way to do this? -- Best regards, Daniel - 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: How to get request/page parameters from RequestCycle?
Sorry, my fault - I forgot to pass a parameter. So: requestCycle.getRequest().getUrl() returns full path including mountpath and parameters, eg.: somepath/param1/value1 But if I pass this to UrlPathPageParametersEncoder.decodePageParameters() this decodes somepath as a first argument. On Mon, Jan 19, 2015 at 5:12 PM, Daniel Stoch daniel.st...@gmail.com wrote: requestCycle.getRequest().getUrl() return null for me. - sorry, not null but returns only a mount path without paramname/paramvalue part. On Mon, Jan 19, 2015 at 5:09 PM, Daniel Stoch daniel.st...@gmail.com wrote: On Mon, Jan 19, 2015 at 4:54 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, On Mon, Jan 19, 2015 at 4:38 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, In Wicket 1.4 I can get a page parameter value using this code: PageParameters pageParameters = requestCycle.getPageParameters(); String value = pageParameters.getString(paramName); The problem is that in Wicket 6 there is no equivalent. I have tried with this solution: IRequestParameters requestParameters = requestCycle.getRequest().getRequestParameters(); String value = requestParameters.getParameterValue(paramName).toString(); request.getQueryParameters() is the equivalent, but #getRequestParameters() would work too because it is a mix of GET and POST parameters But I think it does not work with UrlPathPageParametersEncoder. but this does not work. These requestParameters does not contain parameters. I think the problem is related to url encoding strategy which is used. My urls are encoded like: somepath/param1/value1/param2/value2 Check org.apache.wicket.request.mapper.parameter.UrlPathPageParametersEncoder Ok, but how should I get url argument? requestCycle.getRequest().getUrl() return null for me. Another, minor, problem is that with this solution I have a hard coded page parameters encoder here. In previous version the code can be universal: it does not matter which encoding strategies page is using. For now if there will be pages with different encoding strategies this code stops working. -- Daniel Is there another way to do this? -- Best regards, Daniel - 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: How to get request/page parameters from RequestCycle?
Maybe such workaround (not very elegant though):
app.init():
getRequestCycleListeners().add(new PageRequestHandlerTracker());
private Page getCurrentPage(RequestCycle requestCycle) {
IPageRequestHandler pageRequestHandler =
PageRequestHandlerTracker.getLastHandler(requestCycle);
if ((pageRequestHandler != null) (pageRequestHandler.getPage()
instanceof Page)) {
Page page = (Page)pageRequestHandler.getPage();
return page;
}
return null;
}
Page page = getCurrentPage(requestCycle.getPageParameters());
if (page != null) {
PageParameters pageParameters =
getCurrentPage(requestCycle.getPageParameters());
String value = pageParameters.getString(paramName);
} ...
?
--
Daniel
On Mon, Jan 19, 2015 at 3:38 PM, Daniel Stoch daniel.st...@gmail.com wrote:
Hi,
In Wicket 1.4 I can get a page parameter value using this code:
PageParameters pageParameters = requestCycle.getPageParameters();
String value = pageParameters.getString(paramName);
The problem is that in Wicket 6 there is no equivalent. I have tried
with this solution:
IRequestParameters requestParameters =
requestCycle.getRequest().getRequestParameters();
String value = requestParameters.getParameterValue(paramName).toString();
but this does not work. These requestParameters does not contain
parameters. I think the problem is related to url encoding strategy
which is used. My urls are encoded like:
somepath/param1/value1/param2/value2
Is there another way to do this?
--
Best regards,
Daniel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to get request/page parameters from RequestCycle?
requestCycle.getRequest().getUrl() return null for me. - sorry, not null but returns only a mount path without paramname/paramvalue part. On Mon, Jan 19, 2015 at 5:09 PM, Daniel Stoch daniel.st...@gmail.com wrote: On Mon, Jan 19, 2015 at 4:54 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, On Mon, Jan 19, 2015 at 4:38 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, In Wicket 1.4 I can get a page parameter value using this code: PageParameters pageParameters = requestCycle.getPageParameters(); String value = pageParameters.getString(paramName); The problem is that in Wicket 6 there is no equivalent. I have tried with this solution: IRequestParameters requestParameters = requestCycle.getRequest().getRequestParameters(); String value = requestParameters.getParameterValue(paramName).toString(); request.getQueryParameters() is the equivalent, but #getRequestParameters() would work too because it is a mix of GET and POST parameters But I think it does not work with UrlPathPageParametersEncoder. but this does not work. These requestParameters does not contain parameters. I think the problem is related to url encoding strategy which is used. My urls are encoded like: somepath/param1/value1/param2/value2 Check org.apache.wicket.request.mapper.parameter.UrlPathPageParametersEncoder Ok, but how should I get url argument? requestCycle.getRequest().getUrl() return null for me. Another, minor, problem is that with this solution I have a hard coded page parameters encoder here. In previous version the code can be universal: it does not matter which encoding strategies page is using. For now if there will be pages with different encoding strategies this code stops working. -- Daniel Is there another way to do this? -- Best regards, Daniel - 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: How to get request/page parameters from RequestCycle?
This code is called inside custom DefaultMapperContext.newPageInstance() implementation and in custom IRequestMapper.mapRequest() method. -- Daniel On Mon, Jan 19, 2015 at 5:22 PM, Martin Grigorov mgrigo...@apache.org wrote: In what context do you need to extract these parameters ? In what class is this code ? Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Jan 19, 2015 at 6:20 PM, Daniel Stoch daniel.st...@gmail.com wrote: Sorry, my fault - I forgot to pass a parameter. So: requestCycle.getRequest().getUrl() returns full path including mountpath and parameters, eg.: somepath/param1/value1 But if I pass this to UrlPathPageParametersEncoder.decodePageParameters() this decodes somepath as a first argument. On Mon, Jan 19, 2015 at 5:12 PM, Daniel Stoch daniel.st...@gmail.com wrote: requestCycle.getRequest().getUrl() return null for me. - sorry, not null but returns only a mount path without paramname/paramvalue part. On Mon, Jan 19, 2015 at 5:09 PM, Daniel Stoch daniel.st...@gmail.com wrote: On Mon, Jan 19, 2015 at 4:54 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, On Mon, Jan 19, 2015 at 4:38 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, In Wicket 1.4 I can get a page parameter value using this code: PageParameters pageParameters = requestCycle.getPageParameters(); String value = pageParameters.getString(paramName); The problem is that in Wicket 6 there is no equivalent. I have tried with this solution: IRequestParameters requestParameters = requestCycle.getRequest().getRequestParameters(); String value = requestParameters.getParameterValue(paramName).toString(); request.getQueryParameters() is the equivalent, but #getRequestParameters() would work too because it is a mix of GET and POST parameters But I think it does not work with UrlPathPageParametersEncoder. but this does not work. These requestParameters does not contain parameters. I think the problem is related to url encoding strategy which is used. My urls are encoded like: somepath/param1/value1/param2/value2 Check org.apache.wicket.request.mapper.parameter.UrlPathPageParametersEncoder Ok, but how should I get url argument? requestCycle.getRequest().getUrl() return null for me. Another, minor, problem is that with this solution I have a hard coded page parameters encoder here. In previous version the code can be universal: it does not matter which encoding strategies page is using. For now if there will be pages with different encoding strategies this code stops working. -- Daniel Is there another way to do this? -- Best regards, Daniel - 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: How to get request/page parameters from RequestCycle?
I have found another solution: in my scenario I can get parameters from DefaultMapperContext. newPageInstance(). Thanks for your help and tips. -- Daniel On Mon, Jan 19, 2015 at 5:44 PM, Daniel Stoch daniel.st...@gmail.com wrote: This code is called inside custom DefaultMapperContext.newPageInstance() implementation and in custom IRequestMapper.mapRequest() method. -- Daniel On Mon, Jan 19, 2015 at 5:22 PM, Martin Grigorov mgrigo...@apache.org wrote: In what context do you need to extract these parameters ? In what class is this code ? Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Jan 19, 2015 at 6:20 PM, Daniel Stoch daniel.st...@gmail.com wrote: Sorry, my fault - I forgot to pass a parameter. So: requestCycle.getRequest().getUrl() returns full path including mountpath and parameters, eg.: somepath/param1/value1 But if I pass this to UrlPathPageParametersEncoder.decodePageParameters() this decodes somepath as a first argument. On Mon, Jan 19, 2015 at 5:12 PM, Daniel Stoch daniel.st...@gmail.com wrote: requestCycle.getRequest().getUrl() return null for me. - sorry, not null but returns only a mount path without paramname/paramvalue part. On Mon, Jan 19, 2015 at 5:09 PM, Daniel Stoch daniel.st...@gmail.com wrote: On Mon, Jan 19, 2015 at 4:54 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, On Mon, Jan 19, 2015 at 4:38 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, In Wicket 1.4 I can get a page parameter value using this code: PageParameters pageParameters = requestCycle.getPageParameters(); String value = pageParameters.getString(paramName); The problem is that in Wicket 6 there is no equivalent. I have tried with this solution: IRequestParameters requestParameters = requestCycle.getRequest().getRequestParameters(); String value = requestParameters.getParameterValue(paramName).toString(); request.getQueryParameters() is the equivalent, but #getRequestParameters() would work too because it is a mix of GET and POST parameters But I think it does not work with UrlPathPageParametersEncoder. but this does not work. These requestParameters does not contain parameters. I think the problem is related to url encoding strategy which is used. My urls are encoded like: somepath/param1/value1/param2/value2 Check org.apache.wicket.request.mapper.parameter.UrlPathPageParametersEncoder Ok, but how should I get url argument? requestCycle.getRequest().getUrl() return null for me. Another, minor, problem is that with this solution I have a hard coded page parameters encoder here. In previous version the code can be universal: it does not matter which encoding strategies page is using. For now if there will be pages with different encoding strategies this code stops working. -- Daniel Is there another way to do this? -- Best regards, Daniel - 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: Change in configuring AtmosphereServlet init-params
Thanks for your answers. I must check why this new version does not work in my app. -- Best regards, Daniel On Mon, Jan 12, 2015 at 1:00 PM, Emond Papegaaij emond.papega...@topicus.nl wrote: You are right. The filter allows the client to know the length of pushed messages. I believe it was also needed for very long messages. The problem with the default filter was, that the separator was far too common to use for wicket's Ajax responses and the default implementation did not offer a way to change the separator. This was fixed in recent versions of Atmosphere. In fact, changes to the API broke the old one, so I needed to replace it with the improved default. Best regards, Emond On Sunday 11 January 2015 21:54:36 Martin Grigorov wrote: Only Emond knows the details ... AFAIK TrackMessageSizeFilter was needed to overcome a problem in Atmosphere + Wicket's XML response. It seems Atmosphere 2.20+ provides the solution by itself so Wicket's one is not needed anymore. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Jan 9, 2015 at 3:41 PM, Daniel Stoch daniel.st...@gmail.com wrote: On Fri, Jan 9, 2015 at 2:37 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, I think this changes was needed to upgrade from Atmosphere 2.18 to 2.22. AFAIK this change is needed by Atmosphere itself. Wicket-Atmosphere doesn't use these parameters. Ok, I know that. But how did you (or Emond ;)) know how to changed it, maybe I should look into Atmosphere documentation? The old TrackMessageSizeFilter comes from Wicket-Atmosphere, so there was some reason to setup such parameter. -- Daniel Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Jan 9, 2015 at 11:07 AM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, In the most recent version of atmosphere-example the init-params were changed in servlet configuration (in web.xml). From: init-param param-nameorg.atmosphere.cpr.broadcastFilterClasses/param-name param-valueorg.apache.wicket.atmosphere.TrackMessageSizeFilter/param-va lue /init-param To: init-param param-nameorg.atmosphere.cpr.AtmosphereInterceptor/param-name param-valueorg.atmosphere.client.TrackMessageSizeInterceptor/param-valu e /init-param init-param param-nameorg.atmosphere.client.TrackMessageSizeInterceptor.delimiter/p aram-name param-value![CDATA[|msg|]]/param-value /init-param What is the reason of this change, what these parameters are used for? Actual version does not work for me and I need to know how to debug this. Any tip will be helpful. -- Best regards, Daniel - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Change in configuring AtmosphereServlet init-params
Hi, In the most recent version of atmosphere-example the init-params were changed in servlet configuration (in web.xml). From: init-param param-nameorg.atmosphere.cpr.broadcastFilterClasses/param-name param-valueorg.apache.wicket.atmosphere.TrackMessageSizeFilter/param-value /init-param To: init-param param-nameorg.atmosphere.cpr.AtmosphereInterceptor/param-name param-valueorg.atmosphere.client.TrackMessageSizeInterceptor/param-value /init-param init-param param-nameorg.atmosphere.client.TrackMessageSizeInterceptor.delimiter/param-name param-value![CDATA[|msg|]]/param-value /init-param What is the reason of this change, what these parameters are used for? Actual version does not work for me and I need to know how to debug this. Any tip will be helpful. -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Change in configuring AtmosphereServlet init-params
On Fri, Jan 9, 2015 at 2:37 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, I think this changes was needed to upgrade from Atmosphere 2.18 to 2.22. AFAIK this change is needed by Atmosphere itself. Wicket-Atmosphere doesn't use these parameters. Ok, I know that. But how did you (or Emond ;)) know how to changed it, maybe I should look into Atmosphere documentation? The old TrackMessageSizeFilter comes from Wicket-Atmosphere, so there was some reason to setup such parameter. -- Daniel Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Jan 9, 2015 at 11:07 AM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, In the most recent version of atmosphere-example the init-params were changed in servlet configuration (in web.xml). From: init-param param-nameorg.atmosphere.cpr.broadcastFilterClasses/param-name param-valueorg.apache.wicket.atmosphere.TrackMessageSizeFilter/param-value /init-param To: init-param param-nameorg.atmosphere.cpr.AtmosphereInterceptor/param-name param-valueorg.atmosphere.client.TrackMessageSizeInterceptor/param-value /init-param init-param param-nameorg.atmosphere.client.TrackMessageSizeInterceptor.delimiter/param-name param-value![CDATA[|msg|]]/param-value /init-param What is the reason of this change, what these parameters are used for? Actual version does not work for me and I need to know how to debug this. Any tip will be helpful. -- Best regards, Daniel - 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
Synchonization problems? (Cannot modify component hierarchy after render phase has started)
Hi, Is it possible that there is some issue with simultaneous access to a page by different threads using wicket-atmosphere integration? From time to time, when system send many server events to page, such error can occurs - in onConfigure method I call setVisible on some children components: org.apache.wicket.WicketRuntimeException: Cannot modify component hierarchy after render phase has started (page version cant change then anymore) at org.apache.wicket.Component.checkHierarchyChange(Component.java:3557) at org.apache.wicket.Component.addStateChange(Component.java:3486) at org.apache.wicket.Component.setVisible(Component.java:3173) at myapp.MyPanel.onConfigure(MyPanel.java:83) at org.apache.wicket.Component.configure(Component.java:1041) at org.apache.wicket.Component.internalBeforeRender(Component.java:926) at org.apache.wicket.Component.beforeRender(Component.java:1003) at org.apache.wicket.Component.internalPrepareForRender(Component.java:2179) at org.apache.wicket.Component.render(Component.java:2268) at org.apache.wicket.ajax.XmlAjaxResponse.writeComponent(XmlAjaxResponse.java:128) at org.apache.wicket.ajax.AbstractAjaxResponse.writeComponents(AbstractAjaxResponse.java:218) at org.apache.wicket.ajax.AbstractAjaxResponse.writeTo(AbstractAjaxResponse.java:150) at org.apache.wicket.ajax.AjaxRequestHandler.respond(AjaxRequestHandler.java:359) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:97) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) at org.apache.wicket.atmosphere.EventBus.post(EventBus.java:417) at org.apache.wicket.atmosphere.EventBus.postToSingleResource(EventBus.java:393) at org.apache.wicket.atmosphere.EventBus.post(EventBus.java:346) at org.apache.wicket.atmosphere.EventBus.post(EventBus.java:329) So it looks that some thread earlier mark this component as rendering? -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to call onResourceRequested for page behavior in ajax update (Atmosphere related)
Hi, Ok, I think I didn't described a problem well. When you add a component which subscribes some events, then AtmosphereBehavior is added to page. But the wicketAtmosphere JS callback is registered inside AtmosphereBehavior.renderHead() method, so only (I think) when the whole page is rendered. When you add a component using ajax, then this code (renderHead) is not called, so events are not broadcasted to client: because page is not registered in EventBus and does not have atmosphere resource assigned. So maybe my original question should be: how to invode this JS callback from AtmosphereBehavior.renderHead in ajax requests? -- Daniel On Wed, Dec 10, 2014 at 12:19 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, It seems that I am using an older version of AtmosphereBehavior which implements IResourceListener. Since 6.17.0 this implementation was removed and the code is moved to onRequest() method. So I must check a newer version, maybe my problem is solved. Thanks for a tip! -- Daniel On Wed, Dec 10, 2014 at 11:03 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, Please give more details. https://github.com/apache/wicket/blob/master/wicket-experimental/wicket-atmosphere/src/main/java/org/apache/wicket/atmosphere/AtmosphereBehavior.java#L51 doesn't implement IResourceListener, so it seems you do something custom. Just implementing IResourceListener doesn't mean anything to Wicket. You need to create a callback url with org.apache.wicket.Component#urlFor(org.apache.wicket.RequestListenerInterface, org.apache.wicket.request.mapper.parameter.PageParameters) and use it somehow to invoke org.apache.wicket.IResourceListener#onResourceRequested Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Dec 10, 2014 at 11:45 AM, Daniel Stoch daniel.st...@gmail.com wrote: Is it possible to invoke this listener manually, or maybe this is a generally a bad practise? -- Daniel On 9 gru 2014, at 12:24, Daniel Stoch daniel.st...@gmail.com wrote: Hi, I have a behavior which implements IResourceListener (AtmosphereBehavior). The problem is when this behavior is added to page during ajax request (eg. some panel is dynamically added to page) - then onResourceRequested is not invoked for page. So when using AtmosphereBehavior the suspended connection from the client is not registered. How should I solve this problem: how and when call this onResourceRequested method? -- Best regards, Daniel - 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: How to call onResourceRequested for page behavior in ajax update (Atmosphere related)
On Fri, Dec 12, 2014 at 11:38 AM, Martin Grigorov mgrigo...@apache.org wrote:
I see it is a bit ugly, but oh well... this is how it works now.
in YourComponent#renderHead():
AtmosphereBehavior atmo =
getPage().getBehaviors(AtmosphereBehavior.class).get(0);
CharSequence callbackUrl = atmo.getCallbackUrl();
headerResponse.render(OnDomReadyHeaderItem.forScript(Wicket.Ajax.get({u:
+callbackUrl+})));
Thanks, it works.
But I call whole atmo.renderHead(page, response); method.
You may need to use some flag to make sure this happens once per page
instance. Otherwise every re-render of such component will initialize a new
web socket connection (or whatever fallback you may use)
Hmmm, do we really need this check if I call whole atmo.renderHead method?
Thanks for your help.
--
Daniel
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Dec 12, 2014 at 11:36 AM, Daniel Stoch daniel.st...@gmail.com
wrote:
Hi,
Ok, I think I didn't described a problem well.
When you add a component which subscribes some events, then
AtmosphereBehavior is added to page. But the wicketAtmosphere JS
callback is registered inside AtmosphereBehavior.renderHead() method,
so only (I think) when the whole page is rendered. When you add a
component using ajax, then this code (renderHead) is not called, so
events are not broadcasted to client: because page is not registered
in EventBus and does not have atmosphere resource assigned.
So maybe my original question should be: how to invode this JS
callback from AtmosphereBehavior.renderHead in ajax requests?
--
Daniel
On Wed, Dec 10, 2014 at 12:19 PM, Daniel Stoch daniel.st...@gmail.com
wrote:
Hi,
It seems that I am using an older version of AtmosphereBehavior which
implements IResourceListener. Since 6.17.0 this implementation was
removed and the code is moved to onRequest() method.
So I must check a newer version, maybe my problem is solved.
Thanks for a tip!
--
Daniel
On Wed, Dec 10, 2014 at 11:03 AM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi,
Please give more details.
https://github.com/apache/wicket/blob/master/wicket-experimental/wicket-atmosphere/src/main/java/org/apache/wicket/atmosphere/AtmosphereBehavior.java#L51
doesn't implement IResourceListener, so it seems you do something
custom.
Just implementing IResourceListener doesn't mean anything to Wicket.
You need to create a callback url with
org.apache.wicket.Component#urlFor(org.apache.wicket.RequestListenerInterface,
org.apache.wicket.request.mapper.parameter.PageParameters) and use it
somehow to invoke
org.apache.wicket.IResourceListener#onResourceRequested
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Dec 10, 2014 at 11:45 AM, Daniel Stoch daniel.st...@gmail.com
wrote:
Is it possible to invoke this listener manually, or maybe this is a
generally a bad practise?
--
Daniel
On 9 gru 2014, at 12:24, Daniel Stoch daniel.st...@gmail.com
wrote:
Hi,
I have a behavior which implements IResourceListener
(AtmosphereBehavior). The problem is when this behavior is added to
page during ajax request (eg. some panel is dynamically added to
page)
- then onResourceRequested is not invoked for page. So when using
AtmosphereBehavior the suspended connection from the client is not
registered.
How should I solve this problem: how and when call this
onResourceRequested method?
--
Best regards,
Daniel
-
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: How to call onResourceRequested for page behavior in ajax update (Atmosphere related)
Is it possible to invoke this listener manually, or maybe this is a generally a bad practise? -- Daniel On 9 gru 2014, at 12:24, Daniel Stoch daniel.st...@gmail.com wrote: Hi, I have a behavior which implements IResourceListener (AtmosphereBehavior). The problem is when this behavior is added to page during ajax request (eg. some panel is dynamically added to page) - then onResourceRequested is not invoked for page. So when using AtmosphereBehavior the suspended connection from the client is not registered. How should I solve this problem: how and when call this onResourceRequested method? -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to call onResourceRequested for page behavior in ajax update (Atmosphere related)
Hi, It seems that I am using an older version of AtmosphereBehavior which implements IResourceListener. Since 6.17.0 this implementation was removed and the code is moved to onRequest() method. So I must check a newer version, maybe my problem is solved. Thanks for a tip! -- Daniel On Wed, Dec 10, 2014 at 11:03 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, Please give more details. https://github.com/apache/wicket/blob/master/wicket-experimental/wicket-atmosphere/src/main/java/org/apache/wicket/atmosphere/AtmosphereBehavior.java#L51 doesn't implement IResourceListener, so it seems you do something custom. Just implementing IResourceListener doesn't mean anything to Wicket. You need to create a callback url with org.apache.wicket.Component#urlFor(org.apache.wicket.RequestListenerInterface, org.apache.wicket.request.mapper.parameter.PageParameters) and use it somehow to invoke org.apache.wicket.IResourceListener#onResourceRequested Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Dec 10, 2014 at 11:45 AM, Daniel Stoch daniel.st...@gmail.com wrote: Is it possible to invoke this listener manually, or maybe this is a generally a bad practise? -- Daniel On 9 gru 2014, at 12:24, Daniel Stoch daniel.st...@gmail.com wrote: Hi, I have a behavior which implements IResourceListener (AtmosphereBehavior). The problem is when this behavior is added to page during ajax request (eg. some panel is dynamically added to page) - then onResourceRequested is not invoked for page. So when using AtmosphereBehavior the suspended connection from the client is not registered. How should I solve this problem: how and when call this onResourceRequested method? -- Best regards, Daniel - 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
How to call onResourceRequested for page behavior in ajax update (Atmosphere related)
Hi, I have a behavior which implements IResourceListener (AtmosphereBehavior). The problem is when this behavior is added to page during ajax request (eg. some panel is dynamically added to page) - then onResourceRequested is not invoked for page. So when using AtmosphereBehavior the suspended connection from the client is not registered. How should I solve this problem: how and when call this onResourceRequested method? -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket-Ajax-BaseURL encoding problem when uploading file using ajax
Hi, I have a strange error when uploading file using ajax request. I have a page with parameters whit url like: http://localhost:8080/myapp/customer/id/1234 When I am opening a modal window with upload form the Wicket-Ajax-BaseURL is: customer/id/1234?1 and all links in ajax response are properly constructed, eg.: ../../wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-event-jquery-ver-140930656.js But when I choose a file and press upload (using AjaxSubmitButton) then in the followed request Wicket-Ajax-BaseURL is encoded like: customer%2Fid%2F1234 so the code inside UrlRenderer.renderRelativeUrl does not find a proper baseUrlSegments so the calculated renderedUrl is wrong. This leads to invalid url paths, eg.: ./wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-event-jquery-ver-140930656.js and other errors with resolving urls. I cannot find where this base url can be broken? Maybe the problem is somewhere in my code, but I don't know where to search for this. PS. The same error is in FF and Chrome. Wicket 6.17.0. -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket-Ajax-BaseURL encoding problem when uploading file using ajax
I think the problem is in POST request when submitting a form. In wicket-ajax-jquery.js wicket-ajax-baseurl parametr is appended to request url. It is encoded using Wicket.Form.encode: form.action = attrs.u + separator + wicket-ajax=truewicket-ajax-baseurl= + Wicket.Form.encode(getAjaxBaseUrl()); After this an url becomes encoded using escaped %2F instead of slashes (eg. customer%2Fid%2F1234). This leads to resolving urls problems, as I have described in my previous post. -- Best regards, Daniel On Fri, Nov 7, 2014 at 1:30 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, I have a strange error when uploading file using ajax request. I have a page with parameters whit url like: http://localhost:8080/myapp/customer/id/1234 When I am opening a modal window with upload form the Wicket-Ajax-BaseURL is: customer/id/1234?1 and all links in ajax response are properly constructed, eg.: ../../wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-event-jquery-ver-140930656.js But when I choose a file and press upload (using AjaxSubmitButton) then in the followed request Wicket-Ajax-BaseURL is encoded like: customer%2Fid%2F1234 so the code inside UrlRenderer.renderRelativeUrl does not find a proper baseUrlSegments so the calculated renderedUrl is wrong. This leads to invalid url paths, eg.: ./wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-event-jquery-ver-140930656.js and other errors with resolving urls. I cannot find where this base url can be broken? Maybe the problem is somewhere in my code, but I don't know where to search for this. PS. The same error is in FF and Chrome. Wicket 6.17.0. -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Add extra debug information to component markup
Hi, I want to add extra debug information to component markup or modify existing wicketpath info. For now it can be easily done by using a custom default IMarkupSourcingStrategy which has onComponentTag() method. But inside Component.getMarkupSourcingStrategy() the default strategy is get using a static call to a singleton DefaultMarkupSourcingStrategy.get(). Maybe there should be a method inside IMarkupSettings: IMarkupSourcingStrategy getDefaultMarkupSourcingStrategy() which can be used in Component.getMarkupSourcingStrategy() instead a direct call to DefaultMarkupSourcingStrategy.get(). Another solution is to invent another extension point to allow to customize all components tags, but this described above is very simple to implement I think. PS. I want to add some extra information about class names where every component come from (to allow developers, especially not GUI guys, to easily find a source code). -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Add extra debug information to component markup
You are fast :). I wanted to write about this solution - came to my mind right now :) -- Thanks, Daniel On Thu, Oct 2, 2014 at 12:38 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, You can use Behavior#onComponentTag(). And IComponentInstantiationListenener to add this behavior to all/some components. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Oct 2, 2014 at 12:35 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, I want to add extra debug information to component markup or modify existing wicketpath info. For now it can be easily done by using a custom default IMarkupSourcingStrategy which has onComponentTag() method. But inside Component.getMarkupSourcingStrategy() the default strategy is get using a static call to a singleton DefaultMarkupSourcingStrategy.get(). Maybe there should be a method inside IMarkupSettings: IMarkupSourcingStrategy getDefaultMarkupSourcingStrategy() which can be used in Component.getMarkupSourcingStrategy() instead a direct call to DefaultMarkupSourcingStrategy.get(). Another solution is to invent another extension point to allow to customize all components tags, but this described above is very simple to implement I think. PS. I want to add some extra information about class names where every component come from (to allow developers, especially not GUI guys, to easily find a source code). -- Daniel - 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: How to handle click on removed links - WicketRuntimeException (Component 'xxx' has been removed from page)?
I think the simplest solution for now (until we invent a better one) is to define a dedicated exception class for such case (similar to ListenerInvocationNotAllowedException which is raised if user tries click on disabled links). Then we can catch such exception and handle it eg. as described by Martin in my previous post (How to handle click on disabled links - ListenerInvocationNotAllowedException?). -- Daniel On Fri, Jul 4, 2014 at 5:38 PM, Ernesto Reinaldo Barreiro reier...@gmail.com wrote: maybe what is needed is a fail silently ajax request ;-) On Fri, Jul 4, 2014 at 5:36 PM, Ernesto Reinaldo Barreiro reier...@gmail.com wrote: Hi, On Fri, Jul 4, 2014 at 4:59 PM, Daniel Stoch daniel.st...@gmail.com wrote: Sorry, but for me all these solutions are hacks :). Why? As far as they are under control... Isn't software development production controlled hacks? Wicket itself is a hack and so do are other WEB frameworks like GWT. As far as you remain in control I do not see the problem. All frameworks have limitations... Why not get the best of them and circumvent those. I want to use standard components (eg. AjaxLink) to do simple things. I don't want to think everywhere how to handle such scenarios. It should be handled properly on a framework level. I think there is always possibility that component state on server and DOM tree on client browser are inconsistent (and not necessary because of push requests). Maybe it should be a dedicated exception on such situation (Component 'xxx' has been removed from page.) at least or maybe we can invent a better solution in core? I do agree that would be optimal. -- Daniel On Fri, Jul 4, 2014 at 4:11 PM, Ernesto Reinaldo Barreiro reier...@gmail.com wrote: Maybe you could even just push JSON to client side and generate items content at client side which is going to be way faster On Fri, Jul 4, 2014 at 4:06 PM, Ernesto Reinaldo Barreiro reier...@gmail.com wrote: Why don't you try routing all the click to a part of you application that is always available? E.g. 1- You have a list of items that are pushed... They are in a certain container that is always there... At client and server side 2- The items are pushed but instead of normal AJAX link you use link to the parent never changing container passing ID of item. This way click will never fail and it is still sort of object oriented... On Fri, Jul 4, 2014 at 3:59 PM, Daniel Stoch daniel.st...@gmail.com wrote: On Fri, Jul 4, 2014 at 3:14 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, You can use Atmopshere to hide/disable the client side too, not just the server side. Of course, I already do that. But user can click the link after state was changed on the server side but before these changes are pushed to client browser. -- Daniel Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Jul 4, 2014 at 1:46 PM, Daniel Stoch daniel.st...@gmail.com wrote: On Fri, Jul 4, 2014 at 12:33 PM, Sven Meier s...@meiers.net wrote: So page was rendered in a browser, on the server component tree was changed What triggers the change to the component tree? On which thread? Are you using websockets? Sven In general this thread is not initialized by user action but by application. So yes, it can be push from a server (eg. using Atmosphere - this is my case) or by ajax self updating behavior. -- DS On 07/04/2014 12:13 PM, Daniel Stoch wrote: Hi all, I think such question occurs from time to time on this list, but I have never found a good answer how to solve such problem in general. The problem is similar to my last question: http://apache-wicket.1842946.n4.nabble.com/How-to-handle-click-on-disabled-links-ListenerInvocationNotAllowedException-td4666287.html but now there is a situation when link was removed from page (not disabled). So page was rendered in a browser, on the server component tree was changed, but user clicks a link in a browser before this changes will be pushed to it. It leads to an exception: org.apache.wicket.WicketRuntimeException: Component 'xxx' has been removed from page. at org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:178) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218
How to handle click on removed links - WicketRuntimeException (Component 'xxx' has been removed from page)?
Hi all, I think such question occurs from time to time on this list, but I have never found a good answer how to solve such problem in general. The problem is similar to my last question: http://apache-wicket.1842946.n4.nabble.com/How-to-handle-click-on-disabled-links-ListenerInvocationNotAllowedException-td4666287.html but now there is a situation when link was removed from page (not disabled). So page was rendered in a browser, on the server component tree was changed, but user clicks a link in a browser before this changes will be pushed to it. It leads to an exception: org.apache.wicket.WicketRuntimeException: Component 'xxx' has been removed from page. at org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:178) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:735) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) How it should be properly handled in application? Unfortunately this is not a dedicated exception to catch somewhere, but a common WicketRuntimeException. -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to handle click on removed links - WicketRuntimeException (Component 'xxx' has been removed from page)?
This is a popular answer on such querstions (use veil and so on) :). But it is not the case here, because we do not know whet to block here. Beside this, in general I think it is not a good solution. On Fri, Jul 4, 2014 at 12:30 PM, Ernesto Reinaldo Barreiro reier...@gmail.com wrote: Block the UI? On Fri, Jul 4, 2014 at 12:13 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi all, I think such question occurs from time to time on this list, but I have never found a good answer how to solve such problem in general. The problem is similar to my last question: http://apache-wicket.1842946.n4.nabble.com/How-to-handle-click-on-disabled-links-ListenerInvocationNotAllowedException-td4666287.html but now there is a situation when link was removed from page (not disabled). So page was rendered in a browser, on the server component tree was changed, but user clicks a link in a browser before this changes will be pushed to it. It leads to an exception: org.apache.wicket.WicketRuntimeException: Component 'xxx' has been removed from page. at org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:178) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:735) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) How it should be properly handled in application? Unfortunately this is not a dedicated exception to catch somewhere, but a common WicketRuntimeException. -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Regards - Ernesto Reinaldo Barreiro - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to handle click on removed links - WicketRuntimeException (Component 'xxx' has been removed from page)?
On Fri, Jul 4, 2014 at 12:33 PM, Sven Meier s...@meiers.net wrote: So page was rendered in a browser, on the server component tree was changed What triggers the change to the component tree? On which thread? Are you using websockets? Sven In general this thread is not initialized by user action but by application. So yes, it can be push from a server (eg. using Atmosphere - this is my case) or by ajax self updating behavior. -- DS On 07/04/2014 12:13 PM, Daniel Stoch wrote: Hi all, I think such question occurs from time to time on this list, but I have never found a good answer how to solve such problem in general. The problem is similar to my last question: http://apache-wicket.1842946.n4.nabble.com/How-to-handle-click-on-disabled-links-ListenerInvocationNotAllowedException-td4666287.html but now there is a situation when link was removed from page (not disabled). So page was rendered in a browser, on the server component tree was changed, but user clicks a link in a browser before this changes will be pushed to it. It leads to an exception: org.apache.wicket.WicketRuntimeException: Component 'xxx' has been removed from page. at org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:178) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:735) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) How it should be properly handled in application? Unfortunately this is not a dedicated exception to catch somewhere, but a common WicketRuntimeException. -- Best regards, Daniel - 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: How to handle click on removed links - WicketRuntimeException (Component 'xxx' has been removed from page)?
I have added the appropriate information in that thread. On Fri, Jul 4, 2014 at 12:47 PM, Ernesto Reinaldo Barreiro reier...@gmail.com wrote: Sven's question goes straight to the point: do you know what is causing the mismacth? On Fri, Jul 4, 2014 at 12:44 PM, Daniel Stoch daniel.st...@gmail.com wrote: This is a popular answer on such querstions (use veil and so on) :). But it is not the case here, because we do not know whet to block here. Beside this, in general I think it is not a good solution. It works for me in many applications. On Fri, Jul 4, 2014 at 12:30 PM, Ernesto Reinaldo Barreiro reier...@gmail.com wrote: Block the UI? On Fri, Jul 4, 2014 at 12:13 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi all, I think such question occurs from time to time on this list, but I have never found a good answer how to solve such problem in general. The problem is similar to my last question: http://apache-wicket.1842946.n4.nabble.com/How-to-handle-click-on-disabled-links-ListenerInvocationNotAllowedException-td4666287.html but now there is a situation when link was removed from page (not disabled). So page was rendered in a browser, on the server component tree was changed, but user clicks a link in a browser before this changes will be pushed to it. It leads to an exception: org.apache.wicket.WicketRuntimeException: Component 'xxx' has been removed from page. at org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:178) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:735) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) How it should be properly handled in application? Unfortunately this is not a dedicated exception to catch somewhere, but a common WicketRuntimeException. -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Regards - Ernesto Reinaldo Barreiro - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Regards - Ernesto Reinaldo Barreiro - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to handle click on removed links - WicketRuntimeException (Component 'xxx' has been removed from page)?
On Fri, Jul 4, 2014 at 3:14 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, You can use Atmopshere to hide/disable the client side too, not just the server side. Of course, I already do that. But user can click the link after state was changed on the server side but before these changes are pushed to client browser. -- Daniel Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Jul 4, 2014 at 1:46 PM, Daniel Stoch daniel.st...@gmail.com wrote: On Fri, Jul 4, 2014 at 12:33 PM, Sven Meier s...@meiers.net wrote: So page was rendered in a browser, on the server component tree was changed What triggers the change to the component tree? On which thread? Are you using websockets? Sven In general this thread is not initialized by user action but by application. So yes, it can be push from a server (eg. using Atmosphere - this is my case) or by ajax self updating behavior. -- DS On 07/04/2014 12:13 PM, Daniel Stoch wrote: Hi all, I think such question occurs from time to time on this list, but I have never found a good answer how to solve such problem in general. The problem is similar to my last question: http://apache-wicket.1842946.n4.nabble.com/How-to-handle-click-on-disabled-links-ListenerInvocationNotAllowedException-td4666287.html but now there is a situation when link was removed from page (not disabled). So page was rendered in a browser, on the server component tree was changed, but user clicks a link in a browser before this changes will be pushed to it. It leads to an exception: org.apache.wicket.WicketRuntimeException: Component 'xxx' has been removed from page. at org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:178) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:735) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) How it should be properly handled in application? Unfortunately this is not a dedicated exception to catch somewhere, but a common WicketRuntimeException. -- Best regards, Daniel - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to handle click on removed links - WicketRuntimeException (Component 'xxx' has been removed from page)?
Sorry, but for me all these solutions are hacks :). I want to use standard components (eg. AjaxLink) to do simple things. I don't want to think everywhere how to handle such scenarios. It should be handled properly on a framework level. I think there is always possibility that component state on server and DOM tree on client browser are inconsistent (and not necessary because of push requests). Maybe it should be a dedicated exception on such situation (Component 'xxx' has been removed from page.) at least or maybe we can invent a better solution in core? -- Daniel On Fri, Jul 4, 2014 at 4:11 PM, Ernesto Reinaldo Barreiro reier...@gmail.com wrote: Maybe you could even just push JSON to client side and generate items content at client side which is going to be way faster On Fri, Jul 4, 2014 at 4:06 PM, Ernesto Reinaldo Barreiro reier...@gmail.com wrote: Why don't you try routing all the click to a part of you application that is always available? E.g. 1- You have a list of items that are pushed... They are in a certain container that is always there... At client and server side 2- The items are pushed but instead of normal AJAX link you use link to the parent never changing container passing ID of item. This way click will never fail and it is still sort of object oriented... On Fri, Jul 4, 2014 at 3:59 PM, Daniel Stoch daniel.st...@gmail.com wrote: On Fri, Jul 4, 2014 at 3:14 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, You can use Atmopshere to hide/disable the client side too, not just the server side. Of course, I already do that. But user can click the link after state was changed on the server side but before these changes are pushed to client browser. -- Daniel Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Jul 4, 2014 at 1:46 PM, Daniel Stoch daniel.st...@gmail.com wrote: On Fri, Jul 4, 2014 at 12:33 PM, Sven Meier s...@meiers.net wrote: So page was rendered in a browser, on the server component tree was changed What triggers the change to the component tree? On which thread? Are you using websockets? Sven In general this thread is not initialized by user action but by application. So yes, it can be push from a server (eg. using Atmosphere - this is my case) or by ajax self updating behavior. -- DS On 07/04/2014 12:13 PM, Daniel Stoch wrote: Hi all, I think such question occurs from time to time on this list, but I have never found a good answer how to solve such problem in general. The problem is similar to my last question: http://apache-wicket.1842946.n4.nabble.com/How-to-handle-click-on-disabled-links-ListenerInvocationNotAllowedException-td4666287.html but now there is a situation when link was removed from page (not disabled). So page was rendered in a browser, on the server component tree was changed, but user clicks a link in a browser before this changes will be pushed to it. It leads to an exception: org.apache.wicket.WicketRuntimeException: Component 'xxx' has been removed from page. at org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:178) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:735) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) How it should be properly handled in application? Unfortunately this is not a dedicated exception to catch somewhere, but a common WicketRuntimeException. -- Best regards, Daniel - 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
How to handle click on disabled links - ListenerInvocationNotAllowedException?
Hi, I have a link (or ajax link) which executes some system command. This system gives me an information if this command is enabled or not, so I can mark my link as enabled or disabled (by calling setEnabled(command.isEnabled()) or overriding link.isEnabled() method). 1. Page is being rendered, command is enabled so link is rendered as enabled. 2. In the meantime system state is changed so command became disabled. 3. User clicks link on a page rendered in step 1 where link is rendered as enabled but it is disabled now. In Wicket 1.4 nothing happens in such situation and only warning was logged: component not enabled or visible; ignoring call. Component: [MarkupContainer [Component id = link]] In Wicket 6 in such situation the exception is raised: ListenerInvocationNotAllowedException: Behavior rejected interface invocation. How should I handle this correctly to show some information to user, that this is link is no longer active (but user should stay on the same page)? Should I catch ListenerInvocationNotAllowedException inside IRequestCycleListener.onException()? -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to handle click on disabled links - ListenerInvocationNotAllowedException?
On Tue, Jun 17, 2014 at 4:14 PM, Sven Meier s...@meiers.net wrote: Hi, when you alter the enabled state in #onConfigure() - this is recommended instead of overriding #isEnabled() - the link will still be enabled when the next click comes in. Hmmm, I think I don't understand :). The next click does not come because exception is raised. If I catch exception and do nothing the link is still enabled to user, because page is not rerendered, You can handle the changed system state in your application logic. How? The only solution I know is to auto-refresh a page (eg. using push), but user can always click faster ;). Best regards Sven On 06/17/2014 03:55 PM, Daniel Stoch wrote: Hi, I have a link (or ajax link) which executes some system command. This system gives me an information if this command is enabled or not, so I can mark my link as enabled or disabled (by calling setEnabled(command.isEnabled()) or overriding link.isEnabled() method). 1. Page is being rendered, command is enabled so link is rendered as enabled. 2. In the meantime system state is changed so command became disabled. 3. User clicks link on a page rendered in step 1 where link is rendered as enabled but it is disabled now. In Wicket 1.4 nothing happens in such situation and only warning was logged: component not enabled or visible; ignoring call. Component: [MarkupContainer [Component id = link]] In Wicket 6 in such situation the exception is raised: ListenerInvocationNotAllowedException: Behavior rejected interface invocation. How should I handle this correctly to show some information to user, that this is link is no longer active (but user should stay on the same page)? Should I catch ListenerInvocationNotAllowedException inside IRequestCycleListener.onException()? -- Daniel - 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: How to handle click on disabled links - ListenerInvocationNotAllowedException?
On Tue, Jun 17, 2014 at 4:00 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, On Tue, Jun 17, 2014 at 4:55 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, I have a link (or ajax link) which executes some system command. This system gives me an information if this command is enabled or not, so I can mark my link as enabled or disabled (by calling setEnabled(command.isEnabled()) or overriding link.isEnabled() method). 1. Page is being rendered, command is enabled so link is rendered as enabled. 2. In the meantime system state is changed so command became disabled. 3. User clicks link on a page rendered in step 1 where link is rendered as enabled but it is disabled now. In Wicket 1.4 nothing happens in such situation and only warning was logged: component not enabled or visible; ignoring call. Component: [MarkupContainer [Component id = link]] In Wicket 6 in such situation the exception is raised: ListenerInvocationNotAllowedException: Behavior rejected interface invocation. How should I handle this correctly to show some information to user, that this is link is no longer active (but user should stay on the same page)? Should I catch ListenerInvocationNotAllowedException inside IRequestCycleListener.onException()? Yes. This is the best you can do in this case. Thanks for very fast answer :) But what should I return as a IRequestHandler in IRequestCycleListener.onException()? I can return EmptyRequestHandler to silently catch an exception, but if I want show some info to user then...? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to handle click on disabled links - ListenerInvocationNotAllowedException?
On Tue, Jun 17, 2014 at 4:27 PM, Sven Meier s...@meiers.net wrote: Hi, The next click does not come because exception is raised. if the link is still enabled, which exception should be thrown then? Sven Please read again steps 1,2,3 ;). Link is rendered as enabled in the browser (1), but on the server is not enabled anymore (3). -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to handle click on disabled links - ListenerInvocationNotAllowedException?
On Tue, Jun 17, 2014 at 5:08 PM, Sven Meier s...@meiers.net wrote: If you alter the enabled state of your links in #onConfigure(), they will still be enabled - even if the server state already changed. Sven Yes, you're right! I have investigated two scenarios just before your last answer :). 1. Link has overriden isEnabled() - then ListenerInvocationNotAllowedException is when command is not (as I described in my first post). 2. The enabled state of links are altered in #onConfigure() - link is still enabled even if the server state already changed. So we must do an extra check in onClick() method. So now I try to use the second solution (I have an abstraction over all links so it would be easy to implement) and add an extra check before calling a link code. Thanks for your help. -- Daniel On 06/17/2014 04:32 PM, Daniel Stoch wrote: On Tue, Jun 17, 2014 at 4:27 PM, Sven Meier s...@meiers.net wrote: Hi, The next click does not come because exception is raised. if the link is still enabled, which exception should be thrown then? Sven Please read again steps 1,2,3 ;). Link is rendered as enabled in the browser (1), but on the server is not enabled anymore (3). -- Daniel - 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
Atmosphere - multiple browser tabs and page versioning
Hi, I have modified wicket-atmosphere example with sending messages, to display a browser (DataView) with all received messages. So when user sends a message (String) it will be added to list of messages stored in a page and the browser is refreshed. There is a strange behavior when we open two browser tabs (FF 28, Wicket 6.15.0, Wicket-Atmosphere 0.18). 1. Start example app and opens home page in two tabs: tab0 = http://localhost:8080/app/?0 tab1 = http://localhost:8080/app/?1 2. Enter 1 in input field on tab0, click Send message. Both tabs receive 1 message and it will be displayed in a browser. 3. Send 2 in tab0: - on tab1 browser displays 2 rows: 2, 1 - on tab0 browser displays only 1 row: 2 4. Test sending another messages on tab0 or tab1 - you will see that not all messages are received. It looks like a problem with page versioning or something similar. The list of messages (messages field in a page) is not properly restored in following requests. Here is a simple log from example app using above scenario: - sending 1 BEFORE: 1, messages=[] AFTER: 1, messages=[1] BEFORE: 1, messages=[] AFTER: 1, messages=[1] - sending 2 BEFORE: 2, messages=[1] AFTER: 2, messages=[2, 1] BEFORE: 2, messages=[] AFTER: 2, messages=[2] As you can see a list of messages on one tab becomes empty on the second send. You can try to send messages from tab0 or tab1 and you should see that strange behavior (messages list is not updated properly). Is it a bug or maybe it is something wrong in my example? Maybe I should turn on (somehow) multiple tabs support, there is such setting in Wicket 1.4 but in Wicket 6 I belive there is not necessary to configure such support in any special way? BTW: Why in the original example page versioning is disabled: setVersioned(false); ? Example project: https://dl.dropboxusercontent.com/u/138504/wicket-atmosphere-tabs-example.zip -- Best regards, Daniel
Session size vs detached models
Hi, In Wicket 1.4 the last page reference is hold in a session (is it in 6.x also?). So after a request has been processed all components and models should be detached, so this last page reference should not hold transient LDM values. Is it true? When we are using DebugBar with SessionSizeDebugPanel, it displays session size and totalSize (by SessionTotalSizeModel). Does this totalSize includes size of object loaded by LDM or it counts all components and models size in detached state? -- Daniel
Re: Session size vs detached models
On Fri, Feb 14, 2014 at 4:12 PM, Martin Grigorov mgrigo...@apache.orgwrote: should be detached, so this last page reference should not hold transient LDM values. Is it true? LDM null-yfies its transien field explicitly: https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/model/LoadableDetachableModel.java?source=cc#L104 But if your custom model uses transient that is not null-yfied in onDetach() then it will be kept alive in the http session. You mean in detach(), not onDetach() ;) When we are using DebugBar with SessionSizeDebugPanel, it displays session size and totalSize (by SessionTotalSizeModel). Does this totalSize includes size of object loaded by LDM or it counts all components and models size in detached state? I have to check what is th difference between size and totalSize, but since https://issues.apache.org/jira/browse/WICKET-4867 the detachable is detached before measuring its size. Ok, great to know. So it looks in 1.4.x totalSize is measured before detaching. Thanks for the answer. -- Daniel
Re: WicketTester.isRenderedPage() in 6.13
I have created a new page with link and then execute: DummyBasePage page = new DummyBasePage(action); startPage(page); clickLink(page.getActionLink()); where action link is a link to another page. But it is still not working, only DummyBasePage is rendered. Then I look into WicketTester code and I have found that there are hard coded links' classes! So the code that is implemented inside a link class is ommited and its logic is doubled inside WicketTester. It looks to me as a very bad design (eg. I cannot test other link implementations). Finally it looks like WicketTester functionality was degraded comparing to 1.4, where application code could be easily testable in WicketTester and in 6.x the code that works ok in real application is not supported by WicketTester :(. Could it be possible to add to WicketTester handling such methods from RequestCycle: setResponsePage(), setResponse()? -- Daniel On Wed, Feb 5, 2014 at 1:51 PM, Martin Grigorov mgrigo...@apache.orgwrote: Component#setResponsePage() just delegates to RequestCycle#setResponsePage(). So it is the same. I'm saying that you should not use tester.getRequestCycle().xyz(). I.e. do not set the new page in the test code. Set it in the real application code. Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 1:47 PM, Daniel Stoch daniel.st...@gmail.com wrote: In my real application there are calls to RequestCycle.setResponsePage(...) which are hidden by more advanced action/navigation framework. So I cannot simply replace them by component.setResponsePage(). I think that if RequestCycle.setResponsePage(...) is valid for real application, it should also be valid for tests. Am I wrong? -- Daniel On Wed, Feb 5, 2014 at 1:14 PM, Martin Grigorov mgrigo...@apache.org wrote: You should not use tester.getRequestCycle().setResponsePage(DummyBasePage. class); You should do something like: - in the test code: tester.startPage(Page1.class) - in your real application code: Page1 or in its components you can use setResponsePage(Page2.class) - finally in the test code: tester.assertRenderedPage(Page2.class) Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 12:18 PM, Daniel Stoch daniel.st...@gmail.com wrote: Ok, but what I should call to render DummyBasePage after calling: tester.getRequestCycle().setResponsePage(DummyBasePage.class); without making a new request? -- Daniel On Wed, Feb 5, 2014 at 12:01 PM, Martin Grigorov mgrigo...@apache.org wrote: #processRequest() triggers a new request to the server so first the page is rendered, then a new request to the default destination is made, so the home page is rendered and lastRenderedPage changes Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 11:39 AM, Daniel Stoch daniel.st...@gmail.com wrote: One more question: what is a difference between these two calls: 1. tester.startPage(DummyBasePage.class); Result result = tester.isRenderedPage(DummyBasePage.class); 2. tester.getRequestCycle().setResponsePage(DummyBasePage.class); tester.processRequest(); Result result = tester.isRenderedPage(DummyBasePage.class); The first one works ok (DummyBasePage is rendered), but the second fails: HomePage is rendered instead of DummyBasePage. Why? -- Daniel On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov mgrigo...@apache.org wrote: Try with tester.setExposeExceptions(false) before making the request to the secured page Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, I'm during migration from Wicket 1.4.x to 6.x and I have the following problem with WicketTester. I have some secured page, during its initialization some kind of AuthorizationException is raised. It should end with displaying standard AccessDeniedPage. Here is a code fragment from test case: 1.4.x: RequestCycle.get().setResponsePage(SecuredDummyPage.class); tester.processRequestCycle(requestCycle); Result result = tester.isRenderedPage(AccessDeniedPage.class); assertFalse(result.getMessage(), result.wasFailed()); This test is passed. But in 6.13 the similar test: RequestCycle.get().setResponsePage(SecuredDummyPage.class); tester.processRequest(); // or tester.startPage(SecuredDummyPage.class) Result result = tester.isRenderedPage(AccessDeniedPage.class
Re: WicketTester.isRenderedPage() in 6.13
I have looked inside 1.4 and the code inside a clickLink() is very similar, so this is not a case to 6.x. But still it would be nice to have RequestCycle#setResponsePage() working ;). -- Daniel On Thu, Feb 6, 2014 at 10:00 AM, Daniel Stoch daniel.st...@gmail.comwrote: I have created a new page with link and then execute: DummyBasePage page = new DummyBasePage(action); startPage(page); clickLink(page.getActionLink()); where action link is a link to another page. But it is still not working, only DummyBasePage is rendered. Then I look into WicketTester code and I have found that there are hard coded links' classes! So the code that is implemented inside a link class is ommited and its logic is doubled inside WicketTester. It looks to me as a very bad design (eg. I cannot test other link implementations). Finally it looks like WicketTester functionality was degraded comparing to 1.4, where application code could be easily testable in WicketTester and in 6.x the code that works ok in real application is not supported by WicketTester :(. Could it be possible to add to WicketTester handling such methods from RequestCycle: setResponsePage(), setResponse()? -- Daniel On Wed, Feb 5, 2014 at 1:51 PM, Martin Grigorov mgrigo...@apache.orgwrote: Component#setResponsePage() just delegates to RequestCycle#setResponsePage(). So it is the same. I'm saying that you should not use tester.getRequestCycle().xyz(). I.e. do not set the new page in the test code. Set it in the real application code. Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 1:47 PM, Daniel Stoch daniel.st...@gmail.com wrote: In my real application there are calls to RequestCycle.setResponsePage(...) which are hidden by more advanced action/navigation framework. So I cannot simply replace them by component.setResponsePage(). I think that if RequestCycle.setResponsePage(...) is valid for real application, it should also be valid for tests. Am I wrong? -- Daniel On Wed, Feb 5, 2014 at 1:14 PM, Martin Grigorov mgrigo...@apache.org wrote: You should not use tester.getRequestCycle().setResponsePage(DummyBasePage. class); You should do something like: - in the test code: tester.startPage(Page1.class) - in your real application code: Page1 or in its components you can use setResponsePage(Page2.class) - finally in the test code: tester.assertRenderedPage(Page2.class) Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 12:18 PM, Daniel Stoch daniel.st...@gmail.com wrote: Ok, but what I should call to render DummyBasePage after calling: tester.getRequestCycle().setResponsePage(DummyBasePage.class); without making a new request? -- Daniel On Wed, Feb 5, 2014 at 12:01 PM, Martin Grigorov mgrigo...@apache.org wrote: #processRequest() triggers a new request to the server so first the page is rendered, then a new request to the default destination is made, so the home page is rendered and lastRenderedPage changes Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 11:39 AM, Daniel Stoch daniel.st...@gmail.com wrote: One more question: what is a difference between these two calls: 1. tester.startPage(DummyBasePage.class); Result result = tester.isRenderedPage(DummyBasePage.class); 2. tester.getRequestCycle().setResponsePage(DummyBasePage.class); tester.processRequest(); Result result = tester.isRenderedPage(DummyBasePage.class); The first one works ok (DummyBasePage is rendered), but the second fails: HomePage is rendered instead of DummyBasePage. Why? -- Daniel On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov mgrigo...@apache.org wrote: Try with tester.setExposeExceptions(false) before making the request to the secured page Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, I'm during migration from Wicket 1.4.x to 6.x and I have the following problem with WicketTester. I have some secured page, during its initialization some kind of AuthorizationException is raised. It should end with displaying standard AccessDeniedPage. Here is a code fragment from test case: 1.4.x: RequestCycle.get().setResponsePage(SecuredDummyPage.class); tester.processRequestCycle(requestCycle); Result result = tester.isRenderedPage(AccessDeniedPage.class); assertFalse(result.getMessage(), result.wasFailed()); This test is passed
WicketTester.isRenderedPage() in 6.13
Hi, I'm during migration from Wicket 1.4.x to 6.x and I have the following problem with WicketTester. I have some secured page, during its initialization some kind of AuthorizationException is raised. It should end with displaying standard AccessDeniedPage. Here is a code fragment from test case: 1.4.x: RequestCycle.get().setResponsePage(SecuredDummyPage.class); tester.processRequestCycle(requestCycle); Result result = tester.isRenderedPage(AccessDeniedPage.class); assertFalse(result.getMessage(), result.wasFailed()); This test is passed. But in 6.13 the similar test: RequestCycle.get().setResponsePage(SecuredDummyPage.class); tester.processRequest(); // or tester.startPage(SecuredDummyPage.class) Result result = tester.isRenderedPage(AccessDeniedPage.class); assertFalse(result.getMessage(), result.wasFailed()); is not passed. It is end up on this AuthorizationException and AccessDeniedPage is not rendered. Should it be rendered or should I have to change my test, because in 6.x it works in different way? -- Daniel
Re: WicketTester.isRenderedPage() in 6.13
It works! Thanks for your fast replay :) -- Daniel On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov mgrigo...@apache.orgwrote: Try with tester.setExposeExceptions(false) before making the request to the secured page Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, I'm during migration from Wicket 1.4.x to 6.x and I have the following problem with WicketTester. I have some secured page, during its initialization some kind of AuthorizationException is raised. It should end with displaying standard AccessDeniedPage. Here is a code fragment from test case: 1.4.x: RequestCycle.get().setResponsePage(SecuredDummyPage.class); tester.processRequestCycle(requestCycle); Result result = tester.isRenderedPage(AccessDeniedPage.class); assertFalse(result.getMessage(), result.wasFailed()); This test is passed. But in 6.13 the similar test: RequestCycle.get().setResponsePage(SecuredDummyPage.class); tester.processRequest(); // or tester.startPage(SecuredDummyPage.class) Result result = tester.isRenderedPage(AccessDeniedPage.class); assertFalse(result.getMessage(), result.wasFailed()); is not passed. It is end up on this AuthorizationException and AccessDeniedPage is not rendered. Should it be rendered or should I have to change my test, because in 6.x it works in different way? -- Daniel
Re: WicketTester.isRenderedPage() in 6.13
For fast REPLY, of course ;) On Wed, Feb 5, 2014 at 10:45 AM, Daniel Stoch daniel.st...@gmail.comwrote: It works! Thanks for your fast replay :) -- Daniel On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov mgrigo...@apache.orgwrote: Try with tester.setExposeExceptions(false) before making the request to the secured page Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, I'm during migration from Wicket 1.4.x to 6.x and I have the following problem with WicketTester. I have some secured page, during its initialization some kind of AuthorizationException is raised. It should end with displaying standard AccessDeniedPage. Here is a code fragment from test case: 1.4.x: RequestCycle.get().setResponsePage(SecuredDummyPage.class); tester.processRequestCycle(requestCycle); Result result = tester.isRenderedPage(AccessDeniedPage.class); assertFalse(result.getMessage(), result.wasFailed()); This test is passed. But in 6.13 the similar test: RequestCycle.get().setResponsePage(SecuredDummyPage.class); tester.processRequest(); // or tester.startPage(SecuredDummyPage.class) Result result = tester.isRenderedPage(AccessDeniedPage.class); assertFalse(result.getMessage(), result.wasFailed()); is not passed. It is end up on this AuthorizationException and AccessDeniedPage is not rendered. Should it be rendered or should I have to change my test, because in 6.x it works in different way? -- Daniel
Re: WicketTester.isRenderedPage() in 6.13
One more question: what is a difference between these two calls: 1. tester.startPage(DummyBasePage.class); Result result = tester.isRenderedPage(DummyBasePage.class); 2. tester.getRequestCycle().setResponsePage(DummyBasePage.class); tester.processRequest(); Result result = tester.isRenderedPage(DummyBasePage.class); The first one works ok (DummyBasePage is rendered), but the second fails: HomePage is rendered instead of DummyBasePage. Why? -- Daniel On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov mgrigo...@apache.orgwrote: Try with tester.setExposeExceptions(false) before making the request to the secured page Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, I'm during migration from Wicket 1.4.x to 6.x and I have the following problem with WicketTester. I have some secured page, during its initialization some kind of AuthorizationException is raised. It should end with displaying standard AccessDeniedPage. Here is a code fragment from test case: 1.4.x: RequestCycle.get().setResponsePage(SecuredDummyPage.class); tester.processRequestCycle(requestCycle); Result result = tester.isRenderedPage(AccessDeniedPage.class); assertFalse(result.getMessage(), result.wasFailed()); This test is passed. But in 6.13 the similar test: RequestCycle.get().setResponsePage(SecuredDummyPage.class); tester.processRequest(); // or tester.startPage(SecuredDummyPage.class) Result result = tester.isRenderedPage(AccessDeniedPage.class); assertFalse(result.getMessage(), result.wasFailed()); is not passed. It is end up on this AuthorizationException and AccessDeniedPage is not rendered. Should it be rendered or should I have to change my test, because in 6.x it works in different way? -- Daniel
Re: WicketTester.isRenderedPage() in 6.13
Ok, but what I should call to render DummyBasePage after calling: tester.getRequestCycle().setResponsePage(DummyBasePage.class); without making a new request? -- Daniel On Wed, Feb 5, 2014 at 12:01 PM, Martin Grigorov mgrigo...@apache.orgwrote: #processRequest() triggers a new request to the server so first the page is rendered, then a new request to the default destination is made, so the home page is rendered and lastRenderedPage changes Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 11:39 AM, Daniel Stoch daniel.st...@gmail.com wrote: One more question: what is a difference between these two calls: 1. tester.startPage(DummyBasePage.class); Result result = tester.isRenderedPage(DummyBasePage.class); 2. tester.getRequestCycle().setResponsePage(DummyBasePage.class); tester.processRequest(); Result result = tester.isRenderedPage(DummyBasePage.class); The first one works ok (DummyBasePage is rendered), but the second fails: HomePage is rendered instead of DummyBasePage. Why? -- Daniel On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov mgrigo...@apache.org wrote: Try with tester.setExposeExceptions(false) before making the request to the secured page Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, I'm during migration from Wicket 1.4.x to 6.x and I have the following problem with WicketTester. I have some secured page, during its initialization some kind of AuthorizationException is raised. It should end with displaying standard AccessDeniedPage. Here is a code fragment from test case: 1.4.x: RequestCycle.get().setResponsePage(SecuredDummyPage.class); tester.processRequestCycle(requestCycle); Result result = tester.isRenderedPage(AccessDeniedPage.class); assertFalse(result.getMessage(), result.wasFailed()); This test is passed. But in 6.13 the similar test: RequestCycle.get().setResponsePage(SecuredDummyPage.class); tester.processRequest(); // or tester.startPage(SecuredDummyPage.class) Result result = tester.isRenderedPage(AccessDeniedPage.class); assertFalse(result.getMessage(), result.wasFailed()); is not passed. It is end up on this AuthorizationException and AccessDeniedPage is not rendered. Should it be rendered or should I have to change my test, because in 6.x it works in different way? -- Daniel
Re: WicketTester.isRenderedPage() in 6.13
In my real application there are calls to RequestCycle.setResponsePage(...) which are hidden by more advanced action/navigation framework. So I cannot simply replace them by component.setResponsePage(). I think that if RequestCycle.setResponsePage(...) is valid for real application, it should also be valid for tests. Am I wrong? -- Daniel On Wed, Feb 5, 2014 at 1:14 PM, Martin Grigorov mgrigo...@apache.orgwrote: You should not use tester.getRequestCycle().setResponsePage(DummyBasePage. class); You should do something like: - in the test code: tester.startPage(Page1.class) - in your real application code: Page1 or in its components you can use setResponsePage(Page2.class) - finally in the test code: tester.assertRenderedPage(Page2.class) Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 12:18 PM, Daniel Stoch daniel.st...@gmail.com wrote: Ok, but what I should call to render DummyBasePage after calling: tester.getRequestCycle().setResponsePage(DummyBasePage.class); without making a new request? -- Daniel On Wed, Feb 5, 2014 at 12:01 PM, Martin Grigorov mgrigo...@apache.org wrote: #processRequest() triggers a new request to the server so first the page is rendered, then a new request to the default destination is made, so the home page is rendered and lastRenderedPage changes Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 11:39 AM, Daniel Stoch daniel.st...@gmail.com wrote: One more question: what is a difference between these two calls: 1. tester.startPage(DummyBasePage.class); Result result = tester.isRenderedPage(DummyBasePage.class); 2. tester.getRequestCycle().setResponsePage(DummyBasePage.class); tester.processRequest(); Result result = tester.isRenderedPage(DummyBasePage.class); The first one works ok (DummyBasePage is rendered), but the second fails: HomePage is rendered instead of DummyBasePage. Why? -- Daniel On Wed, Feb 5, 2014 at 10:40 AM, Martin Grigorov mgrigo...@apache.org wrote: Try with tester.setExposeExceptions(false) before making the request to the secured page Martin Grigorov Wicket Training and Consulting On Wed, Feb 5, 2014 at 10:33 AM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, I'm during migration from Wicket 1.4.x to 6.x and I have the following problem with WicketTester. I have some secured page, during its initialization some kind of AuthorizationException is raised. It should end with displaying standard AccessDeniedPage. Here is a code fragment from test case: 1.4.x: RequestCycle.get().setResponsePage(SecuredDummyPage.class); tester.processRequestCycle(requestCycle); Result result = tester.isRenderedPage(AccessDeniedPage.class); assertFalse(result.getMessage(), result.wasFailed()); This test is passed. But in 6.13 the similar test: RequestCycle.get().setResponsePage(SecuredDummyPage.class); tester.processRequest(); // or tester.startPage(SecuredDummyPage.class) Result result = tester.isRenderedPage(AccessDeniedPage.class); assertFalse(result.getMessage(), result.wasFailed()); is not passed. It is end up on this AuthorizationException and AccessDeniedPage is not rendered. Should it be rendered or should I have to change my test, because in 6.x it works in different way? -- Daniel
Ajax indicator - display delay
Hi all, When there is some AJAX activity on page we can show ajax indicator (using AjaxIndicatorAppender and implementing IAjaxIndicatorAware). My problem is that I want to show such indicator only when ajax request takes longer than specified amount of time (eg. 1 second). But inside a AbstractDefaultAjaxBehavior (1.4.x) such indicator is shown immediately when request is processed. Is there any solution to delay displaying indicator (something like AjaxCallThrottlingDecorator but not for ajax beahvior but for ajax indicator itself)? -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
WicketURLEncoder: escaping / in parameter value
Hi, I'm using WicketURLEncoder (1.4.18) to encode some parameter values. Exactly WicketURLEncoder.QUERY_INSTANCE, but the problem if parameter value contains / (slash) character, eg.: 1 Mbit/s, which is not escaped. This cause an error in url coding startegy which is based on key/value pairs (/key1/value1/key2/value2) because value contains / and brokes the whole url. Here it is an output from different version of WicketURLEncoder for this value: WicketURLEncoder.PATH_INSTANCE = 1%20Mbit%2Fs WicketURLEncoder.FULL_PATH_INSTANCE = 1%20Mbit/s WicketURLEncoder.QUERY_INSTANCE = 1+Mbit/s So should I use PATH_INSTANCE to encode these parameter values instead of QUERY_INSTANCE? I do not use Wicket 6, but maybe the same problem is in that version? -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: WicketURLEncoder: escaping / in parameter value
Thanks for the very fast answer. I wanted to change it on PATH_INSTANCE but I wanted to make sure, so I have asked ;) -- DS On Mon, Nov 26, 2012 at 2:32 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, Since you use parameters in the path you have to use PATH_INSTANCE. On Mon, Nov 26, 2012 at 2:28 PM, Daniel Stoch daniel.st...@gmail.comwrote: Hi, I'm using WicketURLEncoder (1.4.18) to encode some parameter values. Exactly WicketURLEncoder.QUERY_INSTANCE, but the problem if parameter value contains / (slash) character, eg.: 1 Mbit/s, which is not escaped. This cause an error in url coding startegy which is based on key/value pairs (/key1/value1/key2/value2) because value contains / and brokes the whole url. Here it is an output from different version of WicketURLEncoder for this value: WicketURLEncoder.PATH_INSTANCE = 1%20Mbit%2Fs WicketURLEncoder.FULL_PATH_INSTANCE = 1%20Mbit/s WicketURLEncoder.QUERY_INSTANCE = 1+Mbit/s So should I use PATH_INSTANCE to encode these parameter values instead of QUERY_INSTANCE? I do not use Wicket 6, but maybe the same problem is in that version? -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
How to modify attribute (eg. class) in component with setRenderBodyOnly(true) ?
Hi, Is it possible to modify tag attribute (eg. add a CSS class) of component which has set renderBodyOnly flag to true? When using component.add(new AttributeModifier(...)) it has no effect, because a tag in which this class attribute is appended is not rendered in HTML (because of setRenderBodyOnly(true)). Here is an example: LinkContainer is a component (extends Panel) which has setRenderBodyOnly(true). wicket:panel a wicket:id=linkwicket:container wicket:id=linkContent[link content]/wicket:container/a /wicket:panel Somewhere inside a page or panel: add(new LinkContainer(link, ...).add(new AttributeModifier(class, Model.of(my-link-style; But of course this class='my-link-style' will not be rendered anywhere. I want to add a class attribute to contained a tag but using a behavior which can be added to the whole LinkContainer. Is it any simple solution to achieve this? -- DS - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to modify attribute (eg. class) in component with setRenderBodyOnly(true) ?
No. I want to have a. When you use this LinkContainer from my example in HTML like: div wicket:id=link /div It will be rendered as: a wicket:id=link.../a So any attributes modified using behavior will disappear. But if LinkContainer will not have setRenderBodyOnly(true), the the corresponding HTML will be: div wicket:id=link class='my-link-style' a wicket:id=link.../a /div -- DS On Wed, Feb 22, 2012 at 11:49 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, So you want to not have a (because this is what .setRenderBodyOnly(true) does) and in the same time you want to set a class an that non-existing tag ?! The easiest way is to remove the call to .setRenderBodyOnly(true). On Wed, Feb 22, 2012 at 11:38 AM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, Is it possible to modify tag attribute (eg. add a CSS class) of component which has set renderBodyOnly flag to true? When using component.add(new AttributeModifier(...)) it has no effect, because a tag in which this class attribute is appended is not rendered in HTML (because of setRenderBodyOnly(true)). Here is an example: LinkContainer is a component (extends Panel) which has setRenderBodyOnly(true). wicket:panel a wicket:id=linkwicket:container wicket:id=linkContent[link content]/wicket:container/a /wicket:panel Somewhere inside a page or panel: add(new LinkContainer(link, ...).add(new AttributeModifier(class, Model.of(my-link-style; But of course this class='my-link-style' will not be rendered anywhere. I want to add a class attribute to contained a tag but using a behavior which can be added to the whole LinkContainer. Is it any simple solution to achieve this? -- DS - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to modify attribute (eg. class) in component with setRenderBodyOnly(true) ?
On Wed, Feb 22, 2012 at 12:11 PM, Martin Grigorov mgrigo...@apache.org wrote: On Wed, Feb 22, 2012 at 12:01 PM, Daniel Stoch daniel.st...@gmail.com wrote: No. I want to have a. When you use this LinkContainer from my example in HTML like: div wicket:id=link /div It will be rendered as: a wicket:id=link.../a So any attributes modified using behavior will disappear. But if LinkContainer will not have setRenderBodyOnly(true), the the corresponding HTML will be: div wicket:id=link class='my-link-style' a wicket:id=link.../a /div Now it is more clear what you do. You need to add the AttributeModifier to the Link, not to the LinkContainer if you want to manipulate a. Well, I know it is possible in this way. But my question is more general: does using behaviors which changes a markup (like AttributeModifier) on components with setRenderBodyOnly(true) make sense? To add the AttributeModifier to the Link I have to write extra method inside a LinkContainer which adds a behavior to enclosing component (Link is created inside LinkContainer and because of ecapsulation it should not be visible outside it). But the cleaner solution will be to add a behavior to LinkContainer, but then it should be transparently added to the one of its child components. Then I can use AttributeModifier (or related behaviors) the same way with component which has setRenderBodyOnly(true) or not. But now I need to know a component implementation to decide if I can use such modifiers with it or no. -- DS - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to modify attribute (eg. class) in component with setRenderBodyOnly(true) ?
On Wed, Feb 22, 2012 at 12:31 PM, Martin Grigorov mgrigo...@apache.org wrote:
On Wed, Feb 22, 2012 at 12:20 PM, Daniel Stoch daniel.st...@gmail.com wrote:
On Wed, Feb 22, 2012 at 12:11 PM, Martin Grigorov mgrigo...@apache.org
wrote:
On Wed, Feb 22, 2012 at 12:01 PM, Daniel Stoch daniel.st...@gmail.com
wrote:
No. I want to have a. When you use this LinkContainer from my
example in HTML like:
div wicket:id=link
/div
It will be rendered as:
a wicket:id=link.../a
So any attributes modified using behavior will disappear.
But if LinkContainer will not have setRenderBodyOnly(true), the the
corresponding HTML will be:
div wicket:id=link class='my-link-style'
a wicket:id=link.../a
/div
Now it is more clear what you do.
You need to add the AttributeModifier to the Link, not to the
LinkContainer if you want to manipulate a.
Well, I know it is possible in this way. But my question is more
general: does using behaviors which changes a markup (like
AttributeModifier) on components with setRenderBodyOnly(true) make
sense?
No.
To add the AttributeModifier to the Link I have to write extra method
inside a LinkContainer which adds a behavior to enclosing component
(Link is created inside LinkContainer and because of ecapsulation it
should not be visible outside it). But the cleaner solution will be to
add a behavior to LinkContainer, but then it should be transparently
added to the one of its child components.
To which child exactly ? How to decide that for you ?
Then I can use AttributeModifier (or related behaviors) the same way
with component which has setRenderBodyOnly(true) or not. But now I
need to know a component implementation to decide if I can use such
modifiers with it or no.
Each behavior has a reference to the component it is bound to. So you
can assign your own Behavior to the parent class and then in
behavior's onComponentTag, renderHead(), ... you can do whatever you
need with the parent and all its children. It is a bit harder to get
the children ComponentTags but it is possible: new
MarkupStream(getMarkup()) and iterate over the elements in the
MarkupStream.
Thanks for your feedback and suggestions.
I have done a simple behavior to achieve what I want. Maybe this is
not very elegant solution but it should work. It writes out attributes
added as AttributeModifiers to a parent component to a child component
which has this behavior.
public class AttributeModifierPropagator extends AbstractBehavior {
private final MarkupContainer parent;
public AttributeModifierPropagator(MarkupContainer parent) {
super();
if (parent == null) {
throw new IllegalArgumentException(Argument [parent] cannot be null);
}
this.parent = parent;
}
@Override
public void onComponentTag(Component component, ComponentTag tag) {
for (IBehavior behavior : parent.getBehaviors()) {
if ((behavior instanceof AttributeModifier) || (behavior
instanceof SimpleAttributeModifier)) {
behavior.onComponentTag(component, tag);
}
}
}
}
And then inside a LinkContainer after creating nested Link link I can
add this behavior to it:
link.add(new AttributeModifierPropagator(this));
--
DS
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
AbstractAjaxTimerBehavior with restart ability
Hi,
Current implementation of AbstractAjaxTimerBehavior has a
functionality to stop() pooling. But once stopped it cannot be
restarted. There are situations when we want to periodically refresh
components from one event to another, but not all the time (to avoid
unnecessary requests to server). So it would be nice to have a
restarting ability in AbstractAjaxTimerBehavior. Something like:
public final void start(final AjaxRequestTarget target) {
target.getHeaderResponse().renderOnLoadJavascript(getJsTimeoutCall(getUpdateInterval()));
}
But this method does not work in all situations. Eg. when you stopped
this timer using stop() method, the above start() does not work (but
this is probably because a stopped flag cannot be reset to false).
What do you think about such improvement in AbstractAjaxTimerBehavior?
It would be great to has it also in 1.4 because I cannot upgrade to
1.5 ;).
--
Daniel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Display HTML in Label with validation
Thanks for your suggestion. But I need to validate a fragment of HTML, but it seems that HtmlDocumentValidator validates only whole documents. From my point of view the following texts are valid HTML fragments: - This is sample text - bThis is/b sample pparagraph/p -- Daniel On Thu, Sep 15, 2011 at 5:31 PM, manuelbarzi manuelba...@gmail.com wrote: may HtmlDocumentValidator help you. . On Thu, Sep 15, 2011 at 5:05 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, How to display dynamic HTML content on page which can be invalid (because this HTML is entered by a user). I can use Label.setEscapeModelStrings(false), but with invalid HTML content the page will not be rendered (because of HTML parsing error). So maybe I can use some of standard Wicket mechanisms to parse this HTML first to check if I can display it on page? There are some parsers within framework... -- Daniel - 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
Display HTML in Label with validation
Hi, How to display dynamic HTML content on page which can be invalid (because this HTML is entered by a user). I can use Label.setEscapeModelStrings(false), but with invalid HTML content the page will not be rendered (because of HTML parsing error). So maybe I can use some of standard Wicket mechanisms to parse this HTML first to check if I can display it on page? There are some parsers within framework... -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
setRenderAllowed called for invisible components
Hi, Is it a valid behavior that setRenderAllowed(...) method is called for invisible components (components that are not visible in hierarchy). I have a use case with DataView component displaying list of links. When I hide this DataView (eg. by setting dataView.setVisible(false)) then for each of the links components (created in previous request) setRenderAllowed(...) method is called. I have a quickstart app to simulate this, but I don't know is it a bug and should I create JIRA issue for this? -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: setRenderAllowed called for invisible components
Wicket 1.4.18 On Mon, Sep 5, 2011 at 12:29 PM, Daniel Stoch daniel.st...@gmail.com wrote: Hi, Is it a valid behavior that setRenderAllowed(...) method is called for invisible components (components that are not visible in hierarchy). I have a use case with DataView component displaying list of links. When I hide this DataView (eg. by setting dataView.setVisible(false)) then for each of the links components (created in previous request) setRenderAllowed(...) method is called. I have a quickstart app to simulate this, but I don't know is it a bug and should I create JIRA issue for this? -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: setRenderAllowed called for invisible components
Hi, Yes, it should be called also on invisible components, but only when it is any chance that these components can be rendered. If one of theirs parents are not visible, then such component will not be rendered. In my scenario DataView is visible only when dataView.getItemCount() 0. But it leads to an abnormal situation: 1. First request: dataView.getItemCount()=3 so DataView renders 3 subitems (children). 2. Second request: dataView.getItemCount()=0 (eg. someone remove all 3 records from DB), so I set DataView.setVisible(false), but DataView subitems are not removed from its children list before calling DataView.setRenderAllowed (MarkupContainer.setRenderAllowed). MarkupContainer.setRenderAllowed calls setRenderAllowed for all 3 subitems in visitChildren(...). But these subitems should not exists in current request because dataView.getItemCount()=0. They are not removed from DataView because it is not visible and calling setRenderAllowed for these subitems is a bug for me. -- Daniel On Mon, Sep 5, 2011 at 4:21 PM, Andrea Del Bene adelb...@ciseonweb.it wrote: Hi, I'm not completely sure, but setRenderAllowed is called to check rendering authorization, so it should be called also on invisible components. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Extend AjaxFormComponentUpdatingBehavior functionality for required FormComponents
Maybe I should explain one of use-cases. Let's say we have a form to enter RSS feed information. There are two TextFields: - url for RSS feed (urlModel) - custom RSS feed name (nameModel). Both are required and both have OnChangeBehavior attached. When user enter url for RSS the name of it is retrieved and set into nameModel. But only when nameModel has null object or nameEdited (boolean flag) is false. Now user can edit name field (then nameEdited flag is set to true, to avoid changing this name when user change url). But when user clears name field nameModel should be updated to null, but behavior does not allow this (because of validation of required field). what you want can be done in a simple manner. do not mark your field as required, since it is not. write your own validator that allows setting the field value to null when the edit flag is set, and fails when it is not. But this field is required - from user point of view. User cannot submit form without filling the name. you can create your own updating behavior that calls setrequired(false) on the component prior to running validation/model update if that is what you want. but we will not ship something like this as part of core because it doesnt generally make sense. Probably I'll write my own behavior, because it seems this is the only solution :). Maybe it does not make sense from your point of view, but from mine it does. I think your point of view is sometimes too narrow. my point of view has to be narrow. as developers of the framework we try to make the 95% usecase as simple as possible, while leaving the door open for the other rare 5%. unfortunately for you, this is the other 5%. My post was only a proposal, because it is not possible to easy extend AjaxFormComponentUpdatingBehavior because onEvent() is final. I want to avoid copy/paste code with only a little change. And I think this change is very useful. But ok, I understand you, so I'll implement it by myself. But always is good to try convince you first :). -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Extend AjaxFormComponentUpdatingBehavior functionality for required FormComponents
On Thu, Feb 17, 2011 at 10:37 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
validation is there to make sure the user of the webapp cannot push an
illegal value into a model. it doesnt matter if its just the component
that is being submitted or the entire form. components decide whether
or not a user can push null in by using their required flag. you want
to push null, dont mark the component as required. it is as simple as
that. you can create your own updating behavior that calls
setrequired(false) on the component prior to running validation/model
update if that is what you want. but we will not ship something like
this as part of core because it doesnt generally make sense.
-igor
I've found examples in Wicket core, which are very similar to my
use-cases, so it looks like sometimes it does make sense :).
Look at the classes which implements IOnChangeListener. There is a
method onSelectionChanged() which implementation in many cases looks
like:
public final void onSelectionChanged()
{
convertInput();
updateModel();
onSelectionChanged(getModelObject());
}
So as you can see here validation is bypassed and null values can be
push into the model even if FormComponent is required. Eg.
DropDownChoice: when I use non-ajax
wantOnSelectionChangedNotifications() I can push null into its model,
but the same thing does not work with OnChangeAjaxBehavior(). So there
is a small inconsistence between ajax and non-ajax functionality. My
case is to allow the same behavior for ajax calls.
--
Daniel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Extend AjaxFormComponentUpdatingBehavior functionality for required FormComponents
It can be called with null value when you set DropDownChoice.setNullValid(true).
You don't want to understand that this is a good behavior in many
cases, not a bug. But ok it is your framework, so you decide. But
maybe other Wicket commiters have a different feeling about it?
--
Daniel
On Fri, Feb 18, 2011 at 5:36 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
that looks like a bug to me. the reason it has gone unnoticed for so
long is that someone would have to hack html to cause it. onchange
only fires in browsers when there is a value selected, so that code
would not typically be called with a null, and thus no need to check
required.
-igor
On Fri, Feb 18, 2011 at 7:22 AM, Daniel Stoch daniel.st...@gmail.com wrote:
On Thu, Feb 17, 2011 at 10:37 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
validation is there to make sure the user of the webapp cannot push an
illegal value into a model. it doesnt matter if its just the component
that is being submitted or the entire form. components decide whether
or not a user can push null in by using their required flag. you want
to push null, dont mark the component as required. it is as simple as
that. you can create your own updating behavior that calls
setrequired(false) on the component prior to running validation/model
update if that is what you want. but we will not ship something like
this as part of core because it doesnt generally make sense.
-igor
I've found examples in Wicket core, which are very similar to my
use-cases, so it looks like sometimes it does make sense :).
Look at the classes which implements IOnChangeListener. There is a
method onSelectionChanged() which implementation in many cases looks
like:
public final void onSelectionChanged()
{
convertInput();
updateModel();
onSelectionChanged(getModelObject());
}
So as you can see here validation is bypassed and null values can be
push into the model even if FormComponent is required. Eg.
DropDownChoice: when I use non-ajax
wantOnSelectionChangedNotifications() I can push null into its model,
but the same thing does not work with OnChangeAjaxBehavior(). So there
is a small inconsistence between ajax and non-ajax functionality. My
case is to allow the same behavior for ajax calls.
--
Daniel
-
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: Extend AjaxFormComponentUpdatingBehavior functionality for required FormComponents
On Fri, Feb 18, 2011 at 10:09 AM, Daniel Stoch daniel.st...@gmail.com wrote: My post was only a proposal, because it is not possible to easy extend AjaxFormComponentUpdatingBehavior because onEvent() is final. I want to avoid copy/paste code with only a little change. And I think this change is very useful. But ok, I understand you, so I'll implement it by myself. I've tried to implement my own behavior (with an option to bypass validation step). But unfortunately I cannot call formComponent.convertInput() which is necessary to get value from input. This is a protected method. Can you make it a public method? -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Extend AjaxFormComponentUpdatingBehavior functionality for required FormComponents
I need to pass any value (null or not null) to a model without validation. So I cannot call validate() but only convertInput() (as you can see for example in DropDownChoice). To do this inside a behavior class convertInput() method must be public (or I need to hack this using a reflection, but this is ugly solution). -- Daniel On Fri, Feb 18, 2011 at 10:50 PM, Pedro Santos pedros...@gmail.com wrote: Do your use case needs to convert a null input? If the input is differs from null FormComponent#validate will be just fine. On Fri, Feb 18, 2011 at 5:20 PM, Daniel Stoch daniel.st...@gmail.comwrote: On Fri, Feb 18, 2011 at 10:09 AM, Daniel Stoch daniel.st...@gmail.com wrote: My post was only a proposal, because it is not possible to easy extend AjaxFormComponentUpdatingBehavior because onEvent() is final. I want to avoid copy/paste code with only a little change. And I think this change is very useful. But ok, I understand you, so I'll implement it by myself. I've tried to implement my own behavior (with an option to bypass validation step). But unfortunately I cannot call formComponent.convertInput() which is necessary to get value from input. This is a protected method. Can you make it a public method? -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pedro Henrique Oliveira dos Santos - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Extend AjaxFormComponentUpdatingBehavior functionality for required FormComponents
There is a situation when the AjaxFormComponentUpdatingBehavior
deafult functionality fails. When we want to attach this behavior (or
OnChangeAjaxBehavior) to reflect changes inside a Model of
FormComponent which is marked as REQUIRED event if user clears
component input. In such situation AjaxFormComponentUpdatingBehavior
calls validation, FormComponent is not valid so error message is
reported and Model is not updated (I want to update this Model beacuse
the other things on form may depend on it).
My proposition is to extend this behavior to handle such use-cases
when user clears FormComponent input:
1. Do not update a Model and report error message (current and the
default behavior).
2. Update a Model and not report any error messages.
3. Update a Model and report error message.
It can be done by adding to boolean properties to this behavior (they
both be null by default) - feel free to invent a better names ;):
- disabledValidation
- alwaysUpdateModel
The change in code (not tested yet :)):
protected final void onEvent(final AjaxRequestTarget target)
{
final FormComponent? formComponent = getFormComponent();
if (getEvent().toLowerCase().equals(onblur)
disableFocusOnBlur())
{
target.focusComponent(null);
}
try
{
formComponent.inputChanged();
if (!isDisabledValidation) {
formComponent.validate();
}
if (formComponent.hasErrorMessage())
{
formComponent.invalid();
if (isAlwaysUpdateModel()) {
if (getUpdateModel())
{
formComponent.updateModel();
}
}
onError(target, null);
}
else
{
formComponent.valid();
if (getUpdateModel())
{
formComponent.updateModel();
}
onUpdate(target);
}
}
catch (RuntimeException e)
{
onError(target, e);
}
}
--
Daniel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Extend AjaxFormComponentUpdatingBehavior functionality for required FormComponents
On Thu, Feb 17, 2011 at 6:50 PM, Pedro Santos pedros...@gmail.com wrote:
I Daniel, how alwaysUpdateModel differs from updateModel?
You mean from getUpdateModel()? isAlwaysUpdateModel() is called only
when component is invalid, but getUpdateModel() in both cases (for
valid and invalid).
If you have an
required form component that support some clean up logic, it can be coded
inside AjaxFormComponentUpdatingBehavior#onError, and if you need an AJAX
behavior that don't validate the form component, you can
use AjaxEventBehavior instead of AjaxFormComponentUpdatingBehavior.
Yes. Of course I can create my own behavior by doing a copy of
original AjaxFormComponentUpdatingBehavior and changing some code
inside onEvent() method. But then I will have my own class hierarchy,
very similar to original one. And always after upgrading Wicket to a
new version I'll have to check if something was changed in original
classes. The second reason to have this in core is that I think these
use-cases are very common.
Placing my code in onError() is not a good solution, because component
is prior marked as invalid and has an error message (which cause
displaying it in FeedbackPanel).
The code you sent will end up invoking formComponent.valid() for non valid
components, it is problematic.
You have right. So maybe this code should looks like below (changing
valid state only when validation is enabled):
{
formComponent.inputChanged();
if (!isDisabledValidation) {
formComponent.validate();
}
if (formComponent.hasErrorMessage())
{
formComponent.invalid();
if (isAlwaysUpdateModel()) {
if (getUpdateModel())
{
formComponent.updateModel();
}
}
onError(target, null);
}
else
{
if (!isDisabledValidation) {
formComponent.valid();
}
if (getUpdateModel())
{
formComponent.updateModel();
}
onUpdate(target);
}
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Extend AjaxFormComponentUpdatingBehavior functionality for required FormComponents
On Thu, Feb 17, 2011 at 9:02 PM, Pedro Santos pedros...@gmail.com wrote: Override onError still makes sense for me, if the form component is required, why to hide the message? Because I don't want to show such error message when user clears (update) this required field but only when he press Submit. And FeedbackPanel is refreshed automatically, so each message is immediately shown to the user. If there is some special message reporting rule, it can be coded inside onError also. No when component is required, because validation and error reporting is done prior to call onError() method, and I cannot change that. -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Extend AjaxFormComponentUpdatingBehavior functionality for required FormComponents
On Thu, Feb 17, 2011 at 10:01 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: if you want to push a null value into a component you marked required then dont mark it as required. No, because then I must have my own customrequired flags instead of using the core mechanism. I think this is wrong way. There is a wrong assumption that when component is marked as required then I cannot push a null value to its model. Validation should not allow to submit a form (not allow to further processing). But during editing process when user fills the form and updates componenets (not submits whole form) it should be possible to push null in models (of course as an option). The current behavior leads to many boilerplate code which can be avoided. if you have inter-dependent validation use a formvalidator or override form's onsubmit. It is not this case here. -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Extend AjaxFormComponentUpdatingBehavior functionality for required FormComponents
On Thu, Feb 17, 2011 at 10:37 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: validation is there to make sure the user of the webapp cannot push an illegal value into a model. it doesnt matter if its just the component that is being submitted or the entire form. components decide whether or not a user can push null in by using their required flag. you want to push null, dont mark the component as required. it is as simple as that. But you ommit something: model can contains a null value on startup and event though a formcomponent has a valid state on the first render. So passing null to this model later is like resseting its state to original (null) value :). Another thing is than I can set null in code and bypass component validation. So I can push null into this model, but the final validation will still work. Maybe I should explain one of use-cases. Let's say we have a form to enter RSS feed information. There are two TextFields: - url for RSS feed (urlModel) - custom RSS feed name (nameModel). Both are required and both have OnChangeBehavior attached. When user enter url for RSS the name of it is retrieved and set into nameModel. But only when nameModel has null object or nameEdited (boolean flag) is false. Now user can edit name field (then nameEdited flag is set to true, to avoid changing this name when user change url). But when user clears name field nameModel should be updated to null, but behavior does not allow this (because of validation of required field). you can create your own updating behavior that calls setrequired(false) on the component prior to running validation/model update if that is what you want. but we will not ship something like this as part of core because it doesnt generally make sense. Probably I'll write my own behavior, because it seems this is the only solution :). Maybe it does not make sense from your point of view, but from mine it does. I think your point of view is sometimes too narrow. -- Daniel On Thu, Feb 17, 2011 at 1:33 PM, Daniel Stoch daniel.st...@gmail.com wrote: On Thu, Feb 17, 2011 at 10:01 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: if you want to push a null value into a component you marked required then dont mark it as required. No, because then I must have my own customrequired flags instead of using the core mechanism. I think this is wrong way. There is a wrong assumption that when component is marked as required then I cannot push a null value to its model. Validation should not allow to submit a form (not allow to further processing). But during editing process when user fills the form and updates componenets (not submits whole form) it should be possible to push null in models (of course as an option). The current behavior leads to many boilerplate code which can be avoided. if you have inter-dependent validation use a formvalidator or override form's onsubmit. It is not this case here. -- Daniel - 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: back-button causes Wicket state and page displayed to be out of synch
Hi, On Fri, Oct 22, 2010 at 12:53 PM, drf davidrfi...@gmail.com wrote: I have encountered the following serious issue: My application consists of one WebPage which has an AjaxTabbedPanel. Each tab has an associated panel which includes several menu items (links) which can be selected. This works well. However, if the user selects the back-button (once back, then once forward) they can come back to the page with a different tab displayed than the one selected before the back-button was used. If a menu link is then clicked on, an exception is thrown. This appears to be because the Wicket on the server is now out of synch with the html displayed. Wicket thinks a different panel is selected than the one the user sees now. Turn off page caching in a browser for ajax pages. -- DS - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Bean injection
On Thu, Oct 7, 2010 at 5:47 PM, Mauro Ciancio maurocian...@gmail.com wrote: It's not so important, but I can't figure out why I have the same bean instance, taking into account that the page is serialized at the end of the request and the inyected bean is actually a proxy of the bean, so no real bean is in the serialization. I've double checked it, and the _same_ bean instance is holded in my page en each request to the same page. Shouldn't the bean get relocated after serialization? Yes: after deserialization :). And yes: after deserialization of yout page version this bean is relocated from Spring again. You can chcek this: go to the previous page version by clicking back button and press refresh button (if page is cached in a browser). Then you can see that a new bean instance is created. When you stays on the same page and clicking statefull links this page is not deserialized (correct me if I am wrong). -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: DropDownChoice/Model Confusion
The code looks ok. Maybe the problem is in childRecordService: childRecordService.getList() when method getList() does not reflect changes until you create a new session. So maybe the problem is related to your service layer? Have you checked whet this method returns inside childRecordsModel.load() ? -- Daniel On Tue, Oct 5, 2010 at 10:23 PM, Shelli Orton shelli.or...@sjrb.ca wrote: This is what my class basically looks like, hope it helps: - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Image Bundler For Apache Wicket
Hi,
Thanks for this change!
My suggestions and optimalization notes:
1. In some cases there is no necessary to create an anonymous class
for each ImageItem (using AbstractImageItem). When @ImageBundle
interface has not locale specified, then SimpleImageItem(String
imageSrc, String imageStyle) can be used.
2. The call:
String locale = RequestCycle.get().getSession().getLocale().toString();
does not look very good for me :). Now you cannot call any method
outside of a Wicket thread.
Maybe for methods returning an ImageItem a Locale should be a method
argument (but only if image is locale relative). So:
// for not locale relative images
ImageItem getSomeImage();
// for locale related
ImageItem getSomeImage(Locale locale);
Then implementation will be more clear:
@Override
public ImageItem a(Locale locale) {
if ((locale != null) ta_IN.equals(locale.toString()) {
return new SimpleImageItem(images/clear.gif, background-image
:url(resources/org.imagebundler.wicket.examples.SampleImageBundle
/SampleImageBundle_ta_IN.png) ; background-position:-50px -0px;
width:25px; height:25px; ) ;
}
// default
return new SimpleImageItem(images/clear.gif, background-image
:url(resources/org.imagebundler.wicket.examples.SampleImageBundle/SampleImageBundle.png)
; background-position:-48px -0px; width:24px; height:24px; ) ;
}
Another solution is to add a Locale argument to getStyle() method (but
then maybe getSrc() should also have a Locale argument, so maybe the
first option with ImageItem getSomeImage(Locale locale); is better).
For methods returning Image component maybe it would be better to get
Locale during the rendering, not when creating an Image. So maybe it
should be a special AttributeModifier which calculates a proper style
in eg. beforeRender() method?
For now when user changes a locale in application and images are not
recreated (eg. page will be not created again, but only refreshed in a
non-bookmarkable request), they will be still using a style from an
old locale (assigned in creation time).
--
Daniel
On Sun, Apr 18, 2010 at 5:20 PM, Anantha Kumaran
ananthakuma...@gmail.com wrote:
http://ananthakumaran.github.com/imagebundler-wicket/
version 1.2 released
* localization support added
* style and src of the image is available through the ImageItem interface
your comments are welcome
Anantha Kumaran(http://ananthakumaran.github.com)
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Image Bundler For Apache Wicket
On 2010-04-20, at 19:28, Anantha Kumaran wrote:
Maybe for methods returning an ImageItem a Locale should be a method
argument (but only if image is locale relative). So:
// for not locale relative images
ImageItem getSomeImage();
// for locale related
ImageItem getSomeImage(Locale locale);
The first option looks good.
I will add it (may be tomorrow).
I thought about it once again and now I think it is not a good
solution (a method: ImageItem getSomeImage(Locale locale);) for the
same reasons as I wrote about Image components. When I get an
ImageItem instance for specified Locale and pass this instance
somewhere to components, then any locale changes in session will not
affect this ImageItem. So it is going to be more complicated :(.
So maybe the second solution (from my previous mail) is better: add a
Locale argument to getStyle() method (and maybe also to getSrc()).
Or it should be one more interface, eg: ImageItemProvider :) :
interface ImageItemProvider {
ImageItem getImageItem(Locale locale);
}
and then image bundle should have a methods which return
ImageItemProvider instead of ImageItem (this interface will not
change) directly:
ImageItemProvider a();
For methods returning Image component maybe it would be better to get
Locale during the rendering, not when creating an Image. So maybe it
should be a special AttributeModifier which calculates a proper style
in eg. beforeRender() method?
For now when user changes a locale in application and images are not
recreated (eg. page will be not created again, but only refreshed
in a
non-bookmarkable request), they will be still using a style from an
old locale (assigned in creation time).
I am not sure how to handle this.
I will try to prepare a proposal solution for this ;).
--
Daniel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Image Bundler For Apache Wicket
And one more thing: ImageItem interface (and posiibly ImageItemProvider too) should extend Serializable (or maybe better IClusterable?). -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Submit form with ajax on enter
I have the same problem today (what a coincidence :)). This works ok for me in Firefox 3.5 and Opera 10, but does not work in Chrome, Safari and IE. PS. I'm using Wicket 1.4.4. DS On Thu, Feb 4, 2010 at 10:38 AM, MattyDE ufer.mar...@gmail.com wrote: Any other hints for this right now? I want to submit an ajax-Form by hiting enter in Textfield, but i want wicket to call the same Method as i defiend in AjaxButton ... any ideas? Thanks a lot in Advance - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Using style AND variation
Hi all,
Liz Huber wrote:
In our application we use Panels in different variations.
For example: Foot.html, Foot_withTextLinks.html, Foot_withImageLinks.html,
Head.html, Head_error.html
Now we'd additionally like to use different styles.
For example on Valentine's Day all image links in our footer should be shown
in pink. (Just as example to describe)
- session.setStyle(Valentine);
We added File Footer_withImageLinks_Valentine.html and thought everthing is
fine.
But once the style Valentine is set, the Markup Head_error.html is never
used again, because Wicket is looking for Head_error_Valentine.html.
Unfortunately wicket combines variant and style when looking for resources.
That's why the loading order is:
1. Head_error_Valentine.html (= name_variation_style.html)
2. Head.html (= name.html)
Is there a way to change the loading order to:
1. Head_error_Valentine.html (= name_variation_style.html)
2. Head_error.html (= name_variation.html)
3. Head.html (= name.html)
Otherwise every variation must be defined for every style. That makes a lot
of duplicate files.
Or did I get something wrong here?
Liz
Any ideas how to solve this issue? When we have some component (panel)
with different variation which are style agnostic (eg. these panels come
from another components library), then this problem is very obvious.
The easiest way to solve this could be overriding getStyle() method in
Head panel and returns always a getVariation() result (bypass a
session's style):
public String getStyle() {
return getVariation();
}
But Component.getStyle() is a final method :(.
--
Daniel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
