[jsr-314-open] f:ajax not working inside composite components?
by David Geary
I have an application that displays maps at different zoom levels. (If
you're interested in a visual, see
http://www.ibm.com/developerworks/java/library/j-jsf2fu1/index.html, and
please vote for 5 stars. :))
Anyway, my view code is pretty simple:
<h:selectOneMenu id="menu" *onchange="submit()"*
value="#{place.zoomIndex}"
valueChangeListener="#{*place.zoomChanged*}">
<f:selectItems value="#{places.zoomLevelItems}"/>
</h:selectOneMenu>
<h:graphicImage id="*image*" url="#{cc.parent.attrs.thePlace.mapUrl}"/>
As you can tell from #{cc.parent.attrs...} this code is in a composite
component, that itself resides in another composite component. The
preceeding code works just fine. When I select a different zoom level, the
surrounding form is submitted, my value change listener is invoked, which
sets the zoom level in my place backing bean, and subsequently, when the
request returns, place.getMapUrl() returns a map at the appropriate zoom
level.
However, with the preceeding code, the entire page redraws when I change the
zoom level. I figured it'd be a snap to use f:ajax to just update the image,
so I removed the onchange attribute, and added an f:ajax tag to the body of
h:selectOneMenu, like this:
<h:selectOneMenu id="menu"
value="#{place.zoomIndex}"
valueChangeListener="#{place.zoomChanged}"
style="font-size:13px;font-family:Palatino">
<f:selectItems value="#{places.zoomLevelItems}"/>
*<f:ajax execute="@this" render="image"/>
*
</h:selectOneMenu>
With FireBug, I've verified that a POST request is indeed executed when I
change the zoom level, and it appears that everything is in order:
form form
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
3
javax.faces.ViewState -1363564553004911965:-1863826268811277742
javax.faces.behavior.event valueChange
javax.faces.partial.ajax true
javax.faces.partial.event change
javax.faces.partial.execute
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
javax.faces.partial.render
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
javax.faces.source
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
I get a response back that looks like this:
<?xml version="1.0" encoding="utf-8"?>
<partial-response><changes><update
id="javax.faces.ViewState"><![CDATA[1747337848471748955:2683565346534242854
]]></update></changes></partial-response>
However, with f:ajax, my value change listener is never invoked on the
server, so the menu doesn't update, even though I've specified that the menu
should go through the execute phase of the lifecycle.
Does anyone know why my value change listener is not invoked? Am I doing
something wrong, or is this a bug?
btw, here are a couple of interesting datapoints:
1. I have breakpoints in jsf.ajax.request and jsf.ajax.response. The request
breakpoint is hit, but the response is not. The return status for the
response is 200, so there are apparently no errors.
2. I thought, from Jim Driscoll's blog about f:ajax, that we had to specify
client ids for execute and render, so I originally had this:
<f:ajax execute="@this" render="#{cc.clientId}:image"/>
But when I do that, I get this error...
<f:ajax> contains an unknown id
'j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image'
..when I load the page, even though that is the correct client id (as
evidenced from the request data above). Evidently, we're supposed to use the
component id and not the client id?
I'm trying to put together a demo for JavaOne, so if anyone can give me some
insights, I'd be most grateful.
Thanks,
david
14 years, 11 months
[jsr-314-open] where is EL 1.3?
by Dan Allen
Can someone point me to the specification where EL 1.3 is being defined? I
keep hearing that the EL is going to support features such a parameterized
method invocations, and it's even referenced in the Mojarra source code, but
I cannot seem to locate where this specification is being defined. Surely it
cannot still be part of JSP. I really think it deserves to be its own
specification if it isn't already.
-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.
14 years, 11 months
[jsr-314-open] [ADMIN] Credit where it's due
by Ed Burns
Hello Team,
This email is not just for EG members.
I'm giving a JSF2 webinar next week [1] and I'll be using these slides
as a starting point [2]. If you look at those slides, you'll see
thumbnail photos next to many of the features. The photos depict who
came to my mind as having worked on the feature. Naturally, I
inadvertently left many people out and I need your help to fix it.
ACTION: Please look at the slides [2] and let me know where you think
your or someone else's picture should be. Also, if you want to point
out that a particular feature is heavily inspired by some existing
technology not mentioned, please say that too.
I understand that this action is a little bit like creating your own
Wikipedia page, which many people (including myself) find distasteful.
Nonetheless, I really want to know how you feel you've contributed. To
that end, we can use my XRI contact page to anonymously submit your
feedback. Please include a link to a picture if it makes sense.
Sun employees need not apply. Everyone knows we're involved.
ACTION: To submit feedback go to <http://xri.net/=edburns> and fill out
the form and press SEND. Please put JSR-314 as the name. Please do it
by 1700 EDT Monday 20090511.
Thanks,
Ed
[1] http://weblogs.java.net/blog/edburns/archive/2009/05/jsf2_webinar_ne.html
[2] https://javaserverfaces.dev.java.net/presentations/jsf2-complete-tour.pdf
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 12 months
Re: [jsr-314-open] [ADMIN] Final Draft Release Candidate 1
by Ed Burns
>>>>> On Tue, 05 May 2009 20:40:50 -0400, Kito Mann <kito.mann(a)VIRTUA.COM> said:
KM> Hello Ed,
KM> I think you and Roger have done a wonderful job putting this all together,
KM> especially with all of the different artifacts. A few comments:
KM> PLD Docs
KM> * Since we've decided to call it the VDL, why are these still called
KM> PDLDocs?
That's not worth fixing right now.
KM> * The <composite:attribute> "method-signature" should probably be renamed
KM> "methodSignature" to be more consistent with the other attributes
We'll have to live with that, unfortunately.
KM> PDF
KM> Whole document -- "page description language" is still used in a few places
KM> -- a Search and Replace needs to be performed, and this will create some
KM> minor changes for the RI (for example, the configuration in 11.4.5)
Thanks, I thought I got those, but I guess not. I hope some changes
were not over-ridden due to the inability of version control to deal
with .fm files correctly.
Fixed.
KM> * Section 3.6.1.6, formatting is messed up
Fixed
KM> * Section 5.6.1, p 5-15: "resource" is spelled incorrectly when describing
KM> getValue()
Fixed.
KM> * Section 5.6.2 doesn't mention "flash" as an implicit variable, and I don't
KM> see any other reference to how it is resolved in the PDF. The JavaDocs for
KM> Flash say its an implicit variable called "flash".
Fixed.
KM> In addition, I would
KM> expect "flash" to be "flashScope" like the other scope (even though it has
KM> special semantics).
For ease of use and convention with Rails.
KM> And why is flash a property of the ExternalContext instead of the
KM> FacesContext?
Portlet requirements.
KM> * Section 13.1.1.1 -- As I've mentioned several times, it's silly for us not
KM> to have a simple @AjaxResource annotation that encapsulates the standard
KM> librarry name and its location. Every component developer is going to have
KM> to do this themselves.
That's a new feature for 2.1
KM> * Section 13.1.1.3 -- Same issue as 13.1.1.1 -- should be a
KM> <h:outputAjaxScript/> element
That's a new feature for 2.1
KM> * Section 13.1.1.3 -- Should say "The View Declaration Language Approach"
Fixed.
Thanks.
Another draft, the final, forthcoming.
Ed
15 years
[jsr-314-open] Spec Public Issue 552 Proposal
by Roger Kitain
Folks -
Proposal for minor updates to the jsdocs for ajax.response handling per :
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=552
The request came in from the MyFaces folks who are working on their own
spec compliant
JSF 2.0 Ajax implementation. The first part to this issue relaxes the
specification of propagating
javax.faces.ViewState to forms in a page - new requirement is to only
have to specify name.
The second part is a minor clarification to the docs describing the
replacement of document sections
if the server sends javax.faces.ViewRoot.
Thanks, Roger
15 years
