Re: Default focus behavior for ajax request

2007-09-11 Thread Matej Knopp
Because currently there is no way during ajax processing to determine
that the event was a focus related one. I think that it's good to
restore focus on last focused element by default. But I'm also aware
that it causes problems with focus related event, so i think maybe we
should just call target.focusCompnent(null) in abstract ajax event
behavior if the event is onblur. Can you submit RFE?

-Matej

On 9/11/07, Carlos Pita [EMAIL PROTECTED] wrote:
 Hi,

 why is the default behavior for ajax requests to force focus into some
 component (normally the one which triggered the event that caused the
 request, I guess)? This produces some bizarre situations when onfocus
 or onblur are used for ajax validation. For example, if the form
 component to be validated gets its focus transferred to some browser
 ui widget (for example, the location bar), triggering an onblur
 validation this way, it immediately recaptures focus after validation
 has been completed (making it impossible to type text at the location
 bar unless your fingers happen to be faster than the ajax rtt, to
 follow the example). A similar problem occurs with tinymce editor, at
 least. This behavior can be circumvented explicitly setting
 target.focusComponent(null) for validation purposes, but why is it not
 this way in the first place, at least for the focus related events? Is
 there any rationale behind this that I'm missing?

 Regards,
 Carlos

 -
 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]



Re: Default focus behavior for ajax request

2007-09-11 Thread Carlos Pita
 behavior if the event is onblur. Can you submit RFE?

Done. I filed it as minor improvement
https://issues.apache.org/jira/browse/WICKET-957.

 Because currently there is no way during ajax processing to determine
 that the event was a focus related one. I think that it's good to

Maybe setting focusComponent to null by default for any
AjaxEventBehavior whose event happens to be onblur or onchange will be
enough. Even if done at the AjaxFormComponentUpdatingBehavior imo this
will be a great relief for people who are implementing their first
wicket ajax-validated forms and haven't a clue about the cause of such
a strange focus behavior that suddenly possesses their browsers.

Regards,
Carlos

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Default focus behavior for ajax request

2007-09-11 Thread Johan Compagner
see my comments in that issue.
Its not that we have to do something on the serverside this is a clientside
issue.

johan


On 9/11/07, Carlos Pita [EMAIL PROTECTED] wrote:

  behavior if the event is onblur. Can you submit RFE?

 Done. I filed it as minor improvement
 https://issues.apache.org/jira/browse/WICKET-957.

  Because currently there is no way during ajax processing to determine
  that the event was a focus related one. I think that it's good to

 Maybe setting focusComponent to null by default for any
 AjaxEventBehavior whose event happens to be onblur or onchange will be
 enough. Even if done at the AjaxFormComponentUpdatingBehavior imo this
 will be a great relief for people who are implementing their first
 wicket ajax-validated forms and haven't a clue about the cause of such
 a strange focus behavior that suddenly possesses their browsers.

 Regards,
 Carlos

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: Default focus behavior for ajax request

2007-09-11 Thread Carlos Pita
Dunno. Up till now my workaround is to set focusComponent to null at
the server-side for validation purposes. I'm not suggesting that this
should be wicket's approach or something similar, of course.

Regards,
Carlos

On 9/11/07, Johan Compagner [EMAIL PROTECTED] wrote:
 see my comments in that issue.
 Its not that we have to do something on the serverside this is a clientside
 issue.

 johan


 On 9/11/07, Carlos Pita [EMAIL PROTECTED] wrote:
 
   behavior if the event is onblur. Can you submit RFE?
 
  Done. I filed it as minor improvement
  https://issues.apache.org/jira/browse/WICKET-957.
 
   Because currently there is no way during ajax processing to determine
   that the event was a focus related one. I think that it's good to
 
  Maybe setting focusComponent to null by default for any
  AjaxEventBehavior whose event happens to be onblur or onchange will be
  enough. Even if done at the AjaxFormComponentUpdatingBehavior imo this
  will be a great relief for people who are implementing their first
  wicket ajax-validated forms and haven't a clue about the cause of such
  a strange focus behavior that suddenly possesses their browsers.
 
  Regards,
  Carlos
 
  -
  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]



Default focus behavior for ajax request

2007-09-10 Thread Carlos Pita
Hi,

why is the default behavior for ajax requests to force focus into some
component (normally the one which triggered the event that caused the
request, I guess)? This produces some bizarre situations when onfocus
or onblur are used for ajax validation. For example, if the form
component to be validated gets its focus transferred to some browser
ui widget (for example, the location bar), triggering an onblur
validation this way, it immediately recaptures focus after validation
has been completed (making it impossible to type text at the location
bar unless your fingers happen to be faster than the ajax rtt, to
follow the example). A similar problem occurs with tinymce editor, at
least. This behavior can be circumvented explicitly setting
target.focusComponent(null) for validation purposes, but why is it not
this way in the first place, at least for the focus related events? Is
there any rationale behind this that I'm missing?

Regards,
Carlos

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]