Re: ModalDialog and returning back

2012-06-08 Thread Alex
Thank you very much, I will try to use jQuery directly.

2012/6/6 Jeffrey Schneller jeffrey.schnel...@envisa.com

 You could just include the logo panel on the page and uses straight jQuery
 to show and hide the logo panel. You wouldn't need the Ajax timer and your
 extended OpenOnLoadModalWindow class. It should then be able to support the
 back button. You could also determine if the user has been to your app
 before in the same session and choose to show the logo or not (there are a
 few jQuery plugins that can help with determining that)

 With Wicket 6 my understanding is that jQuery will be included by Wicket
 so this may be even easier to do in 6 and all in Java code. I have not
 looked at version 6 yet.


 On Jun 6, 2012, at 7:04 AM, Alex zeita...@googlemail.com wrote:

  Dear All,
  I have an application that on renderOnDomReadyJavascript shows Modal
 Dialog
  for 5 seconds and then closes it. It is kind of Logo. Unfortunately if
 user
  goes to another site and returns back then “Page expired” is displayed in
  this Modal Dialog and it is not closes. Is it possible to avoid showing
  this Modal Dialog after user returns to my application pressing “Back”
  Button on the Browser or to show it properly for 5 sec.
  Thanks a lot in advance,
  Alex
 
  public class LogoStarter {
 private static final Logger log =
  LoggerFactory.getLogger(LogoStarter.class);
 
 public LogoStarter(final WebPage webPage) {
 final ModalWindow modalLogo;
 final ModalWindow modalInfo;
 
 webPage.add(modalLogo = new OpenOnLoadModalWindow(modalLogo));
 modalLogo.setTitle();
 modalLogo.setPageCreator(new ModalWindow.PageCreator() {
 private static final long serialVersionUID =
  2674999186672458996L;
 public Page createPage() {
 return new Logo();
 }
 });
 
 webPage.add(new AjaxLinkObject(logo) {
 public void onClick(AjaxRequestTarget target) {
 if (target != null) {
 modalLogo.show(target);
 } else {
 System.out.println(JS off);
 setResponsePage(new Logo(JS_OFF_MSG));
 }
 
 }
 });
 
 webPage.add(new AbstractAjaxTimerBehavior(Duration.seconds(5)) {
 protected void onTimer(AjaxRequestTarget target) {
 if (modalLogo.isShown())
 modalLogo.close(target);
 stop();
 }
 });
 }
  }
 
  public class OpenOnLoadModalWindow extends ModalWindow implements
  IHeaderContributor {
 
 public OpenOnLoadModalWindow(String id) {
 super(id);
 }
 
 public OpenOnLoadModalWindow(String id, IModel? model) {
 super(id, model);
 }
 
 public void renderHead(IHeaderResponse response)
 {
response.renderOnDomReadyJavascript(getWindowOpenJavascript());
 }
 
protected boolean makeContentVisible()
 {
 return true;
 }
  }



Re: ModalDialog and returning back

2012-06-08 Thread Melinda Dweer
Hi,

Some things I would try are

1-Instead of a page use a panel for your modal. That way the  page expired
will not be shown on the page.
2-Make your page expired page the page you want to show.
3-AFAIK the method
 public void renderHead(IHeaderResponse response)
 {
  response.renderOnDomReadyJavascript(getWindowOpenJavascript());

 }
is the one determining the modal will be show on load. Yo can for instance
use a more permanent cookie and don't call
response.renderOnDomReadyJavascript(getWindowOpenJavascript()); depending
on that condition.

Regards,

Melinda


