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) { > > > > ... > > > > } > > > > }); > > > > > > > > > > > > > > > > > > > >
