Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

At the risk of being unoriginal, request processing in general does two things: changes some data which is stored in HttpSession, database or somewhere else; creates some output which is usually HTML. These is no single class in Wicket that does all the request processing . Classes & classes delegate the work to each other. In a simplified way it goes like this:

...

  1. browser requests a URL
  2. WicketFilter/Servlet receives request from servlet container and creates RequestCycle object
  3. RequestCycle goes through several states, calling at it state certain method in IRequestCycleProcessor
  4. Depending on request parameters IRequestCycleProcessor creates IRequestTarget (in Wicket this process is referred to as "resolving"). At this stage requested URL is translated into IRequestTarget which knows already contains requested Page/Component or knows how to create it.
  5. IRequestTarget use existing Page or creates a new one, optionally asks Components to execute callbacks (user code which handles link clicks, form submits, etc.), then asks Page and Components to render themselves
  6. Page/Components execute callbacks and render themselves. Callbacks change state and rendering produce markup and write it to HttpResponse. This is the place where most of the user code resides.
  7. servlet container writes output to browser

...