On Wed, Jun 6, 2012 at 1:04 PM, Alex zeita...@googlemail.com wrote:

 Dear All,
 I have an application that on renderOnDomReadyJavascript shows Modal Dialog
 for 5 seconds and then closes it. It is kind of Logo. Unfortunately if user
 goes to another site and returns back then “Page expired” is displayed in
 this Modal Dialog and it is not closes. Is it possible to avoid showing
 this Modal Dialog after user returns to my application pressing “Back”
 Button on the Browser or to show it properly for 5 sec.
 Thanks a lot in advance,
 Alex

 public class LogoStarter {
private static final Logger log =
 LoggerFactory.getLogger(LogoStarter.class);

public LogoStarter(final WebPage webPage) {
final ModalWindow modalLogo;
final ModalWindow modalInfo;

webPage.add(modalLogo = new OpenOnLoadModalWindow(modalLogo));
modalLogo.setTitle();
modalLogo.setPageCreator(new ModalWindow.PageCreator() {
private static final long serialVersionUID =
 2674999186672458996L;
public Page createPage() {
return new Logo();
}
});

webPage.add(new AjaxLinkObject(logo) {
public void onClick(AjaxRequestTarget target) {
if (target != null) {
modalLogo.show(target);
} else {
System.out.println(JS off);
setResponsePage(new Logo(JS_OFF_MSG));
}

}
});

webPage.add(new AbstractAjaxTimerBehavior(Duration.seconds(5)) {
protected void onTimer(AjaxRequestTarget target) {
if (modalLogo.isShown())
modalLogo.close(target);
stop();
}
});
}
 }

 public class OpenOnLoadModalWindow extends ModalWindow implements
 IHeaderContributor {

public OpenOnLoadModalWindow(String id) {
super(id);
}

public OpenOnLoadModalWindow(String id, IModel? model) {
super(id, model);
}

public void renderHead(IHeaderResponse response)
{
   response.renderOnDomReadyJavascript(getWindowOpenJavascript());
}

   protected boolean makeContentVisible()
{
return true;
}
 }



Re: ModalDialog and returning back

2012-06-08 Thread Alex
Thanks a lot for your answer Melinda! If my Logo will extend Panel instead
of WebPage what should I use instead of createPage() and setResponsePage();
without this I get an error:
ERROR - RequestCycle   - Error creating page for modal dialog.
org.apache.wicket.WicketRuntimeException: Error creating page for modal
dialog.
at
org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow.getWindowOpenJavascript(ModalWindow.java:1130)
at
de.regio.impl.OpenOnLoadModalWindow.renderHead(OpenOnLoadModalWindow.java:53)
at org.apache.wicket.Component.renderHead(Component.java:2801)
at org.apache.wicket.markup.html.panel.Panel.renderHead(Panel.java:138)
at
org.apache.wicket.markup.html.internal.HtmlHeaderContainer$1.component(HtmlHeaderContainer.java:231)
at
org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:920)
at
org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:960)
at
org.apache.wicket.markup.html.internal.HtmlHeaderContainer.renderHeaderSections(HtmlHeaderContainer.java:222)
at
org.apache.wicket.markup.html.internal.HtmlHeaderContainer.onComponentTagBody(HtmlHeaderContainer.java:137)
at org.apache.wicket.Component.renderComponent(Component.java:2728)
at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1559)
at org.apache.wicket.Component.render(Component.java:2528)
at org.apache.wicket.MarkupContainer.autoAdd(MarkupContainer.java:229)
at
org.apache.wicket.markup.resolver.HtmlHeaderResolver.resolve(HtmlHeaderResolver.java:80)
at
org.apache.wicket.markup.resolver.ComponentResolvers.resolve(ComponentResolvers.java:81)
at
org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1465)
at
org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1575)
at org.apache.wicket.Page.onRender(Page.java:1594)
at org.apache.wicket.Component.render(Component.java:2528)
at org.apache.wicket.Page.renderPage(Page.java:932)
at
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.respond(BookmarkablePageRequestTarget.java:261)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:105)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1260)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1331)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1438)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:546)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:486)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:319)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:547)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)


2012/6/8 Melinda Dweer melinda.dw...@gmail.com

 Hi,

 Some things I would try are

 1-Instead of a page use a panel for your modal. That way the  page expired
 will not be shown on the page.
 2-Make your page expired page the page you want to show.
 3-AFAIK the method
  public void renderHead(IHeaderResponse response)
  {
  response.renderOnDomReadyJavascript(getWindowOpenJavascript());

  }
 is the one determining the modal will be show on load. Yo can for instance
 use a more permanent cookie and don't call
 response.renderOnDomReadyJavascript(getWindowOpenJavascript()); depending
 on that condition.

 Regards,

 Melinda


 On Wed, Jun 6, 2012 at 1:04 PM, Alex zeita...@googlemail.com wrote:

  Dear All,
  I have an application that on renderOnDomReadyJavascript shows Modal
 Dialog
  for 5 seconds and then closes it. It is kind of Logo. Unfortunately if
 user
  goes to another site and returns back then “Page 

Re: Exception handling and testing

2012-06-08 Thread Alec Swan
That's clever. I will give it a try.

