Hehe, great :) So no problems after all?
2009/1/29 dukejansen <[email protected]>
>
> Okay, nevermind. It turns out the issue can be corrected much more simply,
> by
> using an "onclick" event type instead of a "click" event type, which
> arguably may have been obvious.
>
> I'm still not certain whether this will still work properly for
> AjaxFallbackLinks or other links that have both an onclick AND an href, but
> I believe for most/all of my use cases, that's not an issue...
>
> -Jason
>
>
> dukejansen wrote:
> >
> > The code I posted below actually doesn't even get called if the tag has
> an
> > onclick attribute...
> >
> > I'm working up a workaround now, I'll post it if it ends up working...
> >
> > -Jason
> >
> >
> > dukejansen wrote:
> >>
> >> Nino,
> >>
> >> Thanks for the quick reply...
> >>
> >> I dug a bit deeper and you are correct, it does have some hooks for
> >> handling Links, but it may only work for links which extend from the
> base
> >> Link class.
> >>
> >> // Try to bind to link so shortcut will work.
> Should only be done if
> >> // no other handlers were found
> >> if (component instanceof Link && eventType == null)
> {
> >> linkUnbound = true;
> >> return;
> >> }
> >>
> >> In my case, the link is an Ajax link which launches a Modal, and
> AjaxLink
> >> does not extend Link. Furthermore, the behavior of simply handling the
> >> link by calling location = href is not necessarily sufficient - I
> believe
> >> this would circumvent any onclick event handlers set on the tag, which
> >> would prevent the AjaxLink from working...
> >>
> >> I'm thinking the hook for ajax links probably needs to be something like
> >> a combination of the two mechanisms - instead of trying to call click(),
> >> which doesn't exist, would need to call the onclick() directly, and then
> >> check it's result and if true follow the link, if false do not... that
> >> way it could still handle the ajax fallback links as well, I believe.
> >>
> >> This is all theory, haven't actually verified any of this would work
> >> yet...
> >>
> >> On top of all this, I'm working with a 1.4 backport we made of the
> >> input-events code, so any fix I come up with will likely not make it
> back
> >> into the main trunk for the input-events module...
> >>
> >> -Jason
> >>
> >>
> >> Nino Martinez-2 wrote:
> >>>
> >>> I cant exactly remember what the scope where, just that it did support
> >>> links at some point, in safari and IE. Patches are always welcome..
> >>>
> >>> But looking in the source there are some auto hooking for links
> >>> actually, which uses href instead of click AFAIR it should just pick it
> >>> up automaticly...:
> >>>
> >>> <script type="text/javascript">
> >>> function init${wicketComponentId}() {
> >>> shortcut.add("${keys}",function() {
> >>>
> >>>
> >>> window.location=document.getElementById('${wicketComponentId}').href;
> >>>
> >>> },{
> >>> 'disable_in_input':${disable_in_input},
> >>> 'type':'${type}',
> >>> 'propagate':${propagate},
> >>> 'target':${target}
> >>>
> >>> });
> >>> }
> >>> init${wicketComponentId}();
> >>> </script>
> >>>
> >>> Did you check the examples, and see if they still are working, they do
> >>> include a link aswell?
> >>>
> >>>
> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/input-events-parent/input-events-examples
> >>>
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Issues-with-wicket-contrib-input-events-in-Mozilla-tp21718528p21732972.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]
>
>
