when all else fails jira is a pretty good place to fall back on
-igor
On Mon, Mar 17, 2008 at 11:50 PM, lars vonk <[EMAIL PROTECTED]> wrote:
> Someone willing to comment on this? Should I put this in JIRA as change
> request or bug?
>
> Lars
>
>
>
> On Sun, Mar 16, 2008 at 9:41 PM, lars vonk <[EMAIL PROTECTED]> wrote:
>
> > Hi all,
> >
> > I am currently working on wicket-contrib-jamon to provide monitoring for
> > wicket applications. While testing my code I noticed that WicketTester
> > causes different behavior when for instance opening pages and clicking
> links
> > in respect to what happens in real time testing with for instance Jetty.
> > This different behavior is especially around the WebRequestCycle and
> > WebRequestCycleProcessor. For creating nice Monitor labels in Jamon I want
> > to know on which Component (e.g. a link) on which Page someone clicked and
> > which Page is opened. An example Monitor label could be "
> > HomePage.toLoginPage -> LoginPage". To achieve this I need to create
> > custom implementations or WebRequestCycle and WebRequestCycleProcessor.
> >
> > So far I noticed 2 differences (live environment versus WicketTester):
> >
> > 1. Depending on which startPage method you call the
> > WebRequestCycle.onBeginRequest is called or not. When using
> > startPage(Class) the method WebRequestCycle.onBeginRequest is not. Since
> > my code relies on overriding this method I can't use startPage(Class)
> >
> > The startPage(Page) method does call the onBeginRequest, but this one has
> > another side effect. Since WicketTester uses a link "testPage" in the class
> > DummyHomePage as starting point for all the pages that are opened when
> using
> > startPage(Page), this also appears in my Monitor label name.
> >
> > I did some debugging in the Wicket code and came to a different
> > startPage(Class) implementation that will trigger the
> > WebRequestCycle.onBeginRequest and does not use the DummyHomePage. Since I
> > am not a Wicket developer I am not exactly sure if this implementation has
> > some unforeseen side effects:
> >
> > class MyWicketTester extends WicketTester {
> > public Page openPage(Class<? extends Page> pageClass) {
> > WebRequestCycle requestCycle = super.setupRequestAndResponse
> > ();
> > requestCycle.getRequest
> > ().getRequestParameters().setBookmarkablePageClass(pageClass.getName());
> > super.processRequestCycle(requestCycle);
> > return super.getLastRenderedPage();
> > }
> > }
> >
> > 2. When using the WicketTester.clickLink(String) only the
> > WebRequestCycle.onEndRequest is called. When clicking a link in a real
> > environment the WebRequestCycle.onEndRequest is called. Again I created
> > another implementation for clicking links and would like to hear you expert
> > opinions.
> >
> > class MyWicketTester extends WicketTester {
> > public void clickAjaxLink(String linkPath) {
> > WebRequestCycle cycle = super.setupRequestAndResponse();
> > cycle.getRequest().getRequestParameters().setInterfaceName(
> > IBehaviorListener.class.getSimpleName());
> > cycle.getRequest().getRequestParameters().setBehaviorId("0");
> > cycle.getRequest
> >
> ().getRequestParameters().setComponentPath(getComponentFromLastRenderedPage(linkPath).getPath());
> > super.processRequestCycle(cycle);
> > }
> > }
> >
> > (I am not exactly sure what the setBehaviorId("0") means but in a real
> > environment that was it's value.)
> >
> > So my questions are basically:
> >
> > - Is there a reason why WicketTester does not go through the same
> > RequestCycle as it would in a real live envorinment (e.g the on...Request
> > methods)?
> > - Is it possible to change the WicketTester so it better resembles the
> > behavior of a real live environment, especially with respect to the
> > WebRequestCycle and WebRequestCycleProcessor?
> > - Are the above implementations any good? Maybe after tweaking they can be
> > used in the WicketTester?
> >
> > Thanks in advance,
> >
> > Lars
> >
> >
> >
>
