by numerous you mean two?

by default wicket uses something similar to redirect-after-post so
after you click a link there is a http redirect to a view-url that
will no longer execute the link. so that is two http requests/two
request cycles.

-igor

On Wed, Aug 13, 2008 at 7:18 AM, Benny Weingarten <[EMAIL PROTECTED]> wrote:
>
> Thanks Igor.
>
> I have done that, and it is exactly what I was looking for.
>
> However, I have noticed something that strikes me odd:
> on every request to render a page in my application (every time I click a
> link in my application to another page in my application), the method
> newRequestCycle() in WebApplication is called numerous times, and
> subsequently, my pre-render actions are performed many times. Is this
> expected? shouldn't one page require only one RequestCycle?
>
> thanks,
> Benny.
>
>
>
>
> igor.vaynberg wrote:
>>
>> create a custom request cycle and put this stuff in
>> requestcycle#onbeginrequest
>>
>> -igor
>>
>> On Sun, Aug 10, 2008 at 11:15 PM, Benny Weingarten
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> Hello.
>>>
>>> I'm writing a wicket application for facebook, but I think my problem may
>>> be
>>> common to many wicket applications.
>>>
>>> In my case, I'm using the wicket-facebook authentication strategy that is
>>> described in a different thread here on nabble. That works great - when a
>>> page is rendered, the AuthenticationStrategy makes sure that I have a
>>> valid
>>> FacebookRestClient object in my session.
>>> In my application I need to do some other "init" stuff in a service
>>> class,
>>> and I do that in the onUnauthorizedInstantiation method. This "init"
>>> information is stored in a ThreadLocal variable in my BACKEND-Service.
>>> This
>>> is an important point, because wicket uses many different threads for
>>> user
>>> requests, so I need to make sure that in the beginning of each render
>>> request, the init information is stored on THAT REQUEST's thread.
>>>
>>> ALL my components in all my pages and panels try to fetch information
>>> from
>>> the BACKEND-Service. If the BACKEND-Service hasn't been initialized with
>>> the
>>> "init" information on the ThreadLocal variable on the same thread that
>>> the
>>> render request is issued on, an exception would be thrown and the page
>>> would
>>> fail to render.
>>>
>>> This is all great when a user is browsing through PAGES. However, in one
>>> page I have a tabbedpanel. When first the user loads the page, the
>>> authorization strategy kicks in, and the init actions are performed, the
>>> page renders correctly.
>>>
>>> *** and here is my problem:
>>> when the user clicks on the second tab in the page, the request can be
>>> made
>>> from a different thread (wicket controls that), but the "init" stuff is
>>> not
>>> performed because it is not a new page that needs to be rendered. This
>>> problem also arises when I use ajax components.
>>>
>>> I thought of putting the init stuff in the "onBeforeRender()" method of
>>> each
>>> separate component that requires the "init" information.
>>>
>>> Would this be the preferred way of doing "init" actions for components?
>>>
>>> Thanks,
>>> Benny.
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Pre-render-action-common-to-all-pages-tp18920691p18920691.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
> --
> View this message in context: 
> http://www.nabble.com/Pre-render-action-common-to-all-pages-tp18920691p18963966.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to