the response hasnt been flushed yet if you are using render-to-buffer strategy which is default. but. like i said, the kinds of errors you are catching here should never happen in production - these are really the "i wrote code but didnt even try it yet" kinds of errors.
-igor On 2/22/07, Oscar Bueno <[EMAIL PROTECTED]> wrote:
are you talking about add javascript code in the decorateOnFailureScript of the IAjaxCallDecorator? It means that I can't use my ErrorPanel component as response, and what is more important for me, I can not handle my conversation data correctly, you have to know that we are using a flow handler that have to be informed that the flow conversation is broken, because what the AjaxRequestTarget respond was doing is render a new flow view state (Panel), and I would want redirect the flow to an error state, because this new view state has not been rendered. Probabily what I want to do is not possible here if the response is already flushed, I don't know that. Oscar. igor.vaynberg wrote: > > in case what error though? > > respond() is called after all events have been processed > > so these are only types of errors that are render errors - like you have a > component with the wrong id or something > > you can handle errors like that with wicket's javascript error hook > > -igor > > > On 2/22/07, Oscar Bueno <[EMAIL PROTECTED]> wrote: >> >> >> I'm using the AjaxRequestTarget to replace a wizard panel, in case of >> error, >> I would display an errors panel instance of the original panel. >> >> I have created a jira issue: >> https://issues.apache.org/jira/browse/WICKET-313 >> >> Oscar. >> >> >> igor.vaynberg wrote: >> > >> > whats the usecase btw? what are you going to do with that exception? >> those >> > are only render-time exceptions, dont see what use they are to you >> > >> > -igor >> > >> > >> > On 2/22/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: >> >> >> >> irequesttarget.respond doesnt declare it throws any exceptions, so we >> >> would need to refactor ajaxrequesttarget.respond into some protected >> >> method. >> >> >> >> add a jira issue >> >> >> >> -igor >> >> >> >> >> >> On 2/21/07, Oscar Bueno <[EMAIL PROTECTED]> wrote: >> >> > >> >> > >> >> > Hi, >> >> > >> >> > Now the respond method of the AjaxRequestTarget is caching all the >> >> > RuntimeExceptions that are throwed. I would prefer to handle this >> >> > exceptions by myself. I have a requestTarget that is a wrapper of >> the >> >> > wicket AjaxRequestTarget where we could made something in case of >> >> errors >> >> > in >> >> > the respond method of the AjaxRequestTarget. >> >> > >> >> > Oscar. >> >> > -- >> >> > View this message in context: >> >> > >> >> >> http://www.nabble.com/AjaxRequestTarget-respond-exception-handling-tf3271255.html#a9095216 >> >> > Sent from the Wicket - Dev mailing list archive at Nabble.com. >> >> > >> >> > >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/AjaxRequestTarget-respond-exception-handling-tf3271255.html#a9108547 >> Sent from the Wicket - Dev mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/AjaxRequestTarget-respond-exception-handling-tf3271255.html#a9114324 Sent from the Wicket - Dev mailing list archive at Nabble.com.
