9:16 p.m.
I have this:
<h:inputText value="#{user.name}"...>
<f:ajax event="onkeyup" render="echo"/>
</h:inputText>
..
<h:outputText id="echo" value="#{user.name}"/>
That works fine. As I type in the input, whatever I type is echoed by the
output. But if I remove the event attribute, like this:
<h:inputText value="#{user.name}"...>
<f:ajax render="echo"/>
</h:inputText>
..
<h:outputText id="echo" value="#{user.name}"/>
For the preceeding markup, nothing is echoed as I type, or when I tab out of
the field. In fact, the only thing that happens is that I get a JS error
that says "sendAjaxRequest is not defined".
Is this a bug?
I've attached a snapshot of the error in Firebug.
Thanks,
david
8:36 a.m.
One thing that is wrong with your example (at least the code snippet
below) is you need to specify:
<f:ajax event="keyup".../> *not* event="onkeyup" (using
logical names).
Now... looking over the spec - specifically - Section 10.4.1.1 I don't
see any mention of this. So, I'm adding it to the errata.
Not sure how your example is working with "onkeyup".
when I remove the event attr , I'm not seeing your error. Is there
anything more that you have in your page that I'm not
seeing in your code snippet? Seems like the "chain" function is getting
called per your firebug output.
-roger
David Geary wrote:
I have this:
<h:inputText value="#{user.name <http://user.name>}"...>
<f:ajax event="onkeyup" render="echo"/>
</h:inputText>
...
<h:outputText id="echo" value="#{user.name
<http://user.name>}"/>
That works fine. As I type in the input, whatever I type is echoed by
the output. But if I remove the event attribute, like this:
<h:inputText value="#{user.name <http://user.name>}"...>
<f:ajax render="echo"/>
</h:inputText>
...
<h:outputText id="echo" value="#{user.name
<http://user.name>}"/>
For the preceeding markup, nothing is echoed as I type, or when I tab
out of the field. In fact, the only thing that happens is that I get a
JS error that says "sendAjaxRequest is not defined".
Is this a bug?
I've attached a snapshot of the error in Firebug.
Thanks,
david
------------------------------------------------------------------------
10:18 a.m.
Sorry, the whole thing was my blunder. It's working fine now.
david
2009/5/26 Roger Kitain <Roger.Kitain(a)sun.com>
One thing that is wrong with your example (at least the code snippet
below)
is you need to specify:
<f:ajax event="keyup".../> *not* event="onkeyup" (using
logical names).
Now... looking over the spec - specifically - Section 10.4.1.1 I don't see
any mention of this. So, I'm adding it to the errata.
Not sure how your example is working with "onkeyup".
Sorry, that was a typo.
when I remove the event attr , I'm not seeing your error. Is there
anything more that you have in your page that I'm not
seeing in your code snippet? Seems like the "chain" function is getting
called per your firebug output.
-roger
David Geary wrote:
> I have this:
>
> <h:inputText value="#{user.name <http://user.name>}"...>
> <f:ajax event="onkeyup" render="echo"/>
> </h:inputText>
> ...
> <h:outputText id="echo" value="#{user.name
<http://user.name>}"/>
>
> That works fine. As I type in the input, whatever I type is echoed by the
> output. But if I remove the event attribute, like this:
>
> <h:inputText value="#{user.name <http://user.name>}"...>
> <f:ajax render="echo"/>
> </h:inputText>
> ...
> <h:outputText id="echo" value="#{user.name
<http://user.name>}"/>
>
> For the preceeding markup, nothing is echoed as I type, or when I tab out
> of the field. In fact, the only thing that happens is that I get a JS error
> that says "sendAjaxRequest is not defined".
>
> Is this a bug?
>
> I've attached a snapshot of the error in Firebug.
>
> Thanks,
>
>
> david
>
>
>
> ------------------------------------------------------------------------
>
>
10:33 a.m.
On Tue, May 26, 2009 at 11:18 AM, David Geary <clarity.training(a)gmail.com>wrote:
Sorry, the whole thing was my blunder. It's working fine now.
david
2009/5/26 Roger Kitain <Roger.Kitain(a)sun.com>
> One thing that is wrong with your example (at least the code snippet
> below) is you need to specify:
> <f:ajax event="keyup".../> *not* event="onkeyup" (using
logical names).
> Now... looking over the spec - specifically - Section 10.4.1.1 I don't see
> any mention of this. So, I'm adding it to the errata.
> Not sure how your example is working with "onkeyup".
Sorry, that was a typo.
Could we just support both? It really depends on how you read it, but
onkeyup and keyup should be interchangeable. I guess implementations could
add this as an extension (to avoid such typos).
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
2:02 p.m.
On 5/26/09 8:33 AM, Dan Allen wrote:
On Tue, May 26, 2009 at 11:18 AM, David Geary
<clarity.training(a)gmail.com <mailto:clarity.training@gmail.com>> wrote:
Sorry, the whole thing was my blunder. It's working fine now.
david
2009/5/26 Roger Kitain <Roger.Kitain(a)sun.com
<mailto:Roger.Kitain@sun.com>>
One thing that is wrong with your example (at least the code
snippet below) is you need to specify:
<f:ajax event="keyup".../> *not* event="onkeyup"
(using
logical names).
Now... looking over the spec - specifically - Section 10.4.1.1 I
don't see any mention of this. So, I'm adding it to the errata.
Not sure how your example is working with "onkeyup".
Sorry, that was a typo.
Could we just support both? It really depends on how you read it, but
onkeyup and keyup should be interchangeable. I guess implementations
could add this as an extension (to avoid such typos).
I'd originally argued for supporting the "on" version of the names, but
the argument that carried the day was that the actual name of the event
would be both more concise, and more accurate.
The idea of supporting both is interesting (be liberal in what you
accept, after all), I don't think that it would cause any name conflicts.
However, at least in this case, the documentation is quite clear on this
point:
The DOM event name is the actual DOM event name (for example: "click")
as opposed to (for example: "onclick").
I suspect, however, it may be better to wait and see if this is a pain
point for users... It'd be easy to add this later without endangering
existing code.
Jim
4:16 p.m.
> Could we just support both? It really depends on how you read it, but
> onkeyup and keyup should be interchangeable. I guess implementations
> could add this as an extension (to avoid such typos).
>
I'd originally argued for supporting the "on" version of the names, but
the
argument that carried the day was that the actual name of the event would be
both more concise, and more accurate.
The idea of supporting both is interesting (be liberal in what you accept,
after all), I don't think that it would cause any name conflicts.
However, at least in this case, the documentation is quite clear on this
point:
The DOM event name is the actual DOM event name (for example: "click") as
opposed to (for example: "onclick").
I suspect, however, it may be better to wait and see if this is a pain
point for users... It'd be easy to add this later without endangering
existing code.
I supposed we could wait. However, the "on" prefix has been so ingrained in
developers minds that it is almost one of those things that developers
subconsciously add. For instance, in IE, the attachEvent() method has always
required the "on" prefix in the event name, even though the actual DOM event
name is the root word ("click" vs "onclick").
Anyone else on the EG have any thoughts about supporting both derivations
today?
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
4:48 p.m.
Dan Allen wrote:
Anyone else on the EG have any thoughts about supporting both
derivations today?
I do, since I was the one who pushed for the current solution. :-)
Will follow up with my thinking as soon as I get some free cycles here.
Andy
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a
week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
5:08 p.m.
I thought one of the reasons was that the "event" f:ajax attribute also
supports "valueChange" (for example) which is not a DOM event ..
I suppose we could change the docs to say that this attribute supports
the standard DOM events in addition to the faces events
"valueChange" (for EditableValueHolders) and "action" (for
ActionSource)...
-roger
Andy Schwartz wrote:
Dan Allen wrote:
>
> Anyone else on the EG have any thoughts about supporting both
> derivations today?
I do, since I was the one who pushed for the current solution. :-)
Will follow up with my thinking as soon as I get some free cycles here.
Andy
>
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://in.relation.to/Bloggers/Dan
>
> NOTE: While I make a strong effort to keep up with my email on a daily
> basis, personal or other work matters can sometimes keep me away
> from my email. If you contact me, but don't hear back for more than a
> week,
> it is very likely that I am excessively backlogged or the message was
> caught in the spam filters. Please don't hesitate to resend a
> message if
> you feel that it did not reach my attention.
12:13 a.m.
If we disallow the on...-syntax, we need to throw an exception if
someone provides us with an on...-value for the attribute - this is
the least we can do for our users!
regards,
Martin
On 5/27/09, Roger Kitain <Roger.Kitain(a)sun.com> wrote:
I thought one of the reasons was that the "event" f:ajax
attribute also
supports "valueChange" (for example) which is not a DOM event ..
I suppose we could change the docs to say that this attribute supports
the standard DOM events in addition to the faces events
"valueChange" (for EditableValueHolders) and "action" (for
ActionSource)...
-roger
Andy Schwartz wrote:
> Dan Allen wrote:
>>
>> Anyone else on the EG have any thoughts about supporting both
>> derivations today?
>
> I do, since I was the one who pushed for the current solution. :-)
>
> Will follow up with my thinking as soon as I get some free cycles here.
>
> Andy
>
>>
>> -Dan
>>
>> --
>> Dan Allen
>> Senior Software Engineer, Red Hat | Author of Seam in Action
>>
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>> http://in.relation.to/Bloggers/Dan
>>
>> NOTE: While I make a strong effort to keep up with my email on a daily
>> basis, personal or other work matters can sometimes keep me away
>> from my email. If you contact me, but don't hear back for more than a
>> week,
>> it is very likely that I am excessively backlogged or the message was
>> caught in the spam filters. Please don't hesitate to resend a
>> message if
>> you feel that it did not reach my attention.
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
11:35 a.m.
Behavior tag always throws exception in attempt to bind for unregistered
event, so <f:ajax event="onclick" > will cause an error.
Martin Marinschek wrote:
If we disallow the on...-syntax, we need to throw an exception if
someone provides us with an on...-value for the attribute - this is
the least we can do for our users!
regards,
Martin
On 5/27/09, Roger Kitain <Roger.Kitain(a)sun.com> wrote:
> I thought one of the reasons was that the "event" f:ajax attribute also
> supports "valueChange" (for example) which is not a DOM event ..
> I suppose we could change the docs to say that this attribute supports
> the standard DOM events in addition to the faces events
> "valueChange" (for EditableValueHolders) and "action" (for
ActionSource)...
>
> -roger
>
> Andy Schwartz wrote:
>> Dan Allen wrote:
>>> Anyone else on the EG have any thoughts about supporting both
>>> derivations today?
>> I do, since I was the one who pushed for the current solution. :-)
>>
>> Will follow up with my thinking as soon as I get some free cycles here.
>>
>> Andy
>>
>>> -Dan
>>>
>>> --
>>> Dan Allen
>>> Senior Software Engineer, Red Hat | Author of Seam in Action
>>>
>>> http://mojavelinux.com
>>> http://mojavelinux.com/seaminaction
>>> http://in.relation.to/Bloggers/Dan
>>>
>>> NOTE: While I make a strong effort to keep up with my email on a daily
>>> basis, personal or other work matters can sometimes keep me away
>>> from my email. If you contact me, but don't hear back for more than a
>>> week,
>>> it is very likely that I am excessively backlogged or the message was
>>> caught in the spam filters. Please don't hesitate to resend a
>>> message if
>>> you feel that it did not reach my attention.
>
11:51 a.m.
Gang -
Sorry I wasn't able to follow up on this sooner...
The main reason I pushed for using the event type (eg. "click") over the
HTML attribute name (eg. "onclick") was that this is consistent with
similar technologies, such as DOM event listeners. When registering a
listener via the standard DOM APIs, the event type is identified using
the event name (not the "on"-prefixed attribute name). That is, we specify:
domElement.addEventListener("click", listener);
Not:
domElement.addEventListener("onclick", listener);
I believe that the same approach for ClientBehaviorHolder:
behaviorHolder.addClientBehavior("click", behavior);
And by extension <f:ajax>:
<f:ajax event="click"/>
More closely matches this well-known model.
Another parallel can be found in the W3C XML Events spec:
http://www.w3.org/TR/xml-events/Overview.html#section-listener-element
Where the <listener> has an "event" attribute that specified the event
type (not the on-prefixed attribute name):
<listener event="click" observer="para1"
target="link1"
handler="#clicker"/>
Which of course is very similar to the <f:ajax> "event" attribute.
So I think we've got the right approach in place, or at least, we are in
good company with our current approach.
Rather than doubling the # of supported event names, I would like to
stick with a single set of events. People seem to be able to deal with
this pattern when using DOM event listeners - think we should be okay
with JSF behaviors. Of course, we can re-evaluate if this does become a
pain point.
3rd party components are free to specify whatever event names they
prefer, though for the sake of consistency across component sets I do
think it would be beneficial to follow the event name conventions used
by the components in the standard HTML renderkit.
One thing that I completely agree with is that we need to provide clear
error handling for cases where the page author specifies the wrong
name. Currently, for this invalid event name:
<h:commandButton>
<f:ajax event="foo"/>
</h:commandButton>
Mojarra displays the following error message:
/home.xhtml @73,33 <f:ajax> Event attribute could not be
determined: foo
I have opened the following Mojarra issue to request that we improve
this message:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1138
And I have also uploaded a patch which changes the message to:
/home.xhtml @73,33 <f:ajax> 'foo' is not a supported
event for
HtmlCommandButton. Please specify one of these supported event names:
action,
blur, change, click, dblclick, focus, keydown, keypress, keyup, mousedown,
mousemove, mouseout, mouseover, mouseup, select.
Hopefully this will help get our users headed in the right direction.
(Oh, if one of the Mojarra guys could take a look at my patch and let me
know if I can commit it, that would be great.)
Andy
Martin Marinschek wrote On 5/27/2009 1:13 AM ET:
If we disallow the on...-syntax, we need to throw an exception if
someone provides us with an on...-value for the attribute - this is
the least we can do for our users!
regards,
Martin
On 5/27/09, Roger Kitain <Roger.Kitain(a)sun.com> wrote:
> I thought one of the reasons was that the "event" f:ajax attribute also
> supports "valueChange" (for example) which is not a DOM event ..
> I suppose we could change the docs to say that this attribute supports
> the standard DOM events in addition to the faces events
> "valueChange" (for EditableValueHolders) and "action" (for
ActionSource)...
>
> -roger
>
> Andy Schwartz wrote:
>
>> Dan Allen wrote:
>>
>>> Anyone else on the EG have any thoughts about supporting both
>>> derivations today?
>>>
>> I do, since I was the one who pushed for the current solution. :-)
>>
>> Will follow up with my thinking as soon as I get some free cycles here.
>>
>> Andy
>>
>>
>>> -Dan
>>>
>>> --
>>> Dan Allen
>>> Senior Software Engineer, Red Hat | Author of Seam in Action
>>>
>>> http://mojavelinux.com
>>> http://mojavelinux.com/seaminaction
>>> http://in.relation.to/Bloggers/Dan
>>>
>>> NOTE: While I make a strong effort to keep up with my email on a daily
>>> basis, personal or other work matters can sometimes keep me away
>>> from my email. If you contact me, but don't hear back for more than a
>>> week,
>>> it is very likely that I am excessively backlogged or the message was
>>> caught in the spam filters. Please don't hesitate to resend a
>>> message if
>>> you feel that it did not reach my attention.
>>>
>
12:38 p.m.
On Thu, May 28, 2009 at 12:51 PM, Andy Schwartz <andy.schwartz(a)oracle.com>wrote:
Gang -
Sorry I wasn't able to follow up on this sooner...
The main reason I pushed for using the event type (eg. "click") over the
HTML attribute name (eg. "onclick") was that this is consistent with similar
technologies, such as DOM event listeners. When registering a listener via
the standard DOM APIs, the event type is identified using the event name
(not the "on"-prefixed attribute name). That is, we specify:
domElement.addEventListener("click", listener);
Not:
domElement.addEventListener("onclick", listener);
I believe that the same approach for ClientBehaviorHolder:
behaviorHolder.addClientBehavior("click", behavior);
And by extension <f:ajax>:
<f:ajax event="click"/>
More closely matches this well-known model.
Another parallel can be found in the W3C XML Events spec:
http://www.w3.org/TR/xml-events/Overview.html#section-listener-element
Where the <listener> has an "event" attribute that specified the event
type
(not the on-prefixed attribute name):
<listener event="click" observer="para1"
target="link1"
handler="#clicker"/>
Which of course is very similar to the <f:ajax> "event" attribute.
So I think we've got the right approach in place, or at least, we are in
good company with our current approach.
Consistency is good. I can't argue with that. We've just had to wade through
such turbulent waters in the past that you do question yourself the first
couple of times you work with the events (as I mentioned, attachEvent() in
IE requires the on prefix. But we are making a decisive commitment to
aligning with standards.
I would love to see the text you just typed in the non-normative background
part of the spec (perhaps something as concise as "In choosing event names,
we are following well defined standards in JavaScript DOM and W3C XML Events
spec by using the literal event name and excluding any prefix such as
'on'."). Then, people will remember that and never second guess again.
(Section 3.7.1)
Rather than doubling the # of supported event names, I would like to stick
with a single set of events. People seem to be able to deal with this
pattern when using DOM event listeners - think we should be okay with JSF
behaviors. Of course, we can re-evaluate if this does become a pain point.
The importance here is making it well-known. If we come out of the gate with
a strong statement that is memorable, it will never become a pain point.
3rd party components are free to specify whatever event names they prefer,
though for the sake of consistency across component sets I do think it would
be beneficial to follow the event name conventions used by the components in
the standard HTML renderkit.
One thing that I completely agree with is that we need to provide clear
error handling for cases where the page author specifies the wrong name.
Currently, for this invalid event name:
<h:commandButton>
<f:ajax event="foo"/>
</h:commandButton>
Mojarra displays the following error message:
/home.xhtml @73,33 <f:ajax> Event attribute could not be determined: foo
I have opened the following Mojarra issue to request that we improve this
message:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1138
A good error message is going to avoid a lot of complaining. That's really
all I want to avoid. Those nagging complaints that have haunted JSF in the
past.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
5686
days inactive
5688
days old
jsr-314-open-mirror@lists.jboss.org
11 comments
7 participants
participants (7)
-
Alexander Smirnov -
Andy Schwartz -
Dan Allen -
David Geary -
Jim Driscoll -
Martin Marinschek -
Roger Kitain