Yes, that would be awesome. I actually made a wrapper component doing just that in a project. JSF 1.2 also allows that on <f:view> which is better than nothing, but support on most component would be more useful and interesting to trap evil components not acting like expected.
On 7/18/07, Adam Winer <[EMAIL PROTECTED]> wrote:
BTW, one thing I thought of recently is that it could be reallyhandy for JSF debugging to support attaching component-level phase listeners (render, and other phases), so you could set a breakpoint at, for instance, "Before my table renders". Or "After this input field validates". That'd be a generalization of a render listener. The trick would be doing this in a way that doesn't drag down performance overall, which might be a lot easier if the overall UIComponent API were overhauled... -- Adam On 7/17/07, William Hoover <[EMAIL PROTECTED]> wrote: > > The problem with the tableSelection is that I can't ensure that the > page will always be using a table component for the list, but I think I > might have a solution. Thanks for the help though! > > Concerning the render listeners... I can understand your concern. I was > thinking that another solution (correct me if I'm wrong) might be using the > "RenderStage" to track this. When a new stage is set any listeners that are > registered will be notified by a render event... Just a thought :o) > > -----Original Message----- > *From:* Adam Winer [mailto:[EMAIL PROTECTED] > *Sent:* Monday, July 16, 2007 7:24 PM > *To:* MyFaces Discussion > *Subject:* Re: [Trinidad] Renderer Listeners > > On 7/16/07, William Hoover <[EMAIL PROTECTED]> wrote: > > > > The intent is to track selections. It seems like a lot of extra work > > to maintain quite a few tr:inputHidden components just to capture selection > > values. I see what your saying about post-processing a pattern in JS, but I > > don't think that searching through table for fields might be the best > > solution :) > > > For selection the Trinidad table has a built-in selection mechanism - > tableSelection="single|multiple". Might not be the UI you love best, but it > works. > > It seems like a cleaner and less error prone solution would be a > > renderer listener that can be invoked in either the encodeBegin() or > > encodeEnd() methods in the base component. That way a custom component isn't > > necessary. All I would have to do is set the renderer listener on the link > > component to process after the link has been rendered, capture the > > UIParameter values (they will not be null at this stage as they were before > > the link was rendered), and use them in a JS call to populate the selection > > input (as described below). I think this approach would minimize the amount > > of work it takes to implement a custom component, and I'm sure that code > > execution would be more efficient than adding a new component to the mix > > everytime that a developer needs some code to execute before/after a > > component renders. I can see quite a few scenarios where it might be helpful > > to fire some code before/after any component has been rendered- don't you? > > > Actually, I was imagining one custom component that exposes a generic > "before/after rendering" listener API. > > My concern about adding this to all components is that adding overhead > to every component's rendering + state saving performance when only a small > minority actually use the functionality is very worrisome. I've very rarely > encountered the need for what you're going for. > > -- Adam > > > > -----Original Message----- > > From: Adam Winer [mailto: [EMAIL PROTECTED] > > Sent: Saturday, July 14, 2007 12:30 PM > > To: MyFaces Discussion > > Subject: Re: [Trinidad] Renderer Listeners > > > > > > On 7/13/07, William Hoover <[EMAIL PROTECTED] > wrote: > > > As you guessed it, there are links within each table row that > > contain a f:param that holds data for that row. When the user clicks on that > > row I need to update a separate input field (outside the table- inside the > > same form) with the value from the f:param. I need this to happen on the > > client side before the page submits. > > > > > > > That, I don't get. Is the intent to track selection in some way? > > Couldn't you just stick a tr:inputHidden in the row and grab that > > value on the client, copying it into that separate input field? Or, > > for example, running some post-processing in JS (search for fields in > > the table that match a pattern). Etc., there's gotta be a better way > > of handling this. > > > > Alternatively, you could write a simple component of your own that > > doesn't render anything, but gets inserted into the table; you > > implement its encodeBegin() to > > do your stuff. > > > > -- Adam > > > > > > > I know that I can make this happen using EL in the link's onclick > > attribute based upon the current row data and the separate input field id ( > > i.e. onclick="javascript: setInputValue('separateInputFieldId',#{ > > row.someValue}';"), but I have a table view that gets reused quite a > > bit that may or may not need this feature based upon individual needs. Also, > > I'm not sure that it's a good idea to capture the client id for the separate > > input field in this manner due to the client id dependency on naming > > containers. That's why I'm looking for a programmatic solution that will add > > the needed javascript call on an as needed basis before the link/param are > > rendered outside the jsf page. > > > > > > -----Original Message----- > > > From: Adam Winer [mailto:[EMAIL PROTECTED] > > > Sent: Friday, July 13, 2007 3:24 PM > > > To: MyFaces Discussion > > > Subject: Re: [Trinidad] Renderer Listeners > > > > > > > > > Well, that's what you're doing, but doesn't quite explain > > > (A) why the value is null until the link is rendered (though > > > I'm guessing that's because its value comes from the > > > table data) > > > (B) why you need to get the param value for this specific > > > command link within this table (or a specific row > > > of the table?) > > > > > > -- Adam > > > > > > > > > On 7/13/07, William Hoover < [EMAIL PROTECTED]> wrote: > > > > I am trying to get a f:param value from a CoreCommandLink, but the > > value is null until the link has been rendered. > > > > > > > > The link is inside a tr:column- if that helps. > > > > > > > > -----Original Message----- > > > > From: Adam Winer [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, July 13, 2007 2:42 PM > > > > To: MyFaces Discussion > > > > Subject: Re: [Trinidad] Renderer Listeners > > > > > > > > > > > > There's no event listener, but there is that ResponseWriter > > > > API, which will get passed components on startElement(). > > > > 99% works (necessarily, because PPR relies on that!). > > > > What functionality are you trying to get here? > > > > > > > > -- Adam > > > > > > > > > > > > On 7/13/07, William Hoover < [EMAIL PROTECTED]> wrote: > > > > > I don't suppose there are any event listeners that can detect > > when components are being rendered? It would be nice if there was a way to > > be able to... > > > > > > > > > > component.addRendererListener(new RendererListener() { > > > > > public void processRenderBegin(RenderEvent event) { > > > > > ... > > > > > } > > > > > public void processRenderEnd(RenderEvent event) { > > > > > ... > > > > > } > > > > > }); > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
