Re: [jsr-314-open] f:ajax behavior renderer question/discussion
by Ed Burns
>>>>> On Wed, 18 Nov 2009 16:13:24 +0100, Werner Punz <werner.punz(a)gmail.com> said:
WP> Since one of our guys stumbled upon this detail, the f:ajax is
WP> supposed to deliver the javascript for the f:ajax tag to the
WP> component involved the question now is. If we have a button which
WP> has the behavior applied to, does the behavior render a return false
WP> at the end or should it be possible that the button can do a form
WP> submit afterwards.
I belive this is the intent: whatever script was specified by the user
as an XML attribute in the markup page replaces the "return false;" at
the end of the script we generate when the f:ajax tag is attached.
Is this correct?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 1 month
[jsr-314-open] Fwd: [jsr-314-eg] Ajax bugs?
by David Geary
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>
Date: 2009/11/16
Subject: Re: [jsr-314-open] [jsr-314-eg] Ajax bugs?
To: jsr-314-eg(a)jcp.org
Cc: Cay Horstmann <cay(a)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, 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;
render: renderComponents;
}
props[component.id] = component.id;
var pollFunction = function poll() {
jsf.ajax.request(component, event, props);
}
window.setInterval(pollFunction, 200);
}
I am not sure if the component.id = 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' 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 (and 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, 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
15 years, 1 month
[jsr-314-open] f:ajax behavior renderer question/discussion
by Werner Punz
Hello
Since one of our guys stumbled upon this detail, the f:ajax is supposed to
deliver the javascript for the f:ajax tag to the component involved the
question now is.
If we have a button which has the behavior applied to, does the behavior
render a return false at the end or
should it be possible that the button can do a form submit afterwards.
My personal guess is either is correct, if the behavior adds a return false
at the end, then
the ajax call is done and no form submit is done afterwards, if it is not
done
then subsequent added scripts might not be blocked (by other behaviors or
internally set scripts)
but the button has to detect that an ajax behavior is applied and has to add
the return false
at the end himself, so what is the correct approach targetting this.
Kind regards
Werner Punz
15 years, 1 month
Re: [jsr-314-open] Fwd: [jsr-314-eg] Ajax bugs?
by Lincoln Baxter, III
I filed it as an enhancement a long time ago. Ill try to find it if it
matters.
Lincoln Baxter III
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
On Nov 17, 2009 3:29 PM, "Jim Driscoll" <Jim.Driscoll(a)sun.com> wrote:
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 origina...
>
> > From: *Ken Paulsen* <Ken.Paulsen(a)sun.com <mailto:Ken.Paulsen@sun.com>> >
> Date: 2009/11/16 > Subjec...
>
> > To: jsr-314-eg(a)jcp.org <mailto:jsr-314-eg@jcp.org> > Cc: Cay Horstmann <
> cay(a)horstmann.com <mailto:...
>
>> >> >> Sorry for the long email, but it should be easy to grok. >> >> I'm
>> trying to get a simple Ajax...
>> jsf.ajax.request(component.id <http://component.id>,
>>
>> >> event, { render: renderComponents } ) >> } >> var
>> timer = window.setInterv...
>>
> > > I ran into the same issue when trying to do something similar recently.
> > This should make what ...
> 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, pro...
> 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 ...
> '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 th...
> 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 li...
>> jsf.ajax.request(component.id <http://component.id>,
>>
>> >> event, { render: renderComponents, 'javax.faces.behavior.event': >>
>> 'action' } ) >> >> Ugh. That...
>>
> > > I ran into this also. However, if you think about it... this one makes
> > sense. You tell it to...
>
15 years, 1 month
Re: [jsr-314-open] jsf 2 evaluation and test
by Lincoln Baxter, III
I read nearly the entire article, and I am almost convinced that this
(recurring) user response is due to a lack of centralized information, easy
to use quick start guides , and tutorials.
I do think there are a few things that we can take away from this. Like
community involvement, but that is a discussion I'm going to raise at
jsfsummit.
Lincoln Baxter III
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
On Nov 17, 2009 8:23 AM, "Andy Schwartz" <andy.schwartz(a)oracle.com> wrote:
Nice timing Dan... I ran into the primary author (Sebastian) on the
exhibition floor at Devoxx. We had a good discussion. While Sebastian's
article does have its critical points and I don't necessarily share some of
the conclusions, it is clear that Sebastian has put a lot of effort into his
evaluation. We have been encouraging the community to provide feedback... I
am looking at Sebastian's article as some thoughtful, seriously detailed
feedback. Let's make the most of it.
Along those lines... I asked Sebastian if he would be willing to meet again
with some of us from the EG while we are here and he was very open to that.
We can talk over some of the concerns that Sebastian raised and see whether
we can translate these into action items for the EG. (And if we have any
concerns over the content of the article - eg. any inaccurate statements -
we can certainly raise these - Sebastian is interested in hearing our
feedback as well.)
Andy
Dan Allen wrote: > > Here's a lengthy article summarizing an evaluation of
jsf 2 by the fellows at...
15 years, 1 month
Re: [jsr-314-open] jsf 2 evaluation and test
by Ed Burns
>>>>> On Tue, 17 Nov 2009 14:22:59 +0100, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> Along those lines... I asked Sebastian if he would be willing to meet
AS> again with some of us from the EG while we are here and he was very open
AS> to that. We can talk over some of the concerns that Sebastian raised
AS> and see whether we can translate these into action items for the EG.
AS> (And if we have any concerns over the content of the article - eg. any
AS> inaccurate statements - we can certainly raise these - Sebastian is
AS> interested in hearing our feedback as well.)
Andy, Please tell him I'm working on responding to his flash issue
today.
I've been busy with JSR-303 integrations and qualifications into
Glassfish V3 and also with that Brazilian conference I attended last
week. Just finishing up the JSR-303 loose ends today.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 1 month
Re: [jsr-314-open] Errata: contentType and encoding on f:view
by Ed Burns
>>>>> On Tue, 10 Nov 2009 11:04:36 -0800, Jim Driscoll <Jim.Driscoll(a)Sun.COM> said:
JD> Just an FYI:
JD> The f:view tag in Facelets 1.1 had the ability to set contentType and
JD> encoding of responses via two named attributes.
JD> The 2.0 RI inherited that capability, but we neglected to add it to the
JD> faclets tld.
JD> Unless there are any objections, the RI team would like to treat this as
JD> a specification bug, adding these attributes to the TLD, and documenting
JD> this in the MR. This behavior is already supported in the released RI.
That's fine with me. Did you update the changelog?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 1 month
Re: [jsr-314-open] JSF logo
by Ed Burns
>>>>> On Tue, 10 Nov 2009 13:00:15 -0500, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> Okay. We'll just decide who receives it. Maybe we can have it sent to
DA> jsr314-comments.org. I get that e-mail anyway.
DA> Then we just need a page to display the entries. We'll do a vote using
DA> doodle.com or something.
I think this is a good idea. We tried having one for Mojarra, but these
things are difficult, and in the end it didn't pan out. One thing that
has worked for me in the past is to offer a prize to the winner. The
prize I can easily give out is a free copy of my rockstar book. I used
this method twice during JSF 2.0.
1. to get someone to write some XSLT to help us sort issues. Winner:
Imre Oßwald.
2. to get someone to contribute a sample app. Winner: Globalcode
scrumtoys.
Dan, if you want, you can put up a copy of your Seam in action book.
Most importantly, we need to make sure to license the image
appropriately. I suggest creative commons.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 1 month
