You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Nacho Estrada Lachós <na...@dbs.es> on 2006/10/05 08:16:08 UTC

sandbox stateChangedNotifier

Hi all,
It seems to be a strange behaviour in Tomahawk-sandbox
stateChangedNotifier component.
Everything is fine when it's used from a commandLink, but when a
commandButton fires the dialog, the confirmation dialog dissapear in a few
seconds.
Any walkarround for this?
Should I report this in the developers mail list?

Thanks in advance,

Nacho Estrada.


Re: sandbox stateChangedNotifier

Posted by Werner Punz <we...@gmx.at>.
Werner Punz schrieb:

> A submit button however submits a form directly without a huge chance of
> javascript interference upfront, hence the dialog popup and hence
> the submit despite the dialog.
> I am not sure if this is fixable at all, I can remember something along
> those lines, but I will relook into it tomorrow.
> 

No need to look into it anymore... a command button renders into a
submit button, as is, this is not fixable in the fast lane, use command
links instead, if possible, and if have to use command buttons, use
server side onchange events which also work for state change checking.



Re: sandbox stateChangedNotifier

Posted by Werner Punz <we...@gmx.at>.
Nacho Estrada Lachós schrieb:
> Hi all,
> It seems to be a strange behaviour in Tomahawk-sandbox
> stateChangedNotifier component.
> Everything is fine when it's used from a commandLink, but when a
> commandButton fires the dialog, the confirmation dialog dissapear in a few
> seconds.
> Any walkarround for this?
> Should I report this in the developers mail list?
>  

No, I am the maintainer for this beast (and a beast it is) I will look
into this. Have in mind that the state change notifier is heavily
experimental and due to the way it works it will fail on some components
(inherently for instance on tabbed controls and some dhtml stuff, since
it uses generic dom tree walking to find the components, and then alters
the onclick on the controls itself by wrapping itself around the
existing onclicks)


A submit button however submits a form directly without a huge chance of
javascript interference upfront, hence the dialog popup and hence
the submit despite the dialog.
I am not sure if this is fixable at all, I can remember something along
those lines, but I will relook into it tomorrow.

The workaround for this is just to use a command links and no command
buttons. Afair there was an issue with the command buttons that they
issued the command despite the fact that onsubmit or onclick was altered...

another workaround is to bypass the state change notifier at all and use
jsfs server side infrastructure for additional state change checking.