I think you are running into the "composite component gets an id in the

discussing this problem in private mailings with Ryan and Andy...and now

> The problem is, while the username id is represented in the tree (as the > composite component), it's not represented in the rendered output. The > composite component is a non-rendering container. That's why the update > script cannot locate the DOM node to update. > > To get it to work, I had to represent the id of the component template > somewhere in my template...most naturally on the wrapping div. > > <div class="entry" id="#{cc.clientId}"> > <comp:insertChildren/> > </div> >

> Is this an unwritten rule? Or should the id automatically be assigned to > the first child of the composite component. I can see people getting easily > confused over this. Developers are going to trip all over this subtlety, I'm sure of it.

On Sat, May 23, 2009 at 1:26 PM, David Geary <clarity.training(a)gmail.com&gt;wrote: > I have a view composed of a template, and a handful of compositions. In > one of those compositions, I want to trigger an ajax request with f:ajax, > and I want to render a component in a different composition (but ultimately > in the same page). That doesn't seem to work. > > To be a little more explicit, I have a menu, implemented with a > composition, from which I launch an ajax request. When the request returns, > I want to render a single component in another composition. However, when I > try to do that, JSF complains that the component id cannot be found, when in > fact, the component is in the page, and is even in the same naming > container. > > I suspect that f:ajax is looking for the component id before the page is > fully constructed, and therefore only sees components in the same > composition. > > This should work, correct? If I cannot effectively use ajax across > compositions in the same page, then that makes templating a lot less > attractive. > > Thanks, > > > david > -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.

> All I've done is cut the zoom prompt and menu from the original file, and > pasted it into zoomLevelControl.xhtml. > > However, now when I change the zoom level menu, I get an error: > > <f:ajax> contains an unknown id 'image' According to the AjaxBehaviorRenderer: /** * Attempt to find the component assuming the ID is relative to the * nearest naming container. If not found, then search for the component * using an absolute component expression. */ My guess is that the components within the composite component are considered to be within a naming container, isolating them from your image component. The strange part, though, is that the composite component is not acting like a naming container as I observed. To fix your problem w/ the current implementation, you have to use an absolute id to the image component (I would guess). But yeah, this is a very confusing situation for developers.

jQuery) to find components because component IDs in JSF just plain suck.

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

Frankly, for JSF 2.1, I would like to see us go to an XPath-like syntax (or > jQuery) to find components because component IDs in JSF just plain suck. > Yup, I agree wholeheartedly, but we need to make it easy to do Ajax rendering across composite components for JSF 2.0. IMO, composite components are by far the single most kickass feature of JSF 2, and if they're crippled, we're gonna get some bad press.

The only bizzare bit is where the absolute id didn't work - but that's explainable in a few ways. The basic technique - using #{cc.clientId}:subcomponentid to reference the rendered id in the ajax calls, does not seem excessively hard to me. If you're doing ajax stuff in page, you need to know what the rendered id's are going to be. The minute you start doing anything past hello world, you will anyway. If you disagree with this, having seen the basic demo, then obviously I'm wrong, since I'd say you're both more sophisticated than the target audience. So please check that out (jsf-demo/ajax-switchlist), and let me know. Jim On 5/24/09 7:09 PM, Dan Allen wrote: > Hmmm, that seems really bizarre. Perhaps this is a bug in Mojarra but > some chance. Could you distill this down to a basic use case and see if > Ryan et al can make it a test in Mojarra. If there is a problem with the > API, then it will be more clearly revealed. > > > Frankly, for JSF 2.1, I would like to see us go to an XPath-like > syntax (or jQuery) to find components because component IDs in > JSF just plain suck. > > > Yup, I agree wholeheartedly, but we need to make it easy to do Ajax > rendering across composite components for JSF 2.0. IMO, composite > components are by far the single most kickass feature of JSF 2, and > if they're crippled, we're gonna get some bad press. > > > No doubt. We definitely can't overlook the foreground problem here. > > -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. >

Well, it can't be a div anyway, since that changes the layout from inline to block. I guess we could wrap every single component in a span, but that's quite a bit of extra characters for what is going to be rarely necessary.

