unit testing cookies after redirect
hej,
I ve found this
http://apache-wicket.1842946.n4.nabble.com/Wickettester-cookies-and-redirects-in-Wicket-1-4-15-td3250792.html
but im developing on 1.5.2 and ticket is closed. I believe it is the same case.
this is description:
I have a page ValidationPage that accepts request, checks parameters
and sets cookie on response object
((WebResponse)getRequestCycle().getResponse()).addCookie(new
Cookie(mycookie, VAL));
then on certain condition I want to redirect to original destination
or to some set page
if (!continueToOriginalDestination())
{
log.warning(redirect failed redirecting to original destination);
throw new RestartResponseException(new MyOtherPage());
}
so in test
tester.startPage(ValidationPage.class, pageParameters);
tester.assertRenderedPage(MyOtherPage.class);
final Cookie[] cookies = tester.getRequest().getCookies();
assertNotNull(cookies); - fail
and I get null, I tried Reponse object but no luck. I thought cookies
should be resend in next request back to server right?
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Mounting page to mutliple urls with different pageparameter
hi,
thanks for your explanation. As I want to restrict the possible paths to
AnotherPage to /b and /c and not /xyz, I went for the IRequestMapper
implementation.
I now have an implementation that seems to work perfect, but I'm afraid it's
not thread-safe and I'm not sure if I've understood things correctly. So
please, if you could help me answer the following questions ?
I need to return different URLs from mapHandler() for AnotherPage and for
any other URLs I have in my application. This is because I need the b or
c as PageParameter to AnotherPage, but it should not happen for other
URLs. So I implemented IRequestMapper such that it wraps the default
RootRequestMapper to be used for all requests except /b and /c, which are
handled by a different IRequestMapper that uses a path variable. In my
Application:
setRootRequestMapper(new RootRequestMapper(getRootRequestMapper(),
new MountedMapper(/${param}, AnotherPage.class)));
Then in my IRequestMapper implementation, in mapRequest() the request url
segments are checked and if it's /b or /c, use the second one.
To get things to work with the correct URL for both cases, I also check in
mapHandler() which IRequestMapper should return the URL. However I found no
way to remember which case (/b, or anything esle) is being handled between
the mapRequest and mapHandler() methods, so I stored this in a class
variable. This is what I think is not thread-safe.
Please see my implementation here http://pastebin.com/h0rhtFLz.
Surely there's a better of way dealing with this ?
thank you and kind regards
Heikki Doeleman
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Mounting-external-pages-to-root-tp3890756p3996292.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Mounting page to mutliple urls with different pageparameter
Another way is to override some methods in MountedMapper (thus creating
your AnotherPageMapper or something like that).
Methods of interest:
- getCompatibilityScore(): should only return 1 if the url starts with
b or c
See the default MountedMapper implementation, you could simply say:
if( urlStartsWith(request.getUrl(), b) ||
urlStartsWith(request.getUrl(), c) {
return 1;
} else {
return 0;
}
This will make sure that your mapper only handles /b and /c. You can
still mount it at /${param} so it automatically puts the b or c in the
PageParameters upon decoding, and puts it in the url upon encoding.
Then simply call (in webapp.init()):
mount(new AnotherPageMapper(/${param}));
This will add your mapper before all others, thus making sure it is
checked before others on encoding and decoding requests.
Op 6-11-2011 19:02, schreef heikki:
hi,
thanks for your explanation. As I want to restrict the possible paths to
AnotherPage to /b and /c and not /xyz, I went for the IRequestMapper
implementation.
I now have an implementation that seems to work perfect, but I'm afraid it's
not thread-safe and I'm not sure if I've understood things correctly. So
please, if you could help me answer the following questions ?
I need to return different URLs from mapHandler() for AnotherPage and for
any other URLs I have in my application. This is because I need the b or
c as PageParameter to AnotherPage, but it should not happen for other
URLs. So I implemented IRequestMapper such that it wraps the default
RootRequestMapper to be used for all requests except /b and /c, which are
handled by a different IRequestMapper that uses a path variable. In my
Application:
setRootRequestMapper(new RootRequestMapper(getRootRequestMapper(),
new MountedMapper(/${param}, AnotherPage.class)));
Then in my IRequestMapper implementation, in mapRequest() the request url
segments are checked and if it's /b or /c, use the second one.
To get things to work with the correct URL for both cases, I also check in
mapHandler() which IRequestMapper should return the URL. However I found no
way to remember which case (/b, or anything esle) is being handled between
the mapRequest and mapHandler() methods, so I stored this in a class
variable. This is what I think is not thread-safe.
Please see my implementation here http://pastebin.com/h0rhtFLz.
Surely there's a better of way dealing with this ?
thank you and kind regards
Heikki Doeleman
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Mounting-external-pages-to-root-tp3890756p3996292.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
onblur on modal window with Internet Explorer
Hi. When I use the onblur on a modal window, I'm having trouble. After firing onblur events, clicking on the title of a modal window, the window sticks to mouse cursor. This state is released when I click somewhere. Happened in Wicket 1.5.2, but other versions probably happen. This issue occurs in Internet Explorer. Is there any way to somehow ? I prepared sample. http://d.hatena.ne.jp/sekom/files/Wicket152ModalAndJS.zip?d=y To do the following: 1. Click Show modal dialog with a page link. 2. Input the alphabet in the text field. 3. Click title of a modal window. 4. Click OK on the alert 5. Trouble occurs. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
wicket-4200 still broken in 1.5-SNAPSHOT
I understand that wicket-4200 (no prepended javascript in
onBeforeRender()) is marked fixed in 1.5.3. I pulled the latest SNAPSHOT
to see if I could get an early fix. It may be that the current snapshot
is known to be unstable in this regard, but prepending javascript still
does not work. I've been told it does, but it really does not and you
may want to check this out. I added these lines to an ajax target...
StringBuilder prependBuilder;
StringBuilder appendBuilder;
prependBuilder = new StringBuilder(var outerDijit =
dijit.byId(').append(dojoComponent.getMarkupId()).append(');)
.append(if (outerDijit)
{outerDijit.destroyDescendants();outerDijit.destroyRecursive();)
.append(dojo.byId(').append(dojoComponent.getDijitContainerMarkupId())
.append(').id=').append(dojoComponent.getMarkupId()).append('});
appendBuilder = new
StringBuilder(dojo.parser.parse(dojo.byId(').append(dojoComponent.getD
ijitContainerMarkupId()).append(')););
target.prependJavaScript(alert('boofaz'););
target.prependJavaScript(prependBuilder);
target.appendJavaScript(appendBuilder);
Really, most of this code does not matter. Just note that the first bit
of javascript is the simple alert('boofaz') (why 'boofaz', why not?).
The resulting return has this as the first priority-evaluate...
priority-evaluate![CDATA[alert('boofaz');]]/priority-evaluate
...but no alert is ever produced. However, it's clear from the results
of the ajax return that the regular evaluate sections are run. So
something is wrong with the latest wicket-ajax.js.
David
Re: wicket-4200 still broken in 1.5-SNAPSHOT
maybe your browser has cached wicket-ajax.js? try clearing the browser
cache. otherwise check if your browser sees the below lines in
wicket-ajax.js which execute the prepending javascript:
// go through the ajax response and execute all priority-invocations
first
for (var i = 0; i root.childNodes.length; ++i) {
var node = root.childNodes[i];
if (node.tagName == priority-evaluate) {
this.processEvaluation(steps, node);
}
}
// go through the ajax response and for every action
(component, js
evaluation, header contribution)
if the above is in your ajax js and it still doesnt work attach a
quickstart to the jira ticket that reproduces your particular problem.
-igor
On Sun, Nov 6, 2011 at 6:41 PM, David Berkman david.berk...@glu.com wrote:
I understand that wicket-4200 (no prepended javascript in
onBeforeRender()) is marked fixed in 1.5.3. I pulled the latest SNAPSHOT
to see if I could get an early fix. It may be that the current snapshot
is known to be unstable in this regard, but prepending javascript still
does not work. I've been told it does, but it really does not and you
may want to check this out. I added these lines to an ajax target...
StringBuilder prependBuilder;
StringBuilder appendBuilder;
prependBuilder = new StringBuilder(var outerDijit =
dijit.byId(').append(dojoComponent.getMarkupId()).append(');)
.append(if (outerDijit)
{outerDijit.destroyDescendants();outerDijit.destroyRecursive();)
.append(dojo.byId(').append(dojoComponent.getDijitContainerMarkupId())
.append(').id=').append(dojoComponent.getMarkupId()).append('});
appendBuilder = new
StringBuilder(dojo.parser.parse(dojo.byId(').append(dojoComponent.getD
ijitContainerMarkupId()).append(')););
target.prependJavaScript(alert('boofaz'););
target.prependJavaScript(prependBuilder);
target.appendJavaScript(appendBuilder);
Really, most of this code does not matter. Just note that the first bit
of javascript is the simple alert('boofaz') (why 'boofaz', why not?).
The resulting return has this as the first priority-evaluate...
priority-evaluate![CDATA[alert('boofaz');]]/priority-evaluate
...but no alert is ever produced. However, it's clear from the results
of the ajax return that the regular evaluate sections are run. So
something is wrong with the latest wicket-ajax.js.
David
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
