Sorry be be hard-nosed about this, but... This isn't really the place to discuss implementation bugs. Rather, if you have specific concerns about the specification, they should be discussed here. That would typically imply that you would refer to an area of the spec when reporting such bugs. We're going to have to start enforcing this rule vigorously if we open this list up more to the public, or else we're going to end up getting swamped in "my component doesn't work" emails, and we'll be unable to get anything else done.

That said, your mail brings up a few gaps in the specification, though you don't refer explicitly to the spec.

Spec bug 1: There is no defined way to specify an arbitrary method to be called server-side on the execution of a jsf.ajax.request function call. This is an oversight in the spec, and it should be addressed for 2.1. In the meantime, you can get *almost* equivalent functionality by using a valueChange listener or an action listener in most cases. I've filed spec bug 672 to track this issue. This isn't the first time it's come up, but no one bothered to file it last time, apparently - I thought they had. https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=672 The workaround you tried, adding the listener then calling the request manually, is just that, a workaround, that had never (that I know of) been tried before we released - so it's not surprising to me that it ran into trouble of various sorts. The behavior you found is probably a bug (but possibly not, I'll have to code trace and look at the spec to be sure), please file it against the implementation, and I'll take a look when I have time. Setting the javax.faces.behavior.event parameter to action should happen automatically for buttons - but that's an implementation specific detail at this point - it's not in the spec. And as such, you *really* shouldn't be talking about it in a book about standard JSF practice. I'd much rather you encourage end users to use action listeners and valuechange listeners, for which I have a number of demos. The functionality is roughly equivalent, though they'll still function if JavaScript is also disabled in the page - which I'd regard as a feature, rather than a drawback (and which is why it's probably better practice to do it that way for most uses). Where this turns a little silly, of course, is in the case that you're trying - a disconnected request that attempts to run an arbitrary method. But even that has a simple (if inelegant) workaround - a hidden button. I wrote a demo that does poll, and is in the Mojarra samples - did you look at it? It uses that hidden button mechanism to get around the same problem you're encountering. It doesn't cancel, but that's trivial to add. Doing it your proposed way, by registering an ajax listener, is also fraught for another reason that I don't think you've yet considered: event names. The javax.faces.behavior.event parameter is not part of the spec. So, if you want to trigger it for something besides "action", you can't. Even when (if) I do fix the above bug. And, as I said, allowing arbitrary method calls from jsf.ajax.request is something that really should be in 2.1. And it will probably mean setting the "unintuitive" javax.faces.behavior.event parameter, unless someone can come up with a more elegant way. Hopefully, someone will. Your second reported bug is almost certainly an implementation bug. Please file it - as I said, this isn't the place to discuss implementation bugs. We often discuss implementation bugs on webtier(a)glassfish.dev.java.net, if you'd like to subscribe. I'm running a little behind on there (we're doing a release right now), but we have a pretty good answer rate. Again, I'm sorry to come off as not caring about this - I care very much about every bug we find. But I know from past experience that if we let the discussion deviate from the charter of this list, It Won't End Well. Jim P.S. Ken - the suggestion to cancel an in process request is one that I used to favor as well, but that brings up data integrity and consistency issues that are better handled server side. So I'm now reluctantly against allowing that (at least the simple case - though canceling a request that hasn't yet begun would be something that I'd like to support). But still, if you would like to see this in 2.1, please file a spec feature request. On 11/17/09 8:21 AM, David Geary wrote: > I meant to send this to the open mailing list in the first place, so I'm > forwarding my original message and Ken's response. > > ---------- Forwarded message ---------- > From: *Ken Paulsen* <Ken.Paulsen(a)sun.com <mailto:Ken.Paulsen@sun.com>> > Date: 2009/11/16 > Subject: Re: [jsr-314-eg] Ajax bugs? > To: jsr-314-eg(a)jcp.org <mailto:jsr-314-eg@jcp.org> > Cc: Cay Horstmann <cay(a)horstmann.com <mailto:cay@horstmann.com>> > > > > Below are some of my experiences... may be helpful, may not be. :) > > Ken > > > David Geary wrote: > >> Sorry for the long email, but it should be easy to grok. >> >> I'm trying to get a simple Ajax polling example working, and I'm not >> having much luck. I think I'm running across two Ajax bugs in mojarra. >> Here's my markup: >> >> <h:form prependId="false"> >> >> <h:commandButton value="Start polling" id="startPollingButton" >> onclick="startPolling(this, event, >> 'pollOutput')" >> action="#{user.incrementPollIndex}"> >> >> <f:ajax listener="#{user.ajaxListener}"/> >> >> </h:commandButton> >> >> <br/> >> >> <h:outputText value="pollOutput is: #{user.pollIndex}" id="pollOutput"/> >> >> <br/> >> >> <h:commandButton id="stopPollingButton" value="Stop polling" >> action="#{user.stopPolling}"/> >> >> </h:form> >> >> I have two buttons, one to start polling, and the other to stop. I >> also have an output that displays a backing bean property >> (#{user.pollIndex}). When you click the start button, it calls my >> startPolling JavaScript function. That function starts a timer which >> repeatedly calls jsf.ajax.request(): >> >> <script type="text/javascript"> >> function startPolling(component, event, renderComponents) { >> var pollFunction = function poll() { >> jsf.ajax.request(component.id <http://component.id>;, >> >> event, { render: renderComponents } ) >> } >> var timer = window.setInterval(pollFunction, 200); >> } >> </script> >> >> Bug #1: Ajax listener is not invoked when I call jsf.ajax.request() >> manually. >> > I ran into the same issue when trying to do something similar recently. > This should make what you have work: > > function startPolling(component, event, renderComponents) { > var props = { > execute: component.id <http://component.id>; > render: renderComponents; > } > props[component.id <http://component.id>] = component.id > <http://component.id>; > > var pollFunction = function poll() { > jsf.ajax.request(component, event, props); > } > window.setInterval(pollFunction, 200); > } > > I am not sure if the component.id <http://component.id> = component.id > <http://component.id> in "props" is necessary, it is for the button > > component that I am using and I haven't spent the time to find out why > or if it is also needed for h:* components. I think the execute one is > needed also. You can also use '@all' to execute everything (or render > everything). Also, it's better to pass in 'component' instead of > 'component.id <http://component.id>' for the src argument since the > > implementation just searches for 'component' again if you don't pass it > in directly. > > One thing you should be aware of is that if your requests do not > complete in 2 seconds, they'll start queuing up. There should be a way > to terminate previously queued requests that have not yet fired... but I > don't think there is a public way to do this. Please correct me if I'm > wrong. > > > > Everytime I call jsf.ajax.request() in poll(), the button's action >> gets called, as I expect. However, the Ajax listener associated with >> the button is only called when I actually click the button, and not >> when the poll() function is invoked. I expect the Ajax listener, like >> the button's action, to be invoked everytime I call >> jsf.ajax.request(). That seems like a reasonable expectation to me. >> > I think this is expected b/c you are not "executing" the button in your > Ajax request. Hmm... after looking at the jsf.js code, it does default > to component.id <http://component.id> (and component.name > <http://component.name> for some reason). So it should work as you > > expect... perhaps I worked around this bug when I shouldn't have had > to... I'm confused now. :) > > >> After rummaging around in the RI code, I found that I could get >> mojarra to call the Ajax listener everytime I call poll() if I change >> the call above to jsf.ajax.request() to this: >> >> jsf.ajax.request(component.id <http://component.id>;, >> >> event, { render: renderComponents, 'javax.faces.behavior.event': >> 'action' } ) >> >> Ugh. That's not very intuitive. Why do I have to do that? I expect the >> Ajax listener to be called without having to resort to such slight of >> hand. >> >> >> Bug #2: Removing components from the tree in an Ajax listener does not >> remove the component from the page when the Ajax call returns. >> >> When polling is complete, I want to remove the output, so in the Ajax >> listener I tried two things: 1. set the rendered attribute of the >> output to false. 2. remove the output component from it's parent's >> list of components. Neither works. In both cases, the output remains >> in the page until I do a full page refresh, and then it disappears. >> The output no longer updates after it's removed (or it's rendered >> attribute is set to false), but it's still in the page. Note that I am >> specifying that the output component is rendered after the Ajax call. >> >> If I manually remove a component, or set it's rendered attribute to >> true, during an Ajax call, I expect that component to disappear when >> the Ajax call returns, provided of course, that it's one of the >> components to be rendered when the Ajax call returns. >> > I ran into this also. However, if you think about it... this one makes > sense. You tell it to go through the render phase for a component that > says don't produce any output... so that's what it does (render==false > case). And for the render == invalid id case, the current behavior does > nothing. However, it probably should be smarter and return a "delete" > xml element to handle this... > > To work-a-round this one, we added a hack that detected an empty Ajax > response and manipulated the HTML DOM in our own JS... fortunately we > only expected 1 object to be upated so this worked for us. Not a good > work-a-round. We possibly could have changed our server-side logic to > change the 'style' of the component to 'display:none;' instead... > anyway, I agree with you on this issue. > > Ken > > >> Are these bugs, or are my expectations out of line? >> >> Thanks, >> >> >> david >> >> >> >> >> >