> Otherwise, every time a newcomer creates a composite > component that he/she wants to update with Ajax, they are going to going > through this trial and error lesson. But they don't require it every time. They only require it if they want to update the entire component via ajax by the component name (or, more sadly, @this), rather than subportions of the component or the entire form, which I imagine would be a more common case. and if you want to render the entire composite component with ajax, then yes, you just add <span blah></span> - or div, if you want the component to be block mode.

Otherwise, every time a newcomer creates a composite > component that he/she wants to update with Ajax, they are going to going > through this trial and error lesson. I can't imagine that that confusion would last longer than the very first example, would it? For me, it didn't get past the first time I used view source. I got as far as "oh, it doesn't output anything unless I tell it to", and that wasn't hard to understand.

Still, that said, I think that this requires documentation - but goodness knows that that's not the only part that needs more documentation. And for this, I really do think that a simple statement of best practice would suffice.

Jim Driscoll wrote On 5/25/2009 2:23 AM ET: > Well, it can't be a div anyway, since that changes the layout from > inline to block. > > I guess we could wrap every single component in a span, but that's > quite a bit of extra characters for what is going to be rarely necessary. Actually, we cannot do this, since the composite component implementation may include block-level content. Nesting this within inline content (eg. a <div> nested within a <span>) would result in invalid html. The composite component author needs to specify the appropriate type of root element for their implementation.

> Still, that said, I think that this requires documentation - but > goodness knows that that's not the only part that needs more > documentation. And for this, I really do think that a simple statement > of best practice would suffice. Yeah, I was thinking that same. Though not sure where exactly this should be documented in order to increase the chance the our users will find this information.

The only bizzare bit is where the absolute id didn't work - but that's explainable in a few ways. The basic technique - using #{cc.clientId}:subcomponentid to reference the rendered id in the ajax calls, does not seem excessively hard to me.

are going to be. The minute you start doing anything past hello world, you will anyway. If you disagree with this, having seen the basic demo, then obviously I'm wrong, since I'd say you're both more sophisticated than the target audience. So please check that out (jsf-demo/ajax-switchlist), and let me know.

Jim On 5/24/09 7:09 PM, Dan Allen wrote: > Hmmm, that seems really bizarre. Perhaps this is a bug in Mojarra but > some chance. Could you distill this down to a basic use case and see if > Ryan et al can make it a test in Mojarra. If there is a problem with the > API, then it will be more clearly revealed. > > > Frankly, for JSF 2.1, I would like to see us go to an XPath-like > syntax (or jQuery) to find components because component IDs in > JSF just plain suck. > > > Yup, I agree wholeheartedly, but we need to make it easy to do Ajax > rendering across composite components for JSF 2.0. IMO, composite > components are by far the single most kickass feature of JSF 2, and > if they're crippled, we're gonna get some bad press. > > > No doubt. We definitely can't overlook the foreground problem here. > > -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. >

On 5/24/09 8:39 PM, David Geary wrote: > And that id is *exactly* what <f:ajax> says it cannot find. It's in the > page, but <f:ajax> cannot find it?!? > > My guess is that <f:ajax> is evaluating the id before the page is > completely constructed, and therefore, it doesn't find it, but that's > just a WAG on my part. > > So, if this is not correct: > > <f:ajax render="#{cc.parent.clientId}:image"/> > > Then how do I access the image in the parent (map) component? > > It seems to me that I'm using <f:ajax> correctly, but I'd be happy to be > told otherwise. > It's late, but yes, that looks correct, and yes, your guess sounds correct. Could you file this as an impl bug? Now, we do need to fix that as a bug, but I must argue that your use case represents bad practice. Your component is using ajax inside a component to modify the using page. That's difficult to maintain, and I suspect it will lead to obfuscated code quite easily. I'd instead argue that if you are going to have one component modify another, you should either group them into one composite, or, have the ID of the component you act upon passed in as an attribute (say "for="?)

Of course, that second usage suggestion opens up another hole in the cc api - the lack of ability to do name resolution. Though if/when we get method parameters, then cc.findComponent will work, I guess. Though I've been saying that for a pretty long time now, I should check on when we're getting those method params...

<h:body> <h:form id="form1"> <ez:switchlist id="switchlist"/> <h:commandButton value="reload" type="submit"/> </h:form> </h:body>

<cc:implementation> <h:selectManyListbox id="list1"/> <h:commandButton id="move1to2"> <f:ajax execute="@this #{cc.clientId}:list1" render="#{cc.clientId}:list1 #{cc.clientId}:list2"/> </h:commandButton> <h:selectManyListbox id="list2"/> </cc:implementation>

