I think the simplest solution for now (until we invent a better one)
is to define a dedicated exception class for such case (similar to
ListenerInvocationNotAllowedException which is raised if user tries
click on disabled links). Then we can catch such exception and handle
it eg. as described by Martin in my previous post ("How to handle
click on disabled links - ListenerInvocationNotAllowedException?").-- Daniel On Fri, Jul 4, 2014 at 5:38 PM, Ernesto Reinaldo Barreiro <[email protected]> wrote: > maybe what is needed is a "fail silently ajax request" ;-) > > > On Fri, Jul 4, 2014 at 5:36 PM, Ernesto Reinaldo Barreiro < > [email protected]> wrote: > >> Hi, >> >> >> On Fri, Jul 4, 2014 at 4:59 PM, Daniel Stoch <[email protected]> >> wrote: >> >>> Sorry, but for me all these solutions are hacks :). >>> >> >> Why? As far as they are under control... Isn't software development >> production controlled "hacks"? Wicket itself is a "hack" and so do are >> other WEB frameworks like GWT. As far as you remain in control I do not see >> the problem. All frameworks have limitations... Why not get the best of >> them and circumvent those. >> >> >>> I want to use standard components (eg. AjaxLink) to do simple things. >>> I don't want to think everywhere how to handle such scenarios. It >>> should be handled properly on a framework level. I think there is >>> always possibility that component state on server and DOM tree on >>> client browser are inconsistent (and not necessary because of push >>> requests). Maybe it should be a dedicated exception on such situation >>> ("Component 'xxx' has been removed from page.") at least or maybe we >>> can invent a better solution in core? >>> >> >> I do agree that would be optimal. >> >> >> >>> >>> -- >>> Daniel >>> >>> On Fri, Jul 4, 2014 at 4:11 PM, Ernesto Reinaldo Barreiro >>> <[email protected]> wrote: >>> > Maybe you could even just push JSON to client side and generate items >>> > content at client side which is going to be way faster >>> > >>> > >>> > On Fri, Jul 4, 2014 at 4:06 PM, Ernesto Reinaldo Barreiro < >>> > [email protected]> wrote: >>> > >>> >> Why don't you try routing all the click to a part of you application >>> that >>> >> is always available? E.g. >>> >> >>> >> 1- You have a list of items that are pushed... They are in a certain >>> >> container that is "always" there... At client and server side >>> >> 2- The items are pushed but instead of normal AJAX link you use link to >>> >> the parent never changing container passing ID of item. This way click >>> will >>> >> never fail and it is still sort of object oriented... >>> >> >>> >> >>> >> >>> >> On Fri, Jul 4, 2014 at 3:59 PM, Daniel Stoch <[email protected]> >>> >> wrote: >>> >> >>> >>> On Fri, Jul 4, 2014 at 3:14 PM, Martin Grigorov <[email protected] >>> > >>> >>> wrote: >>> >>> > Hi, >>> >>> > >>> >>> > You can use Atmopshere to hide/disable the client side too, not >>> just the >>> >>> > server side. >>> >>> >>> >>> Of course, I already do that. >>> >>> But user can click the link after state was changed on the server side >>> >>> but before these changes are pushed to client browser. >>> >>> >>> >>> -- >>> >>> Daniel >>> >>> >>> >>> >>> >>> > >>> >>> > Martin Grigorov >>> >>> > Wicket Training and Consulting >>> >>> > https://twitter.com/mtgrigorov >>> >>> > >>> >>> > >>> >>> > On Fri, Jul 4, 2014 at 1:46 PM, Daniel Stoch < >>> [email protected]> >>> >>> wrote: >>> >>> > >>> >>> >> On Fri, Jul 4, 2014 at 12:33 PM, Sven Meier <[email protected]> >>> wrote: >>> >>> >> >> So page was rendered in a browser, >>> >>> >> >> on the server component tree was changed >>> >>> >> > >>> >>> >> > >>> >>> >> > What triggers the change to the component tree? On which thread? >>> Are >>> >>> you >>> >>> >> > using websockets? >>> >>> >> > >>> >>> >> > Sven >>> >>> >> >>> >>> >> In general this thread is not initialized by user action but by >>> >>> >> application. So yes, it can be push from a server (eg. using >>> >>> >> Atmosphere - this is my case) or by ajax self updating behavior. >>> >>> >> >>> >>> >> -- >>> >>> >> DS >>> >>> >> >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> > On 07/04/2014 12:13 PM, Daniel Stoch wrote: >>> >>> >> >> >>> >>> >> >> Hi all, >>> >>> >> >> >>> >>> >> >> I think such question occurs from time to time on this list, >>> but I >>> >>> >> >> have never found a good answer how to solve such problem in >>> general. >>> >>> >> >> The problem is similar to my last question: >>> >>> >> >> >>> >>> >> >> >>> >>> >> >>> >>> >>> http://apache-wicket.1842946.n4.nabble.com/How-to-handle-click-on-disabled-links-ListenerInvocationNotAllowedException-td4666287.html >>> >>> >> >> but now there is a situation when link was removed from page >>> (not >>> >>> >> >> disabled). >>> >>> >> >> >>> >>> >> >> So page was rendered in a browser, on the server component tree >>> was >>> >>> >> >> changed, but user clicks a link in a browser before this changes >>> >>> will >>> >>> >> >> be pushed to it. It leads to an exception: >>> >>> >> >> >>> >>> >> >> org.apache.wicket.WicketRuntimeException: Component 'xxx' has >>> been >>> >>> >> >> removed from page. >>> >>> >> >> at >>> >>> >> >> >>> >>> >> >>> >>> >>> org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:178) >>> >>> >> >> at >>> >>> >> >> >>> >>> >> >>> >>> >>> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862) >>> >>> >> >> at >>> >>> >> >> >>> >>> >> >>> >>> >>> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) >>> >>> >> >> at >>> >>> >> >> >>> >>> >> >>> >>> >>> org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261) >>> >>> >> >> at >>> >>> >> >> >>> >>> >> >>> >>> >>> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218) >>> >>> >> >> at >>> >>> >> >> >>> >>> >> >>> >>> >>> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) >>> >>> >> >> at >>> >>> >> >> >>> >>> >> >>> >>> >>> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) >>> >>> >> >> at >>> >>> >> >> >>> >>> >> >>> >>> >>> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) >>> >>> >> >> at >>> >>> >> >> >>> >>> >> >>> >>> >>> org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137) >>> >>> >> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:735) >>> >>> >> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) >>> >>> >> >> >>> >>> >> >> How it should be properly handled in application? Unfortunately >>> this >>> >>> >> >> is not a dedicated exception to catch somewhere, but a common >>> >>> >> >> WicketRuntimeException. >>> >>> >> >> >>> >>> >> >> -- >>> >>> >> >> Best regards, >>> >>> >> >> Daniel >>> >>> >> >> >>> >>> >> >> >>> >>> --------------------------------------------------------------------- >>> >>> >> >> 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] >>> >>> >> > >>> >>> >> >>> >>> >> >>> --------------------------------------------------------------------- >>> >>> >> 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] >>> >>> >>> >>> >>> >> >>> >> >>> >> -- >>> >> Regards - Ernesto Reinaldo Barreiro >>> >> >>> > >>> > >>> > >>> > -- >>> > Regards - Ernesto Reinaldo Barreiro >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> -- >> Regards - Ernesto Reinaldo Barreiro >> > > > > -- > Regards - Ernesto Reinaldo Barreiro --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