What is the recommendation on verifying that an exception was thrown
during page rendering using Wicket tester? I am not talking just about
authentication here, but exceptions in general.

Thanks,

Alec

On Thu, Jun 7, 2012 at 6:18 PM, Martin Grigorov mgrigo...@apache.org wrote:
 On Fri, Jun 8, 2012 at 12:37 AM, Alec Swan alecs...@gmail.com wrote:
 I am also asking how to redirect to sub-site's home page when the user
 is not authenticated and tries to access on of those sub-site pages.

 Use a custom IAuthenticationStrategy that knows which pages are part
 of this sub-site (e.g. you can annotate them with a special @SubSite)
 and
 if the user is not logged in then redirect to @SubSite.homePage class.
 This way even every page can it have its own home page.


 On Thu, Jun 7, 2012 at 3:35 PM, Alec Swan alecs...@gmail.com wrote:
 The problem is that I cannot verify this exception in tests. I am
 basically asking for best practices.

 Thanks!

 On Thu, Jun 7, 2012 at 1:30 AM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 Hi,

 You can use IAuthenticationStrategy and throw
 RestartResponseAtInterceptException.

 On Wed, Jun 6, 2012 at 8:09 PM, Alec Swan alecs...@gmail.com wrote:
 Hello,

 I am creating a new set of pages that are a part of an old project but
 have a different home page. It's kind of like a sub-site within a
 site. The user is required to log in on the sub-site's home page to be
 able to access any of those pages. If the user tries to access any of
 these pages directly he should be redirected to the sub-site's home
 page.

 What's the best way to implement/configure the home page for this 
 sub-site?
 What kind of exception should each sub-site page throw to trigger
 redirection to home page?
 How can I verify that an exception was thrown in my test? (Currently I
 have a test which calls startPanel(..) which logs an exception if the
 user is not logged in, but returns with no errors. So, I have to
 verify that the rendered page is what it should be.)

 I am basically looking for best practices here.

 Thanks,

 Alec

 -
 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




 --
 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: Exception handling and testing

2012-06-08 Thread Michal Margiel
2012/6/8 Alec Swan alecs...@gmail.com

 That's clever. I will give it a try.

 What is the recommendation on verifying that an exception was thrown
 during page rendering using Wicket tester? I am not talking just about
 authentication here, but exceptions in general.


Hello,
Why you want to verify that exception was thrown in WicketTester? IMHO it
is not proper place to check that.
In my code I am verifying expcetions in services tests using
catch-exception library [1].

And then while testing Page I am mocking my service to throw exception and
I am verifying behaviour on exception (e.g. redirecting to login page,
showing error message etc...)

That makes not only clearer code but also simplify testing.
you can see example of services tests in [2] and page tests in [3]

[1] http://code.google.com/p/catch-exception/
[2]
https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/services/UserServiceImplShould.java
[3]
https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/pages/admin/login/LoginPageShould.java
-- 
Pozdrawiam/Best regards
Michał Margiel

http://www.confitura.pl (dawniej Javarsovia)
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu


Re: Exception handling and testing

2012-06-08 Thread Alec Swan
I also use this approach, but with authentication exceptions thrown by
Wicket it's hard to tell if the user was redirected to Login page
because of authentication or some other exceptions.

On Fri, Jun 8, 2012 at 1:15 PM, Michal Margiel michal.marg...@gmail.com wrote:
 2012/6/8 Alec Swan alecs...@gmail.com

 That's clever. I will give it a try.

 What is the recommendation on verifying that an exception was thrown
 during page rendering using Wicket tester? I am not talking just about
 authentication here, but exceptions in general.


 Hello,
 Why you want to verify that exception was thrown in WicketTester? IMHO it
 is not proper place to check that.
 In my code I am verifying expcetions in services tests using
 catch-exception library [1].

 And then while testing Page I am mocking my service to throw exception and
 I am verifying behaviour on exception (e.g. redirecting to login page,
 showing error message etc...)

 That makes not only clearer code but also simplify testing.
 you can see example of services tests in [2] and page tests in [3]

 [1] http://code.google.com/p/catch-exception/
 [2]
 https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/services/UserServiceImplShould.java
 [3]
 https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/pages/admin/login/LoginPageShould.java
 --
 Pozdrawiam/Best regards
 Michał Margiel

 http://www.confitura.pl (dawniej Javarsovia)
 http://www.linkedin.com/in/MichalMargiel
 http://www.margiel.eu

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