<f:ajax execute="@this #{cc.clientId}:list1" render="#{cc.clientId}:list1 #{cc.clientId}:list2"/>

<f:ajax execute="@this list1" render="list1 list2"/>

render="#{cc.clientId}:list1"

render="form1:switchlist:list1"

move1to2ButtonComponent.findComponent("form1:switchlist:list1");

UIComponent resolvedComponent = component.findComponent(expr); if (resolvedComponent == null) { // not found using a relative search, try an absolute search resolvedComponent = component.findComponent(':' + expr); }

<f:ajax execute="@this list1" render="list1 list2"/>

<h:commandButton value="reload" type="submit" id="reload"/>

<f:ajax execute="@this list1" render="list1 list2 :#{cc.parent.clientId}:reload"/>

<f:ajax> contains an unknown id '::reload'

if (COMPOSITE_COMPONENT_PARENT_NAME.equals(propertyName)) { UIComponent c = (UIComponent) base; context.setPropertyResolved(true); UIComponent ccParent = UIComponent.getCompositeComponentParent(c); return ccParent; }

<cc:attribute name="reloadId"/>

<f:ajax execute="@this list1" render="list1 list2 #{cc.attrs.reloadId}"/>

<ez:switchlist id="switchlist" reloadId=":form1:reload"/>

2009/5/24 Jim Driscoll <Jim.Driscoll(a)sun.com <mailto:Jim.Driscoll@sun.com>> On 5/24/09 8:39 PM, David Geary wrote: And that id is *exactly* what <f:ajax> says it cannot find. It's in the page, but <f:ajax> cannot find it?!? My guess is that <f:ajax> is evaluating the id before the page is completely constructed, and therefore, it doesn't find it, but that's just a WAG on my part. So, if this is not correct: <f:ajax render="#{cc.parent.clientId}:image"/> Then how do I access the image in the parent (map) component? It seems to me that I'm using <f:ajax> correctly, but I'd be happy to be told otherwise. It's late, but yes, that looks correct, and yes, your guess sounds correct. Could you file this as an impl bug? Okay. I'll send a WAR to Ryan, and see if we can get this fixed asap. I'd like to get this working for my J1 demo. Now, we do need to fix that as a bug, but I must argue that your use case represents bad practice. Your component is using ajax inside a component to modify the using page. That's difficult to maintain, and I suspect it will lead to obfuscated code quite easily. I'd instead argue that if you are going to have one component modify another, you should either group them into one composite, or, have the ID of the component you act upon passed in as an attribute (say "for="?) Yup, I concur--too much coupling between parent and child components. Unfortunately, I can't seem to pass the component ID to the child component either. IOW, this doesn't work: In parent component: <places:mapZoomControl componentToRender="#{cc.clientId}:image"/> And in mapZoomControl.xhtml: <composite:attribute name="componentToRender"/> ... <f:ajax render="#{cc.attrs.componentToRender}"/> I suppose it's not surprising that the preceeding doesn't work--it looks like a manifestation of the same bug. I'll give Ryan a buzz. Thanks, david Of course, that second usage suggestion opens up another hole in the cc api - the lack of ability to do name resolution. Though if/when we get method parameters, then cc.findComponent will work, I guess. Though I've been saying that for a pretty long time now, I should check on when we're getting those method params... Jim

This will result in the search expression "form1:switchlist:list1" being resolved relative to the nearest naming container, which in this case is the switchlist composite component itself. Since there is no "form1:switchlist:list1" component within the composite component naming container, findComponent() would return null, and the <f:ajax> tag should log a warning.

However, instead of failing/logging a warning, we've got some code in AjaxBehaviorRenderer.findComponent() that does the following: > UIComponent resolvedComponent = component.findComponent(expr); > if (resolvedComponent == null) { > // not found using a relative search, try an absolute search > resolvedComponent = component.findComponent(':' + expr); > } The bonus absolute search is not part of the spec - ie. is not typical findComponent() id resolution behavior. This code should be removed and replaced by a warning. (We should be able to make the warning clearer by identifying the naming container that provided the scope of the search.

In any case, when switching over to: > <f:ajax execute="@this list1" render="list1 list2"/> Everything works as expected. We definitely should update this demo to use this simpler, more spec-compliant solution.

In order to try to reproduce the problem that David was seeing, I decided to see whether I could update the "reload" button on the main page from within the composite component. So, first I gave the reload button an id: > <h:commandButton value="reload" type="submit" id="reload"/> And then I added a new render target inside of our <f:ajax> tag (inside of the composite component): > <f:ajax execute="@this list1" render="list1 list2 > :#{cc.parent.clientId}:reload"/> Note that I used the leading ":" character to indicate that this is an absolute id. I was thinking that "#{cc.parent}" would resolve to the composite component's immediate parent, which in this case happens to be the "form1" component. As such, I figured that "#{cc.parent.clientId}" would give me "form1", and ":#{cc.parent.clientId}:reload" would produce the absolute id ":form1:reload", which should target the outer reload button (leaving aside the question of whether this is a good thing to do or not). However, when I ran the test case, I hit the following error: > <f:ajax> contains an unknown id '::reload' Okay, that's weird. So this means that "#{cc.parent.clientId}" is not resolving to the parent component's client id, but instead to null/empty string. Huh. After poking around some more, I found my way to the com.sun.faces.el.CompositeComponentAttributesELResolver, which provides some special handling for certain properties on the "cc" object, including the "parent" property: > if (COMPOSITE_COMPONENT_PARENT_NAME.equals(propertyName)) { > UIComponent c = (UIComponent) base; > context.setPropertyResolved(true); > UIComponent ccParent = UIComponent.getCompositeComponentParent(c); > return ccParent; > } And, of course, UIComponent.getCompositeComponentParent() does not return the composite component's parent, but instead returns the nearest ancestor composite component. Which, in this particular demo, is... null. Yuck. Okay, in retrospect, rather than re-defining the meaning of "parent" here, we should have introduced a new derived property, eg. "compositeParent", or something along those lines. (Unfortunately the current behavior is defined by the spec - section 5.6.2.2, so too late to do anything about this for 2.0.)

JSF already has a smart enough code that look components by 'id'. Both <h:outputLabel> and <h:message > use it to lookup target component that is defined by the 'for' attribute, RichFaces library uses the same strategy and it works very well. It would be better to use a same code for <f:ajax> tag instead of simple local/global search.

Client identifier of the component for which this element is a label.

The Javadoc for UIMessage and TLDDOC for h:message describes it as one that takes a clientId. This was never the intent - this should always have been a relative ID, exactly as in h:outputLabel. As specified, h:message is incredibly difficult to use. IMO, this is an errata, not a spec change, though for backwards compatibility I'd recommend continuing to look for messages in addition as if "for" were for clientIds.

Frankly, for JSF 2.1, I would like to see us go to an XPath-like syntax (or jQuery) to find components because component IDs in JSF just plain suck.

Hey Alex - Alexandr Smirnov wrote On 5/26/2009 5:41 PM ET: > JSF already has a smart enough code that look components by 'id'. Both > <h:outputLabel> and <h:message > use it to lookup target component that > is defined by the 'for' attribute, RichFaces library uses the same > strategy and it works very well. It would be better to use a same code > for <f:ajax> tag instead of simple local/global search. > > > Good point. I agree that ideally we should be consistent across the various cases where component attributes refer to other components by id. I took a closer look at the spec/code for the outputLabel "for" attribute. The spec is unfortunately vague (and possibly incorrect). The "for" tag doc simply says: Client identifier of the component for which this element is a label. > Adam logged the following related spec issue on this a couple of years ago: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=266 In which Adam says: The Javadoc for UIMessage and TLDDOC for h:message describes it as one > that takes a clientId. This was > never the intent - this should always have been a relative ID, exactly as > in h:outputLabel. As specified, > h:message is incredibly difficult to use. IMO, this is an errata, not a > spec change, though for backwards > compatibility I'd recommend continuing to look for messages in addition as > if "for" were for clientIds. > One thing that is odd is that this implies that outputLabel is correctly specified, though as far as I can tell, both outputLabel and message share the same "for" doc. (At least the tag doc - perhaps I am missing other doc in the spec itself.) Looking at the implementations, MyFaces does the following: - Calls findComponent() using the outputLabel/message component as the base component. - If a component is found, return the id. - If the component is found, attempt to construct an id manually (via string manipulation). So, this is pretty much identical to our f:ajax execute/render id behavior, at least in the case where the id corresponds to a component that can be found in the component tree. That is: <h:outputLabel for="foo"/> And: <f:ajax execute="foo"/> Will find the same components when running in MyFaces. (Same goes for the id ":foo"). Mojarra starts off similar... - Calls findComponent() using the outputLabel/message component as the base component. So for cases where a relative id is specified in the same naming container, or an absolute id is specified, both <f:ajax> and <h:outputLabel> behave the same in Mojarra. However, in the event that the findComponent() call does not find the component, Mojarra then goes on to: - Walk up the ancestor chain. - For each component in the ancestor chain, call findComponent(). - If we reach the root and still haven't found the matching component, recursively walk over the entire component tree looking for NamingContainers, and call findComponent on each NamingContainer. Umm... Yikes. That's a lot of component tree walking! So, a few issues here: 1. We need a spec clarification MyFaces and Mojarra are providing different behaviors... As things currently stand, the following code: <f:subview id="bar"> <h:outputLabel for="foo"> </f:subview> <h:inputText id="foo"/> Is not going to be portable across JSF implementations. 2. The idea of doing so many findComponent() calls worries me. A case that we should be able to handle efficiently is having an <f:ajax> tag attached to a component (eg. an <h:commandButton>) that is being stamped out repeatedly (eg. in an <h:data> component). It is possible that the <f:ajax> execute/render lists may contain multiple execute/render ids each. In this case, we would end up doing possibly many findComponent() calls each time the component is stamped out - ie. for each row in a table. Perhaps with very small component trees this may be acceptable, but I can easily see this becoming inefficient as the size of the component tree grows. Personally I would like to see an approach that optimizes common cases to avoid unnecessary findComponent() calls. For example, there may be cases where we could: - Take the id that we are provided. - Perform some string manipulation to derive the desired id (eg. append the id to the nearest naming container's client id). - Return the derived id. (No findComponent() calls). Or, if we want to provide diagnostic capabilities: - When project stage is development, after we have derived the id, call findComponent() to verify that the referenced component is present. We may not be able to derive ids in this fashion for all case, but it seems to me that this should work okay for simple "relative" ids - eg. execute="foo". 3. We should re-evaluate our component referencing mechanisms for 2.1. For example, I believe that we should provide a way to explicitly address components in ancestor naming containers, rather than rely on an expensive implicit search mechanism. Trinidad provides a way to do this - we use the "::" prefix to indicate that we should pop up one level in the naming container hierarchy (similar to ".." for directory paths). Dan mentioned earlier in the thread: Frankly, for JSF 2.1, I would like to see us go to an XPath-like syntax > (or jQuery) to find components because component IDs in JSF just plain suck. > Not sure what the best solution is, but I agree with Dan that we should take another look at this. 4. Does <f:ajax> actually need to perform id processing/encoding at render time? <f:ajax>/AjaxBehavior currently send all execute/render ids to the client - which means: - Lots of findComponent() calls at render time. - Lots of content bloating. However, as Alex has suggested in the past, this may be unnecessary. Instead of sending these ids back and forth to/from the client, we should be able to enhance our Behavior mechanism to give the Behavior that triggered a postback the first crack at processing the request... So, for example, this would allow AjaxBehavior to enhance the PartialViewContext's execute/render lists early on during the Faces lifecycle (when processing a postback). No need to send the ids to the client at all. The cost of doing this is one extra tree visit, which seems like a reasonable trade-off. Let's revisit this one 2.1. Andy

Notice the <f:ajax> tag. I think I'm accessing the image from the parent component (map.xhtml) correctly. However, when I load the page I get this: <f:ajax> contains an unknown id 'form:j_id1186681689_16ef8569:0:j_id1186681689_16ef8513:j_id-1105909415_41ead6fe:image'

If I remove the f:ajax tag, load the page, and check the source, I see an <img> tag: <img id="form:j_id1186681689_16ef8569:0:j_id1186681689_16ef8513:j_id-1105909415_41ead6fe:image" src="..."/> And that id is *exactly* what <f:ajax> says it cannot find. It's in the page, but <f:ajax> cannot find it?!? My guess is that <f:ajax> is evaluating the id before the page is completely constructed, and therefore, it doesn't find it, but that's just a WAG on my part.