ah, okay.

but i don't think we need to break session factories to be explicit 
here.  request cycle is available by threadlocal.


Johan Compagner wrote:
> 
> I didn't revert that
> 
> ISessionFactory still has:
> 
> Session newSession(Request request, Response response);
> 
> But i am proposing to do this:
> 
> ISessionFactory: Session newSession(RequestCycle requestCycle);
> 
> then create the request cycle before the session creation
> 
> and let the session get the RequestCycle
> the request cycle factory should move to application then instead of
> session
> 
> johan
> 
> 
> 
> 
> On 4/12/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> why did you revert the changes that threaded the response through?
>>
>> that's a definite improvement.
>>
>>
>> Johan Compagner wrote:
>> >
>> > ok i changed it back for now
>> > But if we want to fix this then we need to change some flow
>> >
>> > Now a RequestCycle is created by a Session object:
>> >
>> >
>> > final WebRequest request =
>> webApplication.newWebRequest(servletRequest);
>> >
>> > // First, set the webapplication for this thread
>> > Application.set(webApplication);
>> >
>> > // Create a response object and set the output encoding according to
>> > // org.apache.wicket's application setttings.
>> > final WebResponse response =
>> > webApplication.newWebResponse(servletResponse);
>> > response.setAjax(request.isAjax());
>> > response.setCharacterEncoding(webApplication.getRequestCycleSettings
>> > ().getResponseRequestEncoding());
>> >
>> > // Get session for request
>> > final WebSession session = webApplication.getSession(request,
>> response);
>> >
>> > RequestCycle cycle = session.newRequestCycle(request, response);
>> >
>> > we could do this:
>> >
>> >
>> >
>> > final WebRequest request =
>> webApplication.newWebRequest(servletRequest);
>> >
>> > // First, set the webapplication for this thread
>> > Application.set(webApplication);
>> >
>> > // Create a response object and set the output encoding according to
>> > // org.apache.wicket's application setttings.
>> > final WebResponse response =
>> > webApplication.newWebResponse(servletResponse);
>> > response.setAjax(request.isAjax());
>> > response.setCharacterEncoding(webApplication.getRequestCycleSettings
>> > ().getResponseRequestEncoding());
>> >
>> > RequestCycle cycle =
>> > webApplication.getRequestCycleFactory().newRequestCycle(request,
>> > response);
>> >
>> > // Get session for request
>> > final WebSession session = webApplication.getSession(request,
>> response);
>> >
>> >
>> > Then a request cycle is not a child anymore of the session.
>> > So a request cycle doesn't get the session in its constructor anymore.
>> (it
>> > doesn't have access at all to a session object)
>> >
>> > johan
>> >
>> >
>> >
>> >
>> >
>> > On 4/11/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Looked at it some more
>> >> this needs to be rollbacked. This is really really bad code.
>> >>
>> >> there are public methods called on the session object that is not
>> fully
>> >> constructed yet
>> >> And the this is given to the newRequestCycle() method.. What if people
>> >> want to use there
>> >> own Session object in the RequestCycle create?? That is impossible
>> >> because
>> >> the Session
>> >> object is not completely valid yet!
>> >>
>> >> We need to find another solution for this because this can't be done.
>> >>
>> >> On 4/11/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>> >> >
>> >> > in the constructor:
>> >> >
>> >> >     protected Session(Application application, Request request,
>> >> Response
>> >> > response)
>> >> >     {
>> >> >         // Construct request cycle (which sets thread local)
>> >> >         getRequestCycleFactory().newRequestCycle(this, request,
>> >> > response);
>> >> >
>> >> >
>> >> > and ofcourse normally in the WicketFilter.doGet()
>> >> >
>> >> > please don't tell me this change of the Session constructor
>> (suddenly
>> a
>> >> > response object as a param)
>> >> > and the construction of that request cycle is because of UNIT
>> TESTS????
>> >> > because that would be horrible that we change such a basic code just
>> >> for
>> >> > unit testing.
>> >> >
>> >> > johan
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/why-are-we-suddenly-creating-2-request-cycles--tf3557832.html#a9958131
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: 
http://www.nabble.com/why-are-we-suddenly-creating-2-request-cycles--tf3557832.html#a9958541
Sent from the Wicket - Dev mailing list archive at Nabble.com.

Reply via email to