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