maybe what is needed is a "fail silently ajax request" ;-)

On Fri, Jul 4, 2014 at 5:36 PM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Hi,
>
>
> On Fri, Jul 4, 2014 at 4:59 PM, Daniel Stoch <daniel.st...@gmail.com>
> 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
>> <reier...@gmail.com> 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 <
>> > reier...@gmail.com> 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 <daniel.st...@gmail.com>
>> >> wrote:
>> >>
>> >>> On Fri, Jul 4, 2014 at 3:14 PM, Martin Grigorov <mgrigo...@apache.org
>> >
>> >>> 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 <
>> daniel.st...@gmail.com>
>> >>> wrote:
>> >>> >
>> >>> >> On Fri, Jul 4, 2014 at 12:33 PM, Sven Meier <s...@meiers.net>
>> 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: users-unsubscr...@wicket.apache.org
>> >>> >> >> For additional commands, e-mail: users-h...@wicket.apache.org
>> >>> >> >>
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> ---------------------------------------------------------------------
>> >>> >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >>> >> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >>> >> >
>> >>> >>
>> >>> >>
>> ---------------------------------------------------------------------
>> >>> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >>> >> For additional commands, e-mail: users-h...@wicket.apache.org
>> >>> >>
>> >>> >>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >>> For additional commands, e-mail: users-h...@wicket.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Regards - Ernesto Reinaldo Barreiro
>> >>
>> >
>> >
>> >
>> > --
>> > Regards - Ernesto Reinaldo Barreiro
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>



-- 
Regards - Ernesto Reinaldo Barreiro

Reply